Git 项目管理.pdfVIP

Git 项⽬的管理 既然是相互协作，在贡献代码的同时，也免不了要维护管理⾃⼰的项⽬。像是 么处 理别⼈⽤ format-patch ⽣成的补丁，或是集成远端仓库上某个分⽀上的变化等等。但 ⽆论是管理代码仓库，还是帮忙审核收到的补丁，都需要同贡献者约定某种长期可持 续的⼯作⽅式。 使⽤特性分⽀进⾏⼯作 如果想要集成新的代码进来，最好局限在特性分⽀上做。临时的特性分⽀可以让你随 意尝试，进退⾃如。⽐如碰上⽆法正常⼯作的补丁，可以先搁在那边，直到有时间仔 细核查修复为⽌。创建的分⽀可以⽤相关的主题关键字命名，⽐如 ruby_client 或者其 它类似的描述性词语，以帮助将来回忆。Git 项⽬本⾝还时常把分⽀名称分置于不同 命名空间下，⽐如 sc/ruby_client 就说明这是 sc 这个⼈贡献的。 现在从当前主⼲分⽀ 为基础，新建临时分⽀： $ git branch sc/ruby_client master 另外，如果你希望⽴即转到分⽀上去⼯作，可以⽤ checkout -b ： $ git checkout -b sc/ruby_client master 好了，现在已经准备妥当，可以试着将别⼈贡献的代码合并进来了。之后评估⼀下有 没有问题，最后再决定是不是真的要并⼊主⼲。 采纳来⾃邮件的补丁 如果收到⼀个通过电邮发来的补丁，你应该先把它应⽤到特性分⽀上进⾏评估。有两 种应⽤补丁的⽅法：git apply 或者 git am 。 使⽤ apply 命令应⽤补丁 如果收到的补丁⽂件是⽤ git diff 或由其它 Unix 的 diff 命令⽣成，就该⽤ git apply 命 令来应⽤补丁。假设补丁⽂件存在 /tmp/patch-ruby-client .patch ，可以这样运⾏： $ git apply /tmp/patch-ruby-client.patch 这会修改当前⼯作⽬录下的⽂件，效果基本与运⾏ patch -p 1 打补丁⼀样，但它更为严 格，且不会出现混乱。如果是 git diff 格式描述的补丁，此命令还会相应地添加，删 除，重命名⽂件。当然，普通的 patch 命令是不会这么做的。另外请注意，git apply 是⼀个事务性操作的命令，也就是说，要么所有补丁都打上去，要么全部放弃。所以 不会出现 patch 命令那样，⼀部分⽂件打上了补丁⽽另⼀部分却没有，这样⼀种不上 不下的修订状态。所以总的来说，git apply 要⽐ patch 严谨许多。因为仅仅是更新当 前的⽂件，所以此命令不会⾃动⽣成提交对象，你得⼿⼯缓存相应⽂件的更新状态并 执⾏提交命令。 在实际打补丁之前，可以先⽤ git apply --check 查看补丁是否能够⼲净顺利地 应⽤到当前分⽀中： $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply 如果没有任何输出，表⽰我们可以顺利采纳该补丁。如果有问题，除了报告错误信息 之外，该命令还会返回⼀个⾮零的状态，所以在 shell 脚本⾥可⽤于检测状态。 使⽤ am 命令应⽤补丁 如果贡献者也⽤ Git ，且擅于制作 format-patch 补丁，那你的合并⼯作将会⾮常轻松。 因为这些补丁中除了⽂件内容差异外，还包含了作者信息和提交消息。所以请⿎励贡 献者⽤ format-patch ⽣成补丁。对于传统的 diff 命令⽣成的补丁，则只能⽤ git apply 处理。 对于 format-patch 制作的新式补丁，应当使⽤ git am 命令。从技术上来说，git am 能 够读取 mbox 格式的⽂件。这是种简单的纯⽂本⽂件，可以包含多封电邮，格式上⽤ From 加空格以及随便什么辅助信息所组成的⾏作为分隔⾏，以区分每封邮件，就像 这样： From 33002d704da8e76ca5c05c1 8e71a8 Mon Sep 17 00:00:00 From: Jessica Smith jessica@ Date: Sun, 6 Apr 2008 10:17:23 -0700 Subject: [PATCH 1/2] add limit to log function Limit log functionality to the first 20 这是 format-patch 命令输出的开头⼏⾏，也是⼀个有效