git

1. 环境配置

git config --system  （系统中对所有用户都普遍适用的配置 /etc/gitconfig）

git config --global （用户目录下的配置文件，只适用于该用户 ~/.gitconfig）

当前项目的git目录中的配置文件（工作目录中的.git/config文件）：仅仅针对当前项目有效，每个级别覆盖上层的相同配置，所以.git/config里的配置会覆盖/etc/gitconfig中同名的变量

在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是C:\Documents and Settings\$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位

$ git config --global user.name "John Doe"

$ git config --global user.email johndoe@example.com

如果用了 --global选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 --global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。

差异分析工具

还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：

$ git config --global merge.tool vimdiff

Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合并工具的输出信息。当然，你也可以指定使用自己开发的工具，具体怎么做可以参阅第七章。

查看配置

git config --list

取得项目的仓库

有两种取得 Git 项目仓库的方法。第一种是在现存的目录下，通过导入所有文件来创建新的 Git 仓库。第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。

在工作目录中初始化新仓库

$ git init

$git add .

$git commit -m 'initial project version'

 

从现有仓库克隆

git clone [url]

$ git clone git://github.com/schacon/grit.git

这会在当前目录下创建一个名为grit的目录，其中包含一个 .git 的目录，用于保存下载下来的所有版本记录，然后从中取出最新版本的文件拷贝。如果进入这个新建的 grit 目录，你会看到项目中的所有文件已经在里边了，准备好后续的开发和使用。如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：

$ git clone git://github.com/schacon/grit.git mygrit

唯一的差别就是，现在新建的目录成了mygrit，其他的都和上边的一样。

Git 支持许多数据传输协议。之前的例子使用的是git:// 协议，不过你也可以用 http(s):// 或者 user@server:/path.git 表示的 SSH 传输协议。我们会在第四章详细介绍所有这些协议在服务器端该如何配置使用，以及各种方式之间的利弊。

 

查看提交历史

git log：按提交时间列出所有的更新，最近的更新排在最上面

git log -p -2：-p选项展开显示每次提交的内容差异， -2仅显示最近的两次更新

git log --stat ：仅显示简要的增改行数统计

git log -U1 --word-diff ：这里并没有平常看到的添加行或者删除行的信息。这里的对比显示在行间。新增加的单词被 {+ +}括起来，被删除的单词被 [- -]括起来。在进行单词层面的对比的时候，你可能希望上下文（ context ）行数从默认的 3 行，减为 1 行，那么可以使用 -U1 选项

--pretty：可以指定使用完全不同于默认格式的方式展示提交历史，online将每个提交放在一行显示 （short , full , fuller）

　　　　format：定制显示的记录格式

        　　--graph， 可以看到开头简单图形，展示了每个提交这所在分支及其分化衍合情况

 

撤销操作

修改最后一次提交：想要撤消刚才的提交操作，使用 --amend（git commit --amend）

$ git commit -m 'initial commit'

$ git add forgotten_file

$ git commit --amend

取消已经暂存的文件：git reset HEAD 

取消对文件的修改：git checkout -- 

远程仓库的使用

查看当前的远程库：git remote（列出每个远程库的简短名字）默认使用origin名字标志克隆的原始仓库

　　　　　　　　　git remote -v（--verbose）显示对应的克隆地址

添加远程仓库

git remote add  [shortname]   [url]

指代对应的仓库地址,抓取所有paul有的，git fetch pb

从远程仓库抓取数据

从远程仓库抓取数据到本地：git fetch [remote-name]（拉取所本地仓库中没有的数据）

如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。所以，git fetch origin 会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch 以来别人提交的更新）。有一点很重要，需要记住，fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。

如果设置了某个分支用于跟踪某个远端仓库的分支（参见下节及第三章的内容），可以使用git pull命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用，既快且好。实际上，默认情况下 git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支（假设远程仓库确实有 master 分支）。所以一般我们运行 git pull，目的都是要从原始克隆的远端仓库中抓取数据后，合并到工作目录中的当前分支。

推送数据到远程仓库

git push [remote-name]  [branch-name]

如果把本地的master分支推送到origin服务器上（克隆操作会自动使用默认的master和origin名字）: git push origin master

（只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送。有关推送数据到远程仓库的详细内容见第三章。）

查看远程仓库信息

查看某个远程仓库的详细信息：git remote show [remote-name]

远程仓库的删除和重命名：git remote rename   eg:git remote rename pb paul（会使对应的分支名称发生变化）

移除对应的远端仓库:git remote rm [name]

打标签（对某一时间点上的版本打上标签）

列显已有的标签：git tag （按字母顺序排列）

