pro git学习笔记 4
提交指南
首先,请不要在更新中提交多余的白字符(whitespace)。Git 有种检查此类问题的方法,在提交之前,先运行 git diff --check
,会把可能的多余白字符修正列出来。下面的示例,我已经把终端中显示为红色的白字符用 X
替换掉:
接下来,请将每次提交限定于完成一次逻辑功能。并且可能的话,适当地分解为多次小更新,以便每次小型提交都更易于理解。请不要在周末穷追猛打一次性解决五个问题,而最后拖到周一再提交。就算是这样也请尽可能利用暂存区域,将之前的改动分解为每次修复一个问题,再分别提交和加注说明。如果针对两个问题改动的是同一个文件,可以试试看 git add --patch
的方式将部分内容置入暂存区域。
项目的管理
如果想要集成新的代码进来,最好局限在特性分支上做。临时的特性分支可以让你随意尝试,进退自如。比如碰上无法正常工作的补丁,可以先搁在那边,直到有时间仔细核查修复为止。创建的分支可以用相关的主题关键字命名,比如 ruby_client
或者其它类似的描述性词语,以帮助将来回忆。Git 项目本身还时常把分支名称分置于不同命名空间下,比如 sc/ruby_client
就说明这是 sc
这个人贡献的。现在从当前主干分支为基础,新建临时分支:
$ git branch sc/ruby_client master
另外,如果你希望立即转到分支上去工作,可以用 checkout -b
:
$ git checkout -b sc/ruby_client master
好了,现在已经准备妥当,可以试着将别人贡献的代码合并进来了。之后评估一下有没有问题,最后再决定是不是真的要并入主干。
使用 apply 命令应用补丁
如果收到的补丁文件是用 git diff
或由其它 Unix 的 diff
命令生成,就该用 git apply
命令来应用补丁。假设补丁文件存在 /tmp/patch-ruby-client.patch
,可以这样运行:
$ git apply /tmp/patch-ruby-client.patch
这会修改当前工作目录下的文件,效果基本与运行 patch -p1
打补丁一样,但它更为严格,且不会出现混乱。如果是 git diff
格式描述的补丁,此命令还会相应地添加,删除,重命名文件。当然,普通的 patch
命令是不会这么做的。另外请注意,git apply
是一个事务性操作的命令,也就是说,要么所有补丁都打上去,要么全部放弃。所以不会出现 patch
命令那样,一部分文件打上了补丁而另一部分却没有,这样一种不上不下的修订状态。所以总的来说,git apply
要比 patch
严谨许多。因为仅仅是更新当前的文件,所以此命令不会自动生成提交对象,你得手工缓存相应文件的更新状态并执行提交命令。
准备发布
现在可以发布一个新的版本了。首先要将代码的压缩包归档,方便那些可怜的还没有使用Git的人们。可以使用git archive
:
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz
这个压缩包解压出来的是一个文件夹,里面是你项目的最新代码快照。你也可以用类似的方法建立一个zip压缩包,在git archive
加上--format=zip
选项:
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
制作简报
是时候通知邮件列表里的朋友们来检验你的成果了。使用git shortlog
命令可以方便快捷的制作一份修改日志(changelog),告诉大家上次发布之后又增加了哪些特性和修复了哪些bug。实际上这个命令能够统计给定范围内的所有提交;假如你上一次发布的版本是v1.0.1,下面的命令将给出自从上次发布之后的所有提交的简介: