Git Pro.1

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置：
/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。 如果使用带有 --system 选项的 git config 时，它会从此文件读写配置变量。
~/.gitconfig 或 ~/.config/git/config 文件：只针对当前用户。 可以传递 --global 选项让 Git 读写此文件。
当前使用仓库的 Git 目录中的 config 文件（就是 .git/config）：针对该仓库。
每一个级别覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。
在Windows系统中，Git会查找$HOME目录下（一般情况下是 C:\Users\$USER）的.gitconfig文件;同样也会寻找/etc/gitconfig文件，但只限于安装Git时所选的目标位置根目录下。


如果想要检查你的配置，可以使用 git config --list 命令来列出所有 Git 当时能找到的配置(可能会看到重复的变量名，因为Git会从不同的文件中读取同一个配置(例如：/etc/gitconfig 与 ~/.gitconfig)这种情况下，Git会使用它找到的每一个变量的最后一个配置)
可以通过输入 git config <key>： 来检查 Git 的某一项配置(如：git config user.name)


若你使用 Git 时需要获取帮助，有三种方法可以找到 Git 命令的使用手册：
$ git help <verb>
$ git <verb> --help
$ man git-<verb>


git add是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态.
如果你使用 git status -s 命令或 git status --short 命令，你将得到一种更为紧凑的格式输出.(新添加的未跟踪文件前面有 ?? 标记，新添加到暂存区中的文件前面有 A 标记，出现在右边的 M 表示该文件被修改了但是还没放入暂存区，出现在靠左边的 M 表示该文件被修改了并放入了暂存区， MM是在工作区被修改并提交到暂存区后又在工作区中被修改了)


文件 .gitignore 的格式规范如下：
所有空行或者以 ＃ 开头的行都会被 Git 忽略。
可以使用标准的 glob 模式匹配。
匹配模式可以以（/）开头防止递归。
匹配模式可以以（/）结尾指定目录。
要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。
所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。 星号（*）匹配零个或多个任意字符；[abc] 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。 使用两个星号（*) 表示匹配任意中间目录，比如a/**/z 可以匹配 a/z, a/b/z 或 a/b/c/z等。
GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表，你可以在 https://github.com/github/gitignore 找到它
例子：
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the TODO file in the current directory, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .pdf files in the doc/ directory
doc/**/*.pdf


要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff 此命令比较的是工作目录中当前文件和暂存区域快照之间的差异
若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --cached 命令(Git 1.6.1 及更高版本还允许使用 git diff --staged，效果是相同的，但更好记些)
如果你喜欢通过图形化的方式或其它格式输出方式的话，可以使用 git difftool 命令来用 Araxis ，emerge 或 vimdiff 等软件输出 diff 分析结果。 使用 git difftool --tool-help 命令来看你的系统支持哪些 Git Diff 插件。


git commit这种方式会启动文本编辑器以便输入本次提交的说明，可以用 -v 选项，这会将你所做的改变的 diff 输出放到编辑器中从而使你知道本次提交具体做了哪些修改。
另外，你也可以在 commit 命令后添加 -m 选项，将提交信息与命令放在同一行。
只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤。


要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是 未暂存清单）看到，运行 git rm filename记录此次移除文件的操作，下一次提交时，该文件就不再纳入版本管理了。
如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（译注：即 force 的首字母）。
另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中，使用git rm --cached filename
git rm log/\*.log 注意到星号 * 之前的反斜杠 \， 因为 Git 有它自己的文件模式扩展匹配方式，所以我们不用 shell 来帮忙展开。 此命令删除 log/ 目录下扩展名为 .log 的所有文件。


要在 Git 中对文件改名，可以这么做git mv file_from file_to 
其实，就相当于运行了下面三条命令:
$ mv file_from file_to 
$ git rm file_from
$ git add file_to


