包含许多特性分支的故事分支Git模型

Question

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

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

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

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

一旦每个功能完成，story将被合并回master (S*)。

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

我想听听关于安全工作流程(git merge --no-commit ?)的建议来完成这个模型。

Answer 1

重写将重写历史记录。永远不要重写已经发布的提交的历史记录(特别是如果您知道进一步的分支是基于它们的)，否则您将使您的同事比应该做的更困难。

你建议的工作流程应该可以很好地合并而不是重基。定期将master合并到story和story中，合并到story的任何仍然活跃的特性分支中，并不能避免合并冲突(不过，重基也不能)，但可以让您以小的、可管理的块来处理它们，而不是在一个大的

bang混乱中处理它们。

我不想在开发结束时将story合并到master时避免merge master into story类型的提交。

为什么?没有什么好羞愧的。

你推荐什么?git checkout story && git merge master --no-commit ?

这将做的是合并master到story没有隐式提交。只有在手动提交之前，合并才会在您的工作副本中，这允许您在持久化合并结果之前手动修改合并结果。当你手动提交时，结果提交将仍然是合并提交，即它将有两个父文件(除非你已经从工作副本中删除了合并，例如使用git reset --hard HEAD或git checkout .。)

另外，你看到feature分支的git rebase story有任何问题吗?

只需应用

规则

不要对存在于你的存储库之外的提交进行重基。

这意味着，如果特性分支不被共享，因此它们中的每一个只存在于各自的单个开发人员的本地存储库中，那么重基不会导致任何问题。(但这必须由各自的开发人员完成，因为他是唯一一个在他们的repo中有分支的人。)

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