由 dawei 在你的团队中正式确立 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 分支的历史将穿插着所有同时开发的功能的提交。这样混乱的历史很难回顾。确切的提交时间通常并不是那么重要。最好是有一个易于查看的历史日志。