特定的搜索模式列出符合条件的标签：git tag -l 'v1.4.2.*'

新建标签：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签，以便保留相关信息；当然，如果只是临时性加注标签，或者不需要旁注额外信息，用轻量级标签也没问题。

含附注的标签：git tag -a v1.4 -m 'my version 1.4'  -m 选项则指定了对应的标签说明， git 会将此说明一同保存在标签对象中，

查看相应标签的版本信息： git show v1.4

签署标签： 如果你有自己的私钥，还可以用 GPG 来签署标签，只需要把之前的 -a 改为 -s（译注： 取 signed 的首字母）即可:git tag -s v1.5 -m 'my signed 1.5 tag'

轻量级标签：保存着对应提交对象的校验和信息的文件，直接给出标签名字即可：git tag v1.4 -lw

git 技巧和窍门

自动补全：

如果你用的是 Bash shell，可以试试看 Git 提供的自动补全脚本。下载 Git 的源代码，进入 contrib/completion 目录，会看到一个git-completion.bash 文件。将此文件复制到你自己的用户主目录中（译注：按照下面的示例，还应改名加上点：cp git-completion.bash ~/.git-completion.bash），并把下面一行内容添加到你的.bashrc 文件中：

source ~/.git-completion.bash
也可以为系统上所有用户都设置默认使用此脚本。Mac 上将此脚本复制到 /opt/local/etc/bash_completion.d目录中，Linux 上则复制到 /etc/bash_completion.d/ 目录中。这两处目录中的脚本，都会在 Bash 启动时自动加载。

如果在 Windows 上安装了 msysGit，默认使用的 Git Bash 就已经配好了这个自动补全脚本，可以直接使用。

在输入 Git 命令的时候可以敲两次跳格键（Tab），就会看到列出所有匹配的可用命令建议：

$ git co<tab><tab>
commit config

此例中，键入 git co 然后连按两次 Tab 键，会看到两个相关的建议（命令） commit和 config。继而输入m<tab>会自动完成git commit命令的输入。

命令的选项也可以用这种方式自动完成，其实这种情况更实用些。比如运行 git log 的时候忘了相关选项的名字，可以输入开头的几个字母，然后敲 Tab 键看看有哪些匹配的：

$ git log --s<tab>
--shortstat  --since=  --src-prefix=  --stat   --summary

这个技巧不错吧，可以节省很多输入和查阅文档的时间。

git 命令别名：

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 commit 只需键入 git ci 即可。而随着 Git 使用的深入，会有很多经常要用到的命令，遇到这种情况，不妨建个别名提高效率。

使用这种技术还可以创造出新的命令，比方说取消暂存文件时的输入比较繁琐，可以自己设置一下：

$ git config --global alias.unstage 'reset HEAD --'
这样一来，下面的两条命令完全等同：

$ git unstage fileA
$ git reset HEAD fileA

显然，使用别名的方式看起来更清楚。另外，我们还经常设置 last命令：

$ git config --global alias.last 'log -1 HEAD'
然后要看最后一次的提交信息，就变得简单多了：

$ git last
commit 66938dae3329c7aebe598c2246a8e6af90d04646
Author: Josh Goebel <dreamer3@example.com>
Date:   Tue Aug 26 19:48:51 2008 +0800

    test for current head
    Signed-off-by: Scott Chacon <schacon@example.com>

可以看出，实际上 Git 只是简单地在命令中替换了你设置的别名。不过有时候我们希望运行某个外部命令，而非 Git 的子命令，这个好办，只需要在命令前加上 ! 就行。如果你自己写了些处理 Git 仓库信息的脚本的话，就可以用这种技术包装起来。作为演示，我们可以设置用git visual启动 gitk：

$ git config --global alias.visual '!gitk'

 

分支

新建分支：git branch name

切换分支：git checkout name

 

git checkout -b name    ==>  git branch name   git checkout name

合并分支：git checkout master,    git merge hotfix   

删掉分支：git branch -d hotfix

遇到冲突时的分支合并：如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来裁决。）

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用 git status 查阅：

$ 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")

任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：

<<<<<<< HEAD
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
  please contact us at support@github.com
</div>
>>>>>>> iss53

可以看到=======隔开的上半部分，是 HEAD（即 master 分支，在运行 merge 命令时所切换到的分支）中的内容，下半部分是在 iss53 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：

<div id="footer">
please contact us at email.support@github.com
</div>

这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了 <<<<<<<，======= 和>>>>>>> 这些行。在解决了所有文件里的所有冲突后，运行 git add将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行 git mergetool，它会调用一个可视化的合并工具并引导你解决所有冲突：

$ git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html

Normal merge conflict for 'index.html':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (opendiff):

