哪些是最常见的Git分支方案/提交生命周期?

我现在已经管理了几个使用Git的团队,我们已经制定了一个非常适合我们的策略。

• 大师总是一个复制品,什么是在生产。当代码被释放时,当前分支将快速转发到master,并添加一个标记,以便及时标记释放,如果需要,我们可以获取代码。
• 开发人员可以自由地按照他们的分支工作,但是对于功能分支,我们通常为每个功能都有一个分支,并且多个开发人员在该分支之间合并以共享该功能的工作。
• 当发布候选时,会创建一个RC_XXX分支,并且足够远的特征分支都会合并到其中。然后对其进行测试,并在此基础上进行缺陷修复。
• 说到做到,RC_XXX分公司就可以投入生产了,在它“坚持”了几天之后,我们就把它推广到master,然后新的功能分公司就建立在它的基础上。

这工作得很好,因为只需从master分支,就可以轻松创建和部署针对生产的热修复,而且开发人员可以针对功能分支分支进行分支,以便在必要时引入依赖项。

这个呢(我忽略了开发人员在他们的机器上有什么):

• 创建了新的QA分支,所有开发人员都重新调整了基础

我还不是一个Git顾问,但根据经验,开发人员应该更经常地(而不仅仅是“发布之后”)调整工作。
否则,就像你在评论中提到的,会导致 git revert “(这是有效的,但应该是一种例外情况,而不是一种常见的解决办法)。

点对点协作是可能的,但是需要遵守一些规则 requires setting up a bare repo 和 local protocol .