2 向一个项目贡献.pdfVIP

5.2 向⼀个项⽬贡献 向⼀个项⽬贡献 描述如何向⼀个项⽬贡献的主要困难在于完成贡献有很多不同的⽅式。因为 Git ⾮ 灵活，⼈们可以通过不同的⽅式来⼀起⼯作，所以描述应该如何贡献并不是⾮ 准确 - 每⼀个项⽬都有⼀点⼉不同。影响因素包括活跃贡献者的数量、选择的⼯作流程、 提交权限与可能包含的外部贡献⽅法。 第⼀个影响因素是活跃贡献者的数量 - 积极地向这个项⽬贡献代码的⽤户数量以及他 们的贡献频率。在许多情况下，你可能会有两三个开发者⼀天提交⼏次，对于不活跃 的项⽬可能更少。对于⼤⼀些的公司或项⽬，开发者的数量可能会是上千，每天都有 成百上千次提交。这很重要，因为随着开发者越来越多，在确保你的代码能⼲净地应 ⽤或轻松地合并时会遇到更多问题。提交的改动可能表现为过时的，也可能在你正在 做改动或者等待改动被批准应⽤时被合并⼊的⼯作严重损坏。如何保证代码始终是最 新的，并且提交始终是有效的？ 下⼀个影响因素是项⽬使⽤的⼯作流程。它是中⼼化的吗，即每⼀个开发者都对主线 代码有相同的写⼊权限？项⽬是否有⼀个检查所有补丁的维护者或整合者？是否所有 的补丁是同⾏评审后批准的？你是否参与了那个过程？是否存在副官系统，你必须先 将你的⼯作提交到上⾯？ 下⼀个问题是提交权限。是否有项⽬的写权限会使向项⽬贡献所需的流程有极⼤的不 同。如果没有写权限，项⽬会选择何种⽅式接受贡献的⼯作？是否甚⾄有⼀个如何贡 献的规范？你⼀次贡献多少⼯作？你多久贡献⼀次？ 所有这些问题都会影响实际如何向⼀个项⽬贡献，以及对你来说哪些⼯作流程更适合 或者可⽤。我们将会由浅⼊深，通过⼀系列⽤例来讲述其中的每⼀个⽅⾯；从这些例 ⼦应该能够建⽴实际中你需要的特定⼯作流程。 提交准则 在我们开始查看特定的⽤例前，这⾥有⼀个关于提交信息的快速说明。有⼀个好的创 建提交的准则并且坚持使⽤会让与 Git ⼯作和与其他⼈协作更容易。Git 项⽬提供了⼀ 个⽂档，其中列举了关于创建提交到提交补丁的若⼲好的提⽰ - 可以在 Git 源代码中 的 Documentation/SubmittingPatches ⽂件中阅读它。 ⾸先，你不会想要把空⽩错误 （根据 git help diff 的描述，结合下⾯给出的图⽚，空⽩ 错误是指⾏尾的空格、Tab 制表符，和⾏⾸空格后跟 Tab 制表符的⾏为）提交上去。 Git 提供了⼀个简单的⽅式来检查这点 - 在提交前，运⾏ git diff --check，它将 会找到可能的空⽩错误并将它们为你列出来。 “提交区间” 中详细介绍这个语法。 ⽬前，我们可以从输出中看到有⼀个 John ⽣成的但是 Jessica 还没有合并⼊的提交。 如果她合并 origin/master，也就是说将会修改她的本地⼯作的那个单个提交。 现在，Jessica 可以合并她的特性⼯作到她的 master 分⽀，合并 John 的⼯作 （origin/master）进⼊她的 master 分⽀，然后再次推送回服务器。⾸先，为了 整合所有这些⼯作她切换回她的 master 分⽀。 $ git checkout master Switched to branch master Your branch is behind origin/master by 2 commits, and can be fas 她既可以先合并 origin/master 也可以先合并 issue 4 - 它们都是上游，所以顺 序并没有关系。不论她选择的顺序是什么最终的结果快照是完全⼀样的；只是历史会 有⼀点轻微的区别。她选择先合并⼊ issue 4： $ git merge issue 4 Updating fbff bc..4af4298 Fast forward README | 1 + lib/simplegit.rb | 6 +++++- 2 files changed, 6 insertions(+), 1 deletions(-) 没有发⽣问题；如你所见它是⼀次简单的快进。现在 Jessica 合并⼊ John 的⼯作 （origin/master）： $ git merge origin/master Auto-merging lib/simplegit.rb Merge made by recursive. lib/simplegit.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(