git log 有许多选项可以帮助你搜寻你所要找的提交,一个常用的选项是 -p，用来显示每次提交的内容差异。 你也可以加上 -(n) 来仅显示最近n次提交: git log -p -2
如果你想看到每次提交的简略的统计信息，你可以使用 git log --stat
另外还有按照时间作限制的选项，比如 --since 和 --until 也很有用,例如：git log --since=2.weeks 列出所有最近两周内的提交，这个命令可以在多种格式下工作，比如说具体的某一天 "2008-01-15"，或者是相对地多久以前 "2 years 1 day 3 minutes ago"。
用 --author 选项显示指定作者的提交，用 --grep 选项搜索提交说明中的关键字。 （请注意，如果要得到同时满足这两个选项搜索条件的提交，就必须用 --all-match 选项。否则，满足任意一个条件的提交都会被匹配出来）
另一个非常有用的筛选选项是 -S，可以列出那些添加或移除了某些字符串的提交。 比如说，你想找出添加或移除了某一个特定函数的引用的提交，你可以这样使用：$ git log -Sfunction_name
最后一个很实用的 git log -- 路径(path)， 如果只关心某些文件或者目录的历史提交，可以在 git log 选项的最后指定它们的路径。 因为是放在最后位置上的选项，所以用两个短划线（--）隔开之前的选项和后面限定的路径名。例如：git log -- device/
另外一个常用的选项是 --pretty 这个选项可以指定使用不同于默认格式的方式展示提交历史。 这个选项有一些内建的子选项供你使用。 比如用 oneline 将每个提交放在一行显示，查看的提交数很大时非常有用。 另外还有 short，full 和 fuller 可以用,但最有意思的是 format，可以定制要显示的记录格式。 这样的输出对后期提取分析格外有用?—?因为你知道输出的格式不会随着Git的更新而发生改变：
git log --pretty=format 常用的选项:
%H  提交对象（commit）的完整哈希字串
%h  提交对象的简短哈希字串
%T  树对象（tree）的完整哈希字串
%t  树对象的简短哈希字串
%P  父对象（parent）的完整哈希字串
%p  父对象的简短哈希字串
%an 作者（author）的名字
%ae 作者的电子邮件地址
%ad 作者修订日期（可以用 --date= 选项定制格式）
%ar 作者修订日期，按多久以前的方式显示
%cn 提交者(committer)的名字
%ce 提交者的电子邮件地址
%cd 提交日期
%cr 提交日期，按多久以前的方式显示
%s  提交说明
你一定奇怪 作者 和 提交者 之间究竟有何差别， 其实作者指的是实际作出修改的人，提交者指的是最后将此工作成果提交到仓库的人。
当 oneline 或 format 与另一个 log 选项 --graph 结合使用时尤其有用。 这个选项添加了一些ASCII字符串来形象地展示你的分支、合并历史.


git log 的常用选项:
-p              按补丁格式显示每个更新之间的差异。
--stat          显示每次更新的文件修改统计信息。
--shortstat     只显示 --stat 中最后的行数修改添加移除统计。
--name-only     仅在提交信息后显示已修改的文件清单。
--name-status   显示新增、修改、删除的文件清单。
--abbrev-commit 仅显示 SHA-1 的前几个字符，而非所有的 40 个字符。
--relative-date 使用较短的相对时间显示（比如，“2 weeks ago”）。
--graph         显示 ASCII 图形表示的分支合并历史。
--pretty        使用其他格式显示历史提交信息。可用的选项包括 oneline，short，full，fuller 和 format（后跟指定格式）。
-(n)  仅显示最近的 n 条提交
--since, --after 仅显示指定时间之后的提交。
--until, --before仅显示指定时间之前的提交。
--author 仅显示指定作者相关的提交。
--committer 仅显示指定提交者相关的提交。
--grep 仅显示含指定关键字的提交
-S 仅显示添加或移除了某个关键字的提交


撤消操作
有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令尝试重新提交：git commit --amend 这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息,文本编辑器启动后，可以看到之前的提交信息,编辑后保存会覆盖原来的提交信息。
例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
最终你只会有一个提交 - 第二次提交将代替第一次提交的结果。

取消暂存的文件使用 git reset HEAD <file>   (虽然在调用时加上 --hard 选项可以令 git reset 成为一个危险的命令（译注：可能导致工作目录中所有当前进度丢失！）,不加选项地调用 git reset 并不危险 — 它只会修改暂存区域。)
撤消对文件的修改使用 git checkout -- <file> (这是一个危险的命令，你对那个文件做的任何修改都会消失，你只是拷贝了另一个文件来覆盖它)


