赞
踩
Git 自带一个git config
的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置:
/etc/gitconfig
文件: 包含系统上每一个用户及他们仓库的通用配置。 如果在执行git config
时带上--system
选项,那么它就会读写该文件中的配置变量。 (由于它是系统配置文件,因此你需要管理员或超级用户权限来修改它。)~/.gitconfig
或 ~/.config/git/config
文件:只针对当前用户。 你可以传递--global
选项让 Git 读写此文件,这会对你系统上所有的仓库生效。config
文件(即.git/config
):针对该仓库。 你可以传递--local
选项让 Git 强制读写此文件,虽然默认情况下用的就是它。(当然,你需要进入某个 Git 仓库中才能让该选项生效。)每一个级别会覆盖上一级别的配置,所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。
# 查看所有的配置以及它们所在的文件
$ git config --list --show-origin
# 编辑Git配置文件
$ git config -e [--global]
# 设置提交代码时的用户信息
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"
# 配置默认文本编辑器,当 Git 需要你输入信息时会调用它。 如果未配置,Git 会使用操作系统默认的文本编辑器。
$ git config [--global] core.editor emacs
# 提交时换行符转化为LF,检出分支不做转换。统一使用LF以确保Linux和Windows均可兼容
$ git config [--global] core.autocrlf input
# 配置GIT不自动转换文件权限,保留项目文件原始的执行权限
$ git config [--global] core.fileMode false
# 配置GIT不使用ssl验证,否则本地需要配置ssl相关
$ git config [--global] http.sslVerify false
#配置git的longpaths,解决git clone代码报文件名过长问题
$ git config [--global] core.longpaths true
# 来检查 Git 的某一项配置
$ git config <key>
解决git每次提交和拉取代码需要输入用户名和密码问题
输入以下命令行:
$ git config --global credential.helper store
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
此外,如果你不需要全面的手册,只需要可用选项的快速参考,那么可以用 -h
选项获得更简明的 “help”
$ git add -h
git
add:添加文件内容至索引
commit:记录变更到仓库
push :更新远程引用和相关的对象
git push -u [remote] [本地分支名/commit]:[远程分支名]
HEAD
或者 如master~3
的commit指针--force-with-lease
checkout:切换分支或恢复工作区文件
# 恢复暂存区的指定文件到工作区
$ git checkout [file]
# 恢复暂存区的所有文件到工作区
$ git checkout .
# 恢复某个commit的指定文件到暂存区和工作区
$ git checkout [commit] [file]
# 恢复某个branch的n个版本之前的指定文件到暂存区和工作区
$ git checkout [branch][~n] [file]
reset:重置当前 HEAD指针 到指定状态,同时重置暂存区
# 重置暂存区的指定文件,与上一次commit保持一致,但工作区不变
$ git reset [file]
# 重置暂存区与工作区,与上一次commit保持一致
$ git reset --hard
# 重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变
$ git reset [commit]
# 重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致
$ git reset --hard [commit]
# 重置当前HEAD为指定commit,但保持暂存区和工作区不变
$ git reset --keep [commit]
git reset --hard HEAD~1
git log
git rebase -i 提交ID
pick
替换为drop
(注意每完成一个替换操作,需要按下Esc键退出vi的编辑模式)。pick(p)
:保留该commitreword(r)
:保留该commit,但我需要修改该commit 的注释edit(e)
:保留该commit,但我要停下来修改该提交(不仅仅修改注释)squash(s)
:将该commit与前一个commit合并fixup(f)
:将该commit和前一个commit合并,但我不要保留该提交的注释信息exec(x)
:执行shell命令drop(d)
:丢弃该commitwq
保存并退出(|REBASE-m)
问题的解决方法:git rebase --continue
fetch:从另外一个仓库下载对象和引用
git fetch [remote] [远程分支名]:[本地分支名]
pull:获取并整合另外的仓库或一个本地分支
git pull [remote] [远程分支名]:[本地分支名]
diff:显示提交之间、提交和工作区之间等的差异
branch:分支相关
# 新建一个commit,用来撤销指定commit
# 后者的所有变化都将被前者抵消,并且应用到当前分支
$ git revert [commit]
#暂时将未提交的变化移除,稍后再移入
$ git stash
$ git stash pop
# 显示暂存区和工作区的差异
$ git diff
# 显示暂存区和上一个commit的差异
$ git diff --cached [file]
# 显示工作区与指定分支最新提交之间的差异
$ git diff [branch]
# 显示工作区与当前分支最新commit之间的差异
$ git diff HEAD
# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]
# 显示今天你写了多少行代码
$ git diff --shortstat "@{0 day ago}"
# 显示某次提交的元数据和内容变化
$ git show [commit]
# 显示某次提交发生变化的文件
$ git show --name-only [commit]
# 显示某次提交时,某个文件的内容
$ git show [commit]:[filename]
# 显示当前分支的最近几次提交
$ git reflog
git add
加入暂存区,状态变为Staged
。Modified
;git rm
移除仓库区和暂存区,则称为Untracked
文件。git add
加入暂存区,变为Staged
状态git checkout
恢复仓库区的文件快照,覆盖当前修改,返回到unmodify
状态git commit
将暂存区同步到仓库中,此时若仓库中的文件与本地文件一致,则文件变为Unmodify
状态;git reset HEAD <filename>
取消暂存,文件状态为Modified
通常有两种获取 Git 项目仓库的方式:
两种方式都会在你的本地机器上得到一个工作就绪的 Git 仓库。
如果你有一个尚未进行版本控制的项目目录,想要用 Git 来控制它,那么首先需要进入该项目目录中。
# 在当前目录新建一个Git代码库
$ git init
# 新建一个目录,将其初始化为Git代码库
$ git init [project-name]
该命令将创建一个名为 .git 的子目录,这个子目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的骨干。 但是,在这个时候,我们仅仅是做了一个初始化的操作,你的项目里的文件还没有被跟踪。 (参见Git 内部原理来了解更多关于到底 .git 文件夹中包含了哪些文件的信息。)
如果在一个已存在文件的文件夹(而非空文件夹)中进行版本控制,你应该开始追踪这些文件并进行初始提交。 可以通过git add
命令来指定所需的文件来进行追踪,然后执行 git commit :
$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'
现在,你已经得到了一个存在被追踪文件与初始提交的 Git 仓库。
如果你想获得一份已经存在了的 Git 仓库的拷贝,比如说,你想为某个开源项目贡献自己的一份力,这时就要用到git clone
命令。
# 下载一个项目和它的整个代码历史
$ git clone [url]
Git 克隆的是该 Git 仓库服务器上的几乎所有数据,而不是仅仅复制完成你的工作所需要文件。 当你执行git clone
命令的时候,默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。 事实上,如果你的服务器的磁盘坏掉了,你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库(虽然可能会丢失某些服务器端的钩子(hook)设置,但是所有版本的数据仍在,详见在服务器上搭建 Git )。
$ git clone https://github.com/libgit2/libgit2
这会在当前目录下创建一个名为 “libgit2” 的目录,并在这个目录下初始化一个.git
文件夹, 从远程仓库拉取下所有数据放入 .git 文件夹,然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 libgit2 文件夹,你会发现所有的项目文件已经在里面了,准备就绪等待后续的开发和使用。
如果你想在克隆远程仓库的时候,自定义本地仓库的名字,你可以通过额外的参数指定新的目录名:
$ git clone https://github.com/libgit2/libgit2 mylibgit
这会执行与上一条命令相同的操作,但目标目录名变为了 mylibgit
。
Git 支持多种数据传输协议。 上面的例子使用的是https://
协议,不过你也可以使用git://
协议或者使用 SSH 传输协议,比如user@server:path/to/repo.git
。在服务器上搭建 Git 将会介绍所有这些协议在服务器端如何配置使用,以及各种方式之间的利弊。
git status
命令的输出十分详细,但其用语有些繁琐。 Git 有一个选项可以帮你缩短状态命令的输出,这样可以以简洁的方式查看更改。 如果你使用git status -s
命令或git status --short
命令,你将得到一种格式更为紧凑的输出。
# 显示有变更的文件
$ git status
# 状态简览
$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txt
新添加的未跟踪文件前面有 ??
标记,新添加到暂存区中的文件前面有 A
标记,修改过的文件前面有 M
标记。 输出中有两栏,左栏指明了暂存区的状态,右栏指明了工作区的状态。例如,上面的状态报告显示: README
文件在工作区已修改但尚未暂存,而 lib/simplegit.rb
文件已修改且已暂存。Rakefile
文件已修改,暂存后又作了修改,因此该文件的修改中既有已暂存的部分,又有未暂存的部分。
默认不加参数,git log显示如下:
--oneline
将每个commit的信息缩短为一行--graph
会绘制一个 ASCII 图像来展示提交历史的分支结构,类似于一个树形结构,很方便很好看--stat
:显示每次更新的修改文件的统计信息,每个提交都列出了修改过的文件,以及其中添加和移除的行数,并在最后列出所有增减行数小计。--shortstat
:只显示--stat
中最后的行数添加修改删除统计-p
按补丁显示每个更新间的差异,也可以显示指定文件相关的每一次diff,比–stat命令信息更全--name-only
:只显示修改的文件清单--name-status
:显示新增、修改和删除的文件清单--relative-date
:使用较短的相对时间显示(例如:“two weeks ago”)--abbrev-commit
:仅显示SHA-1哈希值的前几个字符,而非所有的40个字符—pretty=
:使用其他格式显示历史提交信息,可选项有:oneline,short,medium,full,fuller,email,raw
以及format:<string>
,默认为medium
,如:
--pretty=oneline
:一行显示,只显示哈希值和提交说明(--online
本身也可以作为单独的属性)--pretty=format:" "
:控制显示的格式,如:
%H
提交对象(commit)的完整哈希字串%h
提交对象的简短哈希字串%T
树对象(tree)的完整哈希字串%t
树对象的简短哈希字串%P
父对象(parent)的完整哈希字串%p
父对象的简短哈希字串%an
作者(author)的名字%ae
作者的电子邮件地址%ad
作者修订日期(可以用 -date= 选项定制格式)%ar
作者修订日期,按多久以前的方式显示%cn
提交者(committer)的名字%ce
提交者的电子邮件地址%cd
提交日期(可以用 -date= 选项定制格式)%cr
提交日期,按多久以前的方式显示%s
提交说明--pretty=format:" "
,以这句为例:%Cred%h%Creset -%C(yellow)%d%Cblue %s %Cgreen(%cd) %C(bold blue)<%an>
[%Cred%h] [%Creset -] [%C(yellow)%d ] [%Cblue%s] [%Cgreen(%cd)] [%C(bold blue)<%an>]
reset(默认的灰色),normal, black, red, green, yellow, blue, magenta, cyan, white
.bold, dim, ul, blink, reverse
.--date= (relative|local|default|iso|rfc|short|raw)
:定制后边如果出现%ad
或%cd
时的日期格式-n
限定前n次提交--author="作者"
用来过滤commit,限定输出给定的用户--after '日-月-年'
和--before '日-月-年'
限定指定日期范围的log--decoreate
显示对应commit所属的branch和tag信息-S [keyword]
根据关键词搜索提交历史--merges
或者--no-merges
控制是否显示merge的commit按数量
-n:显示前n条log
按日期
--after=
比如git log --after="2014-7-1”,显示2014年7月1号之后的commit(包含7月1号)
后边的日期还可以用相对时间表示,比如"1 week ago"和”yesterday",比如git log --after="yesterday"
这里的格式可以是什么?
--before=
同上
另外这两条命令可以同时使用表示时间段,比如git log --after="2014-7-1" --before="2014-7-4"
另外--since --until和 --after --before是一个意思,都可以用
按作者
--author=
比如git log --author=“John",显示John贡献的commit
注意:作者名不需要精确匹配,只需要包含就行了
而且:可以使用正则表达式,比如git log --author="John|Mary”,搜索Marry和John贡献的commit
而且:这个--author不仅包含名还包含email, 所以你可以用这个搜索email
按commit描述
--grep=
比如:git log --grep="JRA-224"
而且:可以传入-i用来忽略大小写
注意:如果想同时使用--grep和--author,必须在附加一个--all-match参数
按文件
- -(空格)或[没有]
有时你可能只对某个文件的修改感兴趣, 你只想查看跟某个文件相关的历史信息, 你只需要插入你感兴趣文件的路径[对,是路径,所以经常是不太好用]就可以了
比如:git log -- foo.py bar.py ,只返回和foo.py或bar.py相关的commit
这里的--是告诉Git后面的参数是文件路径而不是branch的名字. 如果后面的文件路径不会和某个branch产生混淆, 你可以省略- -,比如git log foo.py
另外,后边的路径还支持正则,比如:git log *install.md 是,指定项目路径下的所有以install.md结尾的文件的提交历史
另外,文件名应该放到参数的最后位置,通常在前面加上--并用空格隔开表示是文件
另外,git log file/ 查看file文件夹下所有文件的提交记录
按分支
- -
--branchName branchName为任意一个分支名字,查看某个分支上的提交记录
需要放到参数中的最后位置处
如果分支名与文件名相同,系统会提示错 误,可通过--选项来指定给定的参数是分支名还是文件名
比如:在当前分支中有一个名为v1的文件,同时还存在一个名为v1的分支
git log v1 -- 此时的v1代表的是分支名字(--后边是空的)
git log -- v1 此时的v1代表的是名为v1的文件
git log v1 -- v1 代表v1分支下的v1文件
按内容
-S"<string>"、-G"<string>"
有时你想搜索和新增或删除某行代码相关的commit. 可以使用这条命令
假设你想知道Hello, World!这句话是什么时候加入到项目里去的,可以用:git log -S"Hello,World!"
另外:如果你想使用正则表达式去匹配而不是字符串, 那么你可以使用-G代替-S.
这是一个非常有用的debug工具, 使用他你可以定位所有跟某行代码相关的commit. 甚至可以查看某行是什么时候被copy的, 什么时候移到另外一个文件中去的
注:-S后没有"=",与查询内容之间也没有空格符
按范围
git log <since>..<until>
这个命令可以查看某个范围的commit
这个命令非常有用当你使用branch做为range参数的时候. 能很方便的显示2个branch之间的不同
比如:git log master..feature,master..feature这个range包含了在feature有而在master没有的所有commit,同样,如果是feature..master包含所有master有但是feature没有的commit
另外,如果是三个点,表示或的意思:git log master...test 查询master或test分支中的提交记录
过滤掉merge commit
--no-merges
默认情况下git log会输出merge commit. 你可以通过--no-merges标记来过滤掉merge commit,git log --no-merges
另外,如果你只对merge commit感兴趣可以使用—merges,git log --merges
按标签tag
git log v1.0
直接这样是查询标签之前的commit
加两个点git log v1.0.. 查询从v1.0以后的提交历史记录(不包含v1.0)
按commit
git log commit :查询commit之前的记录,包含commit
git log commit1 commit2:查询commit1与commit2之间的记录,包括commit1和commit2
git log commit1..commit2:同上,但是不包括commit1
其中,commit可以是提交哈希值的简写模式,也可以使用HEAD代替
HEAD代表最后一次提交,HEAD^为最后一个提交的父提交,等同于HEAD~1
HEAD~2代表倒数第二次提交
# 显示某个commit之后的所有变动,每个commit占据一行
$ git log [tag] HEAD --pretty=format:%s
# 显示某个commit之后的所有变动,其"提交说明"必须符合搜索条件
$ git log [tag] HEAD --grep feature
# 显示某个文件的版本历史,包括文件改名
$ git log --follow [file]
$ git whatchanged [file]
# 按补丁显示每个更新间的差异,也可以显示指定文件相关的每一次diff,比--stat命令信息更全
$ git log -p [file]
# 显示过去5次提交
$ git log -5 --pretty --oneline
# 显示所有提交过的用户,按提交次数排序
$ git shortlog -sn
# 显示指定文件是什么人在什么时间修改过
$ git blame [file]
工作目录下的每一个文件都不外乎这两种状态:已跟踪 或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件,在上一次快照中有它们的记录,在工作一段时间后, 它们的状态可能是未修改,已修改或已放入暂存区。简而言之,已跟踪的文件就是 Git 已经知道的文件。
工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件,它们既不存在于上次快照的记录中,也没有被放入暂存区。 初次克隆某个仓库的时候,工作目录中的所有文件都属于已跟踪文件,并处于未修改状态,因为 Git 刚刚检出了它们, 而你尚未编辑过它们。
编辑过某些文件之后,由于自上次提交后你对它们做了修改,Git 将它们标记为已修改文件。 在工作时,你可以选择性地将这些修改过的文件放入暂存区,然后提交所有已暂存的修改,如此反复。
# 添加指定文件到暂存区
$ git add [file1] [file2] ...
# 添加指定目录到暂存区,包括子目录
$ git add [dir]
# 添加当前目录的所有文件到暂存区
$ git add .
# 添加每个变化前,都会要求确认
# 对于同一个文件的多处变化,可以实现分次提交
$ git add -p
例子:
$ git add README
#此时再运行 git status 命令,会看到`README`文件已被跟踪,并处于暂存状态:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: README
只要在Changes to be committed
这行下面的,就说明是已暂存状态。 如果此时提交,那么该文件在你运行git add
时的版本将被留存在后续的历史记录中。 git add
命令使用文件或目录的路径作为参数;如果参数是目录的路径,该命令将递归地跟踪该目录下的所有文件。
现在我们来修改一个已被跟踪的文件。 如果你修改了一个名为 CONTRIBUTING.md 的已被跟踪的文件,然后运行 git status 命令,会看到下面内容:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
文件CONTRIBUTING.md
出现在Changes not staged for commit
这行下面,说明已跟踪文件的内容发生了变化,但还没有放到暂存区。 要暂存这次更新,需要运行git add
命令。 这是个多功能命令: 可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等。 将这个命令理解为**“精确地将内容添加到下一次提交中”**而不是“将一个文件添加到项目中”要更加合适。 现在让我们运行git add
将CONTRIBUTING.md
放到暂存区,然后再看看git status
的输出:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
如果此时再次修改CONTRIBUTING.md
文件,CONTRIBUTING.md
文件同时出现在暂存区和非暂存区:
$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
实际上 Git 只不过暂存了你运行 git add
命令时的版本。 如果你现在提交,CONTRIBUTING.md
的版本是你最后一次运行 git add
命令时的那个版本,而不是你运行 git commit
时,在工作目录中的当前版本。 所以,运行了git add
之后又作了修订的文件,需要重新运行git add
把最新版本重新暂存起来:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
#将文件移出暂存区
$ git reset HEAD <file>...
#对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它
$ git checkout -- <file>
一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等。 在这种情况下,我们可以创建一个名为.gitignore
的文件,列出要忽略的文件的模式。
文件 .gitignore 的格式规范如下:
#
开头的行都会被 Git 忽略。foldername
会匹配*/foldername
、*/*/foldername
/
开头防止递归。/
结尾指定目录。!
取反。*
匹配零个或多个任意字符;[abc]
匹配任何一个列在方括号中的字符;?
只匹配一个任意字符;[0-9]
表示匹配所有0 到9的数字)。**
表示匹配任意中间目录(多级目录),比如a/**/z
可以匹配a/z
、 a/b/z
或 a/b/c/z
等。此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。 也就是修改之后还没有暂存起来的变化内容。
#比较工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后还没有暂存起来的变化内容
$ git diff
#比对已暂存文件与最后一次提交的文件差异
$ git diff --staged [file]
# 显示暂存区和最后一次提交的差异 ( --staged 和 --cached 是同义词)
$ git diff --cached [file]
# 显示工作区与当前分支最新commit之间的差异
$ git diff HEAD
# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]
# 显示今天你写了多少行代码
$ git diff --shortstat "@{0 day ago}"
# 提交暂存区到仓库区
$ git commit -m [message]
# 提交暂存区的指定文件到仓库区
$ git commit [file1] [file2] ... -m [message]
要在提交的时候,给 git commit
加上 -a
选项,Git 就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过 git add 步骤:
# 提交工作区自上次commit之后的变化,直接到仓库区
$ git commit -a
# 提交时显示所有diff信息
$ git commit -v
重新提交上一次提交使用--amend
# 使用一次新的commit,替代上一次提交
# 如果代码没有任何新变化,则用来改写上一次commit的提交信息
$ git commit --amend -m [message]
# 重做上一次commit,并包括指定文件的新变化
$ git commit --amend [file1] [file2] ...
要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。可以用 git rm 命令完成此项工作,并连带从工作目录中删除指定的文件,这样以后就不会出现在未跟踪文件清单中了。
如果只是简单地从工作目录中手工删除文件,运行 git status 时就会在 “Changes not staged for commit” 部分(也就是 未暂存清单)。
如果要删除之前修改过或已经放到暂存区的文件,则必须使用强制删除选项 -f
(译注:即 force 的首字母)。 这是一种安全特性,用于防止误删尚未添加到快照的数据,这样的数据不能被 Git 恢复。
另外一种情况是,我们想把文件从 Git 仓库中删除(亦即从暂存区域移除),但仍然希望保留在当前工作目录中。 换句话说,你想让文件保留在磁盘,但是并不想让 Git 继续跟踪。 当你忘记添加 .gitignore
文件,不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时,这一做法尤其有用。 为达到这一目的,使用 --cached
选项:
# 删除工作区文件,并且将这次删除放入暂存区
$ git rm [-f] [file1] [file2] ...
# 停止追踪指定文件,但该文件会保留在工作区
$ git rm --cached [file]
# git rm 命令后面可以列出文件或者目录的名字,也可以使用 glob 模式。比如:
$ git rm log/\*.log
#注意到星号 * 之前的反斜杠 \, 因为 Git 有它自己的文件模式扩展匹配方式,所以我们不用 shell 来帮忙展开。 此命令删除 log/ 目录下扩展名为 .log 的所有文件。
# 改名文件,并且将这个改名放入暂存区
$ git mv [file-original] [file-renamed]
#添加一个新的远程 Git 仓库,同时指定一个方便使用的简写
$ git remote add <shortname> <url>
# 显示所有远程仓库的简写及其链接
$ git remote -v
# 显示某个远程仓库的信息
$ git remote show [remote]
如果你已经克隆了自己的仓库,那么至少应该能看到origin
——这是 Git 给你克隆的仓库服务器的默认名字。
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)
现在你可以在命令行中使用简写pb
来代替整个 URL。
#下载远程仓库的所有变动, 执行完成后,你将会拥有那个远程仓库中所有分支的引用,可以随时合并或查看。
$ git fetch [remote] [远程分支名]:[本地分支名]
# 取回远程仓库的变化,并与本地分支合并,相当于从远程仓库获得最新版本并merge到本地。
$ git pull [remote] [远程分支名]:[本地分支名]
上述命令其实相当于git fetch
加 git merge
# 上传本地指定分支到远程仓库
$ git push [remote] [本地分支名]:[远程分支名]
# 强行推送当前分支到远程仓库,即使有冲突
$ git push [remote] --force
# 推送所有分支到远程仓库
$ git push [remote] --all
# 修改一个远程仓库的简写名
$ git remote rename pb paul
#解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。
$ git remote rm [remote]
# 列出所有tag
$ git tag
# 按照通配符列出标签需要-l或--list
$ git tag -l "v1.8*"
# 查看tag信息
$ git show [tag]
Git 支持两种标签:轻量标签(lightweight)与附注标签(annotated)。
轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。
附注标签是存储在 Git 数据库中的一个完整对象, 它们是可以被校验的,其中包含打标签者的名字、电子邮件地址、日期时间, 此外还有一个标签信息,并且可以使用 GNU Privacy Guard (GPG)签名并验证。 通常会建议创建附注标签,这样你可以拥有以上所有信息。但是如果你只是想用一个临时的标签, 或者因为某些原因不想要保存这些信息,那么也可以用轻量标签。
# 新建一个tag在当前commit
$ git tag -a [tag] -m "message"
# 新建一个tag在指定commit
$ git tag -a [tag] -m "message" [commit]
-m
选项指定了一条将会存储在标签中的信息。
通过使用 git show
命令可以看到标签信息和与之对应的提交信息:
另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。 创建轻量标签,不需要使用 -a、-s 或 -m 选项,只需要提供标签名字:
# 新建一个tag在当前commit
$ git tag [tag]
# 新建一个tag在指定commit
$ git tag [tag] [commit]
# 删除本地tag
$ git tag -d [tag]
# 删除远程tag,下面这种操作的含义是,将冒号前面的空值推送到远程标签名,从而高效地删除它。
$ git push [remote] :refs/tags/<tagName>
# 第二种更直观的删除远程标签的方式是:
$ git push [remote] --delete <tagname>
# 提交指定tag
$ git push [remote] [tag]
# 提交所有tag
$ git push [remote] --tags
# 新建一个分支,指向某个tag
$ git checkout -b [branch] [tag]
# 列出所有本地分支
$ git branch
# 显示每一个分支最后一次提交的详细信息
$ git branch -v
# 查看已经合并到当前分支的分支
$ git branch --merged
# 查看尚未合并到当前分支的分支
$ git branch --no-merged
# 列出所有远程分支
$ git branch -r
# 列出所有本地分支和远程分支
$ git branch -a
# 新建一个分支,但依然停留在当前分支
$ git branch [branch-name]
# 新建一个分支,指向指定commit
$ git branch [branch] [commit]
从一个远程跟踪分支检出一个本地分支会自动创建所谓的“跟踪分支”(它跟踪的分支叫做“上游分支”)。 跟踪分支是与远程分支有直接关系的本地分支。 如果在一个跟踪分支上输入 git pull,Git 能自动地识别去哪个服务器上抓取、合并到哪个分支。
当克隆一个仓库时,它通常会自动地创建一个跟踪origin/master
的master
分支。 然而,如果你愿意的话可以设置其他的跟踪分支,或是一个在其他远程仓库上的跟踪分支,又或者不跟踪master
分支。 最简单的实例就是像之前看到的那样,运行git checkout -b <branch> <remote>/<branch>
。
# 从远程分支检出一个本地分支
$ git checkout -b <branch> <remote>/<branch>
$ git checkout --track <remote>/<branch>
# 新建一个分支,与指定的远程分支建立追踪关系
$ git branch --track [branch] [remote/branch]
设置已有的本地分支跟踪一个刚刚拉取下来的远程分支,或者想要修改正在跟踪的上游分支, 你可以在任意时间使用-u
或--set-upstream-to
选项运行git branch
来显式地设置。
# 建立追踪关系,在现有分支与指定的远程分支之间
$ git branch --set-upstream [branch] [remote/branch]
# 切换到指定分支,并更新工作区
$ git checkout [branch-name]
# 切换到上一个分支
$ git checkout -
$ git checkout -b [branch]
是下面两条命令的简写:
$ git branch [branch]
$ git checkout [branch]
# 删除分支
$ git branch -d [branch-name]
# 删除远程分支
$ git push [remote] --delete [branch-name]
$ git branch -dr [remote/branch]
$ git branch -m 原分支名称 新分支名称
# 合并指定分支到当前分支
$ git merge [branch]
# 出现fatal: 拒绝合并无关的历史时,可以使用如下命令
$ git merge [branch] --allow-unrelated-histories
# 选择一个commit,合并进当前分支
$ git cherry-pick [commit]
有时候合并操作不会如此顺利。 如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们。
此时 Git 做了合并,但是没有自动地创建一个新的合并提交。 Git 会暂停下来,等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并(unmerged)状态的文件:
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
任何因包含合并冲突而有待解决的文件,都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记,这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段,看起来像下面这个样子:
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
由=======
来分割冲突的两部分。为了解决冲突,你必须选择使用由 =======
分割的两部分中的一个,或者你也可以自行合并这些内容。 例如,你可以通过把这段内容换成下面的样子来解决冲突:
<div id="footer">
please contact us at email.support@github.com
</div>
上述的冲突解决方案仅保留了其中一个分支的修改,并且 <<<<<<<
, =======
, 和 >>>>>>>
这些行被完全删除了。 在你解决了所有文件里的冲突之后,对每个文件使用git add
命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件,Git 就会将它们标记为冲突已解决。
如果你想使用图形化工具来解决冲突,你可以运行git mergetool
,该命令会为你启动一个合适的可视化合并工具,并带领你一步一步解决这些冲突:
$ git mergetool
git submodule add <url> <path>
url
为想要添加的子模块路径path
为子模块存放的本地路径命令执行完会自动生成 .gitmodules
里的内容并clone子模块代码
git submodule init
读取.gitmodules
文件并初始化本地配置文件.git/config
和.git/module
git submodule update --remote
不带--remote
的update
只会在本地没有子模块或它的文件夹为空时才有效
git submodule deinit <path> #如果添加上参数 -f,则子模块工作区内即使有本地的修改,也会被移除:
git rm <path> #自动在.gitmodules中删除了子模块相关内容
其中<path>
表示submodule的路径
clone
父仓库时加上--recursive
,会自动初始化并更新仓库中的每一个子模块
git clone --recursive
等效的做法
git clone
git submodule update --init --recursive
git submodule set-url <path> <url>
# 生成一个可供发布的压缩包
$ git archive
$ git remote set-url [remote] https://<your_token>@github.com/<USERNAME>/<REPO>.git
将<your_token>
换成你自己得到的令牌。<USERNAME>
是你自己github的用户名,<REPO>
是你的项目名称。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。