在你的团队中正式确立 Git 约定
每个人都应当遵循对于分支命名、标记和编码的规范。每个组织都有自己的规范或者最佳实践,并且很多建议都可以从网上免费获取,而重要的是尽早选择合适的规范并在团队中遵循。
同时,不同的团队成员的 Git 水平参差不齐。你需要创建并维护一组符合团队规范的基础指令,用于执行通用的 Git 操作。
正确地合并变更
每个团队成员都需要在一个单独的功能分支上开发。但即使是使用了单独的分支,每个人也会修改一些共同的文件。当把更改合并回 master 分支时,合并通常无法自动进行。可能需要手动解决不同的人对同一文件不同变更的冲突。这就是你必须学会如何处理 Git 合并的原因。
它们对同一文件的每个部分提供了合并的各种选择,例如,是否保留你的更改,或者是保留另一分支的更改,亦或者是全部保留。如果你的编辑器不支持这些功能,那么可能是时候换一个代码编辑器了。
经常变基你的功能分支
当你持续地开发你的功能分支时,请经常对它做变基rebase:rebase master。这意味着要经常执行以下步骤:
git checkout master
git pull
git checkout feature-xyz #假设的功能分支名称
git rebase master #可能需要解决 feature-xyz 上的合并冲突
这些步骤会在你的功能分支上。首先,它会使你的功能分支获得 master 分支上当前的所有更新。其次,你在功能分支上的所有提交都会在该分支历史的顶部重写,因此它们会顺序地出现在日志中。你可能需要一路解决遇到的合并冲突,这也许是个挑战。但是,这是解决冲突最好的时机,因为它只影响你的功能分支。
在解决完所有冲突并进行回归测试后,如果你准备好将功能分支合并回 master,那么就可以在再次执行上述的变基步骤几次后进行合并:
git checkout master
git pull
git merge feature-xyz
在此期间,如果其他人也将和你有冲突的更改推送到 master,那么 Git 合并将再次发生冲突。你需要解决它们并重新进行回归测试。
还有一些其他的合并哲学(例如,只使用合并而不使用变基以防止重写历史),其中一些甚至可能更简单易用。但是,我发现上述方法是一个干净可靠的策略。提交历史日志将以有意义的功能序列进行排列。
如果使用“纯合并”策略(上面所说的,不进行定期的变基),那么 master 分支的历史将穿插着所有同时开发的功能的提交。这样混乱的历史很难回顾。确切的提交时间通常并不是那么重要。最好是有一个易于查看的历史日志。