远程仓库的使用
如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写.默认情况下，git clone命令会自动设置本地master分支跟踪克隆的远程仓库的 master分支（或不管是什么名字的默认分支）.(如果你运行git clone -o booyah ，那么你默认的远程分支名字将会是 booyah/master)
如果想查看你已经配置的远程仓库服务器，可以运行 git remote命令(它会列出你指定的每一个远程服务器的简写),也可以指定选项 -v，git remote -v 会显示需要读写远程仓库使用的Git保存的简写与其对应的URL.
可以通过 git ls-remote [remote] 来显式地获得远程引用的完整列表，或者通过 git remote show [remote] 获得远程分支的更多信息.
添加远程仓库,运行 git remote add <shortname> <url> 添加一个新的远程 Git 仓库，同时指定一个你可以轻松引用的简写.
git fetch [remote-name] 会抓取克隆（或上一次抓取）后新推送的所有工作。 必须注意 git fetch 命令会将数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作,你必须手动将其合并入你的工作。
可以使用 git pull 命令来自动的抓取然后合并远程分支到当前分支.(git pull 在大多数情况下它的含义是一个 git fetch 紧接着一个 git merge origin/branch命令)
要特别注意的一点是当git fetch [remote-name]抓取到新的远程跟踪分支时，本地不会自动生成一个新的分支，只有一个不可以修改的 origin/newbranch指针。可以运行 git merge origin/newbranch将这些工作合并到当前所在的分支。 如果想要在本地建立newbranch分支上工作，可以使用：$ git checkout -b newbranch origin/newbranch.
git push [remote-name] [branch-name] 推送到远程仓库,只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。 当他人先推送,然后你再推送，你的推送就会毫无疑问地被拒绝。 你必须先将他们的工作拉取下来并将其合并进你的工作后才能推送.
例如：$ git push origin serverfix 这里有些工作被简化了。 Git 自动将 serverfix 分支名字展开为 refs/heads/serverfix:refs/heads/serverfix，那意味着，“推送本地的 serverfix 分支来更新远程仓库上的 serverfix 分支。” 你也可以运行 git push origin serverfix:serverfix，它会做同样的事，“推送本地的 serverfix 分支，将其作为远程仓库的 serverfix 分支” 可以通过这种格式来推送本地分支到一个命名不相同的远程分支。 如果并不想让远程仓库上的分支叫做 serverfix，可以运行 git push origin serverfix:awesomebranch 来将本地的 serverfix 分支推送到远程仓库上的 awesomebranch 分支。
git checkout -b [branch] [remotename]/[branch] (本地分支与远程分支可设置为不同名字) Git提供了快捷方式git checkout --track origin/branch(本地分支与远程分支同名字).
设置已有的本地当前分支跟踪一个刚刚拉取下来的远程分支，或者想要修改正在跟踪的上游分支，你可以使用git branch -u origin/branch或git branch --set-upstream-to origin/branch来设置.
当设置好跟踪分支后，可以通过 @{upstream} 或 @{u} 快捷方式来引用它。 所以在 master 分支时并且它正在跟踪 origin/master 时，如果愿意的话可以使用 git merge @{u} 来取代 git merge origin/master。
如果想要查看设置的所有跟踪分支，可以使用 git branch -vv (需要重点注意的一点是这些数字的值来自于你从每个服务器上最后一次抓取的数据。这个命令并没有连接服务器，它只会告诉你关于本地缓存的服务器数据。如果想要统计最新的领先与落后数字，需要在运行此命令前抓取所有的远程仓库。可以这样做：$ git fetch --all  $ git branch -vv)
如果想要重命名引用的名字可以运行 git remote rename old_name new_name去修改一个远程仓库的简写名.
如果因为一些原因想要移除一个远程仓库,可以使用 git remote rm <remote-name>
删除远程分支 git push origin --delete <branchname>




