git - 使用 git 分支的门控提交

Question

我正在研究为每个开发人员使用 git 分支设置门控提交工作流程，如下所示：

1. 每个开发人员都有自己的远程分支。
2. 开发人员只推送到他们的远程分支。
3. CI 服务器单独构建每个分支，如果测试通过，则合并到 master。
4. 开发人员通过将他们的分支拉取并重新定位到 master 来接收更改。

这是一个合理的解决方案吗？我来自颠覆，对 git 没有太多经验。

Answer 1

我认为这种方法通常是合理的。我会尽量不要将分支视为“远程”。这是颠覆的一部分。所有开发人员都有本地和远程（暂存）区域（'origin'），用于与实际的远程存储库同步。开发人员应该经常使用主分支提交、拉取、推送和重新定位（保持最新）。

有关工作流程的更多信息：git branch、fork、fetch、merge、rebase 和 clone，有什么区别？

我的工作流程是：

• 拉最新的主人
• 做一个分支
• 做工作
• 提交更改到分支
• 获取最新的主人
• 合并master到分支
• 做更多的工作
• 提交更改到分支
• 获取最新的主人
• 合并master到分支
• 代码审查
• 切换到主
• 获取最新远程版本的远程主机
• 合并分支到master
• 将 master 推送到远程

Answer 2

以我个人的经验，过去最适合我的团队的工作流程是让所有开发人员共享一个远程分支。对于我的团队，我们恰好称这个分支为“master”。我们的分支策略借鉴了这篇文章的想法：a-successful-git-branching-model。只需将文章中的“开发/主”分支与“主/发布”互换，您基本上就拥有了我的设置。都是一样的，只是标签不同而已。

我基本上让我们所有的开发人员都提交给 master，但增加了只提交合并的约定。所有直接编码都发生在主题分支上。对于只有一个变更集的快速修复，可以直接提交给 master。但总的来说，强烈鼓励使用本地主题分支。

此外，必须立即推送所有对 master 的提交，否则差异会累积并使其更难合并。通过这种方式，解决合并的负担是开发人员而不是团队负责人或某些自动化软件的责任。这是理想的情况，因为开发代码的人通常最了解自己的更改。

如果多个开发人员需要处理单个主题分支，我允许所有开发人员将他们自己的分支推送到特定路径下的远程（在我的情况下是“共享/”），以便其他人可以从中提取和推送。

至于测试服务器（CI 服务器），它会在每次测试运行时更新 master 和分支。在新分支上进行测试并不是绝对必要的，但是知道某些自动化脚本不能直接在 master 上运行，我会更舒服。

如果您来自 svn，在共享分支上不断发生小变化可能看起来有点可怕。不要害怕，git 通常非常擅长解决冲突，而且 90% 的时间git merge甚至git pull不会引发冲突。

最后，确保向开发人员灌输经常提交、经常拉取的习惯。小的增量更改实际上有助于 git 更好地合并代码。

Answer 3

使用Gerrit - 它基本上是一个内置代码审查功能的门控提交解决方案。