具有许多功能分支的故事分支的 Git 模型

Question

我的团队开始了一个新故事，将在大约 2 周内交付。这个故事被分解成多个功能，将由几个开发人员处理。流程如下:

(master) - - - - - - - - - - - - - - - - - -  S* - - >
   ↓                                          ↑                                            
(story) - - - - - A* - B* - - - - - - - C*- - -
   ↓              ↑    ↑    ↓           ↑
(feature A) - - - ↑    ↑    ↓           ↑
   ↓                   ↑    ↓           ↑
(feature B) - - - - - -↑    ↓           ↑
                         (feature C) - -

Story 分支取自 master。开发人员从故事分支分支并创建功能分支。 git rebase 经常与 story 一起完成，以尽量减少冲突的数量。一旦功能完成(A*、B*、C*)，提交将被压缩并将分支 merge 到 story 与 --no-ff。

master 更改非常频繁，因为它从其他团队获得提交。

每个功能完成后，story 将 merge 回 master (S*)。

这里的挑战是如何使 story 与 master 保持同步？我想每天使用两次 git rebase master 来保持历史记录干净，但我知道提交将被更改，这可能会严重影响 feature 分支。

我想听听有关安全工作流(git merge --no-commit？)来完成此模型的建议。

Answer 1

rebase 重写历史。 You should never rewrite history of already-published commits (特别是如果您知道更多的分支机构是基于它们的)，否则您会让您的同事遇到比应有的困难得多的事情。

您建议的工作流程应该适用于 merge 而不是 rebase 。定期将 master merge 到 story 并将 story merge 到 story 的任何仍处于事件状态的功能分支中不会避免 merge 冲突(不过， rebase 也不会)，但可以让您以小的、可管理的 block 来处理它们，而不是在一个大的 bang 困惑中处理它们。

I wan't to avoid merge master into story kind of commits when merging story into master at the end of the development.

为什么？他们没什么好羞愧的。

What do you recommend? git checkout story && git merge master --no-commit?

这将做的是将 master merge 到 story 而无需隐式提交。只有在您手动提交之前， merge 才会在您的工作副本中，这允许您在持久化之前手动修改 merge 结果。当您随后手动提交时，生成的提交仍将是 merge 提交，即它将有两个父项(除非您已从工作副本中删除 merge ，例如使用 git reset --hard HEAD 或git checkout ..)

Also, do you see any issue with git rebase story for feature branches?

只需申请 the rule

Do not rebase commits that exist outside your repository.

这意味着，如果功能分支未共享，因此每个分支仅存在于处理它们的相应单个开发人员的本地存储库中，则 rebase 不会导致任何问题。 (但这必须由各自的开发人员完成，因为他是唯一一个在他们的 repo 中有分支的人。)

但是，如果功能分支是共享的(推送或 pull 到其他存储库)，则存在其他人基于它们进行自己的提交的风险，因此在这种情况下您不应该重写它们。