标签
Git使用两种主要类型的标签：轻量标签（lightweight）与附注标签（annotated）。一个轻量标签很像一个不会改变的分支 - 它只是一个特定提交的引用。然而，附注标签是存储在 Git 数据库中的一个完整对象。 它们是可以被校验的；其中包含打标签者的名字、电子邮件地址、日期时间；还有一个标签信息；并且可以使用 GNU Privacy Guard （GPG）签名与验证。
git tag列出已有的标签，也可以使用特定的模式查找标签。 例如，Git 自身的源代码仓库包含标签的数量超过 500 个。 如果只对 1.8.5 系列感兴趣，可以运行：$ git tag -l 'v1.8.5*'
git show tagname 查看标签信息
创建一个附注标签是很简单的。 最简单的方式是当你在运行 tag 命令时指定 -a 选项：$ git tag -a v1.4 -m 'my version 1.4' -m选项指定了一条将会存储在标签中的信息。如果没有为附注标签指定一条信息，Git 会运行编辑器要求你输入信息。
另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中,没有保存任何其他信息。创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：git tag <tagname>.
也可以对过去的提交打标签 $ git tag -a tagname commit_id 或 $ git tag tagname commit_id.
默认情况下，git push 命令并不会传送标签到远程仓库服务器上,可以运行 git push origin <tagname>推送标签到远程仓库服务器上,如果想要一次性推送很多标签，也可以使用git push origin --tags.
可以使用 git checkout -b <branchname> <tagname> 在特定的标签上创建一个新分支.


别名
如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。 这里有一些例子你可以试试：
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
$ git config --global alias.unstage 'reset HEAD --' (这会使下面的两个命令等价：$ git unstage fileA === $ git reset HEAD -- fileA)
$ git config --global alias.last 'log -1 HEAD'
然而，你可能想要执行外部命令，而不是一个 Git 子命令。 如果是那样的话，可以在命令前面加入 ! 符号 例如：我们现在演示将 git visual 定义为 gitk 的别名：$ git config --global alias.visual '!gitk'


git分支
git branch <branchname>命令创建新分支.
git branch -d <branchname>命令删除分支.
可以简单地使用git log --oneline --decorate命令查看各个分支当前所指的对象.
要切换到一个已存在的分支，你需要使用 git checkout <branchname>命令(分支切换会改变你工作目录中的文件).
git log --oneline --decorate --graph --all命令会输出你的提交历史、各个分支的指向以及项目的分支分叉情况.
新建一个分支并同时切换到那个分支上:git checkout -b <branchname>.
合并分之：你只需要检出到你想合并入的分支，然后运行merge命令：例如：$ git checkout master  $ git merge test (将test分之修改合入master分支).
如果你想使用图形化工具来解决冲突，你可以运行 git mergetool. 等你退出合并工具之后，Git会询问刚才的合并是否成功,如果你回答是，Git会暂存那些文件以表明冲突已解决.你可以再次运行git status来确认所有的合并冲突都已被解决.
如果需要查看每一个分支的最后一次提交，可以运行 git branch -v 命令
如果要查看哪些分支已经合并到当前分支，可以运行 git branch --merged. 查看所有包含未合并工作的分支，可以运行 git branch --no-merged.
包含了还未合并的工作，尝试使用 git branch -d <branchname>命令删除它时会失败,如果真的想要删除分支并丢掉那些工作，可以使用git branch -d <branchname>强制删除它.


变基
它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master）的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 然后依次将之前另存为临时文件的修改依序应用。最后回到 master 分支，进行一次快进合并.
$ git checkout experiment
$ git rebase master
$ git checkout master
$ git merge experiment
(使用 git rebase [basebranch] [topicbranch] 命令可以直接将特性分支（即本例中的experiment）变基到目标分支（即 master）上,然后在快进合并主分支master了。这样做能省去你先切换到experiment分支，再对其执行变基命令的多个步骤。即当前分支在master可以如下操作：$ git rebase master experiment  $ git merge experiment)


$ git rebase --onto master server client 命令的意思是：“找出处于client分支和server分支的共同祖先之后在client分支上的修改，"续"在master分支上.


用变基解决变基
方法是使用 git pull --rebase 命令而不是直接 git pull。 又或者你可以自己手动完成这个过程，先 git fetch，再 git rebase origin/master.
(如果你习惯使用 git pull ，同时又希望默认使用选项 --rebase，你可以执行这条语句 git config --global pull.rebase true 来更改 pull.rebase 的默认配置)


总的原则是，只要你把变基命令当作是在推送前清理提交使之整洁的工具，并且只在从未推送至共用仓库的提交上执行变基命令，从不对已推送至别处的提交执行变基操作你就不会有事。