纠正共享功能分支的Git工作流程？

Question

我试图找出适合这种情况的工作流程:

在共享仓库中,我们有这些分支:

-master
-feature

该功能分支是一个共享的分支,因为许多开发商都上了一个新的功能一起工作.他们正在积极地将他们的更改推送到功能分支.

这个功能最终被合并回主人的那一天,我试图避免"冲突地狱" .目前,我看到一些选择:

1)主动将master合并到功能中,并经常进行.但是,这不建议在git文档中使用,我开始明白为什么.当我尝试这个时,我似乎一遍又一遍地解决同样的冲突.

2)以某种方式使用rebase.我已经阅读了这篇文章,但由于功能分支实际上是共享的,所以看起来它不会工作.所需要的只是一个开发人员做2个rebase,而其他开发人员可能会因不匹配的历史而产生冲突.

3)将功能分支转换为集成分支,让开发人员使用自己独立的功能分支进行变基,以保持理智.

4)完全不同的东西？

Answer 1

对于共享分支,我会使用#3,并将其用作"集成"分支来整合他们的工作.
开发人员必须使用rebase 在合并他们的工作之前不断重播他们的private分支,这样他们就是:featurefeature

• 在本地解决任何合并冲突(在他们自己的回购中)
• 最终合并(从他们的private分支到feature)一个微不足道的(通常是快进)

(如" git rebasevs. merge"答案中所述)

这个想法是,一旦feature分支必须合并master,就不再接受任何贡献feature(分支被"冻结"),并且您可以安全地在master第一个之前重新定义它,或者直接将其合并到master.
然后你开始一个新的feature分支(feature如果需要,它实际上可以与前一个分支并行启动)

Answer 2

您可以rerere用来处理多次看到的合并冲突.