ch2 （《Git权威指南》阅读笔记）

2.1　每日工作备份

修改后提交，在本地完成。

$ git add -u    # 如果创建了新文件，可以执行 git add -i 命令。
$ git commit

下班前，执行推送操作，将在本地Git版本库中的提交同步到公司的Git服务器上。相当于图中的步骤① 。

$ git push

因为公司的Git服务器和异地数据中心的Git服务器建立了镜像，所以每当我向公司内网服务器推送的时候，就会自动触发从内网服务器到外网Git服务器的镜像操作。相当于图中的步骤②，步骤②是自动执行的，无须人工干预。图中标记为 mirror 的版本库就是Git镜像版本库，该版本库只向用户提供只读访问服务，而不能对其进行写操作（推送）。

2.2　异地协同工作

如果在家里有时间工作的话，首先要做的就是将mirror版本库中的数据同步到本地：

$ git pull mirror master

然后在家里的电脑上继续编写并提交。当准备完成一天的工作后，就执行下面的命令，将在家中的提交推送到标记为 home 的版本库中：

$ git push home

当一早到公司，先要从home版本库将家里做的提交同步到公司的电脑中：

$ git pull home master

2.3 现场版本控制

具体操作过程如下。 
（1）创建现场版本库。直接在需要版本控制的目录下执行 Git 版本库初始化命令。 

$ git init 

（2）添加文件并提交。 

$ git add -A 
$ git commit -m "initialized" 

（3）为初始提交建立一个里程碑：“v1”。 

$ git tag v1 

（4）开始在工作区中工作，修改文件并提交。 

$ git commit -a 

（5）当对修改结果满意并想将工作成果保存带走时，可以通过下面的命令将从 v1 开始的历次提交逐一导出为补丁文件。转换的补丁文件都包含一个数字前缀，并提取提交日志信息作为文件名，而且补丁文件还提供对二进制文件的支持。

$ git format-patch v1..HEAD 
0001-Fix-typo-help-to-help.patch 
0002-Add-I18N-support.patch 
0003-Translate-for-Chinese.patch 

（6）通过邮件将补丁文件发出。当然，也可以通过其他方式将补丁文件带走。 

$ git send-email *.patch 

Git 创建的补丁文件使用了 Git 扩展格式，因此在导入时为了避免数据遗漏，要使用 Git 提供的命令而不能使用 GNU的patch 命令。即使要导入的不是 Git 版本库，也可以使用 Git 命令。

2.5　重写提交说明

Git 修改提交说明很简单，而且提交说明的修改也是被追踪的。Git 修改最新提交的提交说明最为简单，使用一条名为修补提交的命令即可。 

$ git commit --amend 

这个命令如果不带-m参数，会进入提交说明编辑界面，修改原来的提交说明，直到满意为止。 
如果要修改某个历史提交的提交说明，Git 也可以实现，但要用到另外一个命令：变基命令。例如，要修改 <commit-id> 所标识的提交的提交说明，执行下面的命令，并在弹出的变基索引文件中修改相应提交前面的动作的关键字。 

$ git rebase -i <commit-id>^ 

2.6 想吃后悔药

如果你用Git，一切就会变得非常简单，而且你也不必去乞求管理员，因为使用 Git，每个人都是管理员。 
如果是最新的提交引入了不该提交的大文件：winxp.img，操作起来会非常简单，还是用修补提交命令。 

$ git rm --cached winxp.img 
$ git commit --amend 

如果是历史版本，例如是在<commit-id>所标识的提交中引入的文件，则需要使用变基操作。 

$ git rebase -i <commit-id>^ 

执行交互式变基操作抛弃历史提交，版本库还不能立即瘦身。除了使用变基操作，Git 还有更多的武器可以实现版本库的整理操作。

NOTE： 正确的版本控制系统的使用方法是，一次提交只干一件事：或是完成了一个新功能，或是修改了一个Bug、或是写完了一节的内容，或是添加了一幅图片，就执行一次提交。不要在下班时才想起来要提交，那样的话版本控制系统就被降格为文件备份系统了。

2.8　更好的差异比较

　　Git 对差异比较进行了扩展，支持对二进制文件的差异比较，这是对GNU的diff和patch命令的重要补充。而且Git 的差异比较除了支持基于行的差异比较外，还支持在一行内逐字比较的方式，当向 git diff 命令传递 --word-diff 参数时，就会进行逐字比较。 
　　上面介绍了工作区的文件修改可能会有两个不同的版本：一个在提交暂存区，一个在工作区。因此，在执行 git diff 命令时会遇到令 Git 新手费解的现象。 

• 　修改后的文件在执行 git diff 命令时会看到修改造成的差异。 
• 　修改后的文件通过 git add 命令提交到暂存区后，再执行 git diff 命令将看不到该文件的差异。 
• 　继续对此文件进行修改，再次执行 git diff 命令会看到新的修改显示在差异中，而看不到旧的修改。 
• 　执行 git diff --cached 命令才可以看到添加到暂存区中的文件所做出的修改。 

2.9　工作进度保存

如果在工作区的修改尚未完成时忽然有一个紧急的任务，需要从一个干净的工作区开始新的工作，或要切换到别的分支进行工作，那么如何保存当前尚未完成的工作进度呢？ 

Git 提供了一个可以保存和恢复工作进度的命令 git stash 。这个命令非常方便地解决了这个难题。 
在切换到新的工作分支之前执行 git stash 保存工作进度，工作区就会变得非常干净，然后就可以切换到新的分支中了。 

$ git stash 
$ git checkout <new_branch> 

新的工作分支修改完毕后，再切换回当前分支，调用 git stash pop 命令则可恢复之前保存的工作进度。 

$ git checkout <orignal_branch> 
$ git stash pop