如果不想用默认的合并工具（Git 为我默认选择了 opendiff，因为我在 Mac 上运行了该命令），你可以在上方"merge tool candidates"里找到可用的合并工具列表，输入你想用的工具名。我们将在第七章讨论怎样改变环境中的默认值。

退出合并工具以后，Git 会询问你合并是否成功。如果回答是，它会为你把相关文件暂存起来，以表明状态为已解决。

再运行一次 git status 来确认所有冲突都已解决：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   index.html

如果觉得满意了，并且确认所有冲突都已解决，也就是进入了暂存区，就可以用 git commit 来完成这次合并提交。提交的记录差不多是这样：

Merge branch 'iss53'

Conflicts:
  index.html

 It looks like you may be committing a merge.
 If this is not correct, please remove the file
       .git/MERGE_HEAD
 and try again.

如果想给将来看这次合并的人一些方便，可以修改该信息，提供更多合并细节。比如你都作了哪些改动，以及这么做的原因。有时候裁决冲突的理由并不直接或明显，有必要略加注解。

管理分支

给出当前所有分支的清单：git branch

查看各个分支最后一个提交对象的信息：git branch -v

查看哪些分支已经或尚未与当前分支合并：git branch --merged    git branch --no-merged

推送本地分支

git push （远程仓库名） （分支名）

eg: git push origin serverfix   ===>  git push origin serverfix:serverfix

把本地分支推送发哦某个命名不同的远程分支：若想把远程分支叫作awesomebranch可以用git push origin serverfix:awesomebranch

协作者再次从服务器上获取数据时， 得到一个新的远程分支origin/serverfix，并指向服务器上的serverfix所指向的版本：git fetch origin

在fetch操作下载好新的远程分支后，仍然无法在本地编辑该远程仓库中的分支，意思是你不会有一个新的serverfix分支， 有的只是一个无法移动的origin/serverfix指针

把远程分支的内容合并到当前分支， git merge origin/serverfix

想要一份自己的serverfix来开发， 可以在远程分支的基础上分化出一个新的分支来：git checkout -b serverfix origin/serverfix（切换到新建的serverfix本地分支，其内容同远程分支origin/serverfix一致，可以继续开发了）

跟踪远程分支

从远程分支 checkout 出来的本地分支，称为 跟踪分支 (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。在跟踪分支里输入 git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样，在这些分支里运行 git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来。

在克隆仓库时，Git 通常会自动创建一个名为 master 的分支来跟踪 origin/master。这正是 git push 和 git pull 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如 origin 上除了 master 之外的其它分支。刚才我们已经看到了这样的一个例子：git checkout -b [分支名] [远程名]/[分支名]。如果你有 1.6.2 以上版本的 Git，还可以用 --track 选项简化：

$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

要为本地分支设定不同于远程分支的名字，只需在第一个版本的命令里换个名字：

$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'

现在你的本地分支 sf 会自动将推送和抓取数据的位置定位到 origin/serverfix 了。

 删除远程分支

如果不再需要某个远程分支了，比如搞定了某个特性并把它合并进了远程的 master 分支（或任何其他存放稳定代码的分支），可以用这个非常无厘头的语法来删除它：git push [远程名] :[分支名]。如果想在服务器上删除 serverfix 分支，运行下面的命令：

$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
 - [deleted]         serverfix

咚！服务器上的分支没了。你最好特别留心这一页，因为你一定会用到那个命令，而且你很可能会忘掉它的语法。有种方便记忆这条命令的方法：记住我们不久前见过的 git push [远程名] [本地分支]:[远程分支] 语法，如果省略 [本地分支]，那就等于是在说“在这里提取空白然后把它变成[远程分支]”。

 git 分支的衍合（merge/rebase）

 

 

 基本操作

当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 "git reset HEAD" 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 "git rm --cached <file>" 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 "git checkout ." 或者 "git checkout -- <file>" 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。

当执行 "git checkout HEAD ." 或者 "git checkout HEAD <file>" 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

 git rm 将文件从缓存区中移除。

 git mv 命令做得所有事情就是 git rm --cached， 重命名磁盘上的文件，然后再执行 git add 把新文件添加到缓存区。因此，虽然有 git mv 命令，但它有点多余 。

 

执行 git diff 来查看执行 git status 的结果的详细信息。

git diff 命令显示已写入缓存与已修改但尚未写入缓存的改动的区别。git diff 有两个主要的应用场景。

• 尚未缓存的改动：git diff
• 查看已缓存的改动： git diff --cached
• 查看已缓存的与未缓存的所有改动：git diff HEAD
• 显示摘要而非整个 diff：git diff --stat

在 hello.php 文件中输入以下内容：