门控提交使用git分支
我正在考虑使用git分支为每个开发人员设置一个门控提交工作流，如下所示：
这是一个合理的解决方案？ 我来自颠覆，对git没有太多经验。
我认为这个评价通常是合理的。 我会尽量不把分支想象成'遥远'。 这是颠覆转变的一部分。 所有开发人员都具有用于与实际远程存储库同步的本地和远程（分段）区域（'起源'）。 开发人员应该经常与主分支进行合作并进行推动和重新分配（保持更新）。
有关git branch，fork，fetch，merge，rebase和clone的工作流程的更多信息，有什么区别？
我的工作流程是：
根据我个人的经验，过去最适合我团队的工作流程是让所有开发人员共享一个远程分支。 对于我的团队来说，我们只是把这个分支称为“主人”。 我们的分支战略借鉴了这篇文章的创意：a-git-branch-model。 只需将文章中的“开发/主”分支与“主/发布”互换，并且您基本上拥有了我的设置。 这是一样的，只是标记不同。
我基本上让我们所有的开发人员都承诺掌握，但只有提交合并的约定。 所有直接编码都发生在主题分支上。 对于只有一个变更集的快速修复，可以直接向母版提交。 但总的来说，强烈鼓励使用本地话题分支。
此外，所有提交给主的提交都必须立即推送，否则差异会累积并使合并更加困难。 通过这种方式，解决合并的负担是开发人员的责任，而不是团队负责人或一些自动化软件。 这是理想的情况，因为开发代码的人通常最了解自己的变化。
如果不止一个开发人员需要在单个主题分支上工作，我允许所有开发人员将他们自己的分支在特定路径下推送到远程（在我的情况下，它是“共享/”），以便其他人可以从中进行推送和推送。
对于测试服务器（CI服务器），它会在每次测试运行时更新其主分支。 在新分支上测试并不是必须的，但是我知道某些自动化脚本不直接在master上工作，所以我更加舒适。
如果你是来自svn，在共享分支上发生不断的小变化可能看起来有点可怕。 不要害怕，git通常非常擅长解决冲突，90％的时间git merge或git pull甚至不会引发冲突。
最后，确保向开发人员灌输经常的习惯，经常拉动。 小的增量更改实际上有助于更好地合并代码。
使用Gerrit - 它基本上是一个内置代码审查功能的门控提交解决方案。
链接地址: http://www.djcxy.com/p/7551.html