持久分支的git体系结构，它始终重新成为master的主管

Question

我有一个repo，它支持几乎相同代码的两个不同部署。有一个提交实际上是master上的补丁，用于创建我的功能分支的功能：

A -- B -- C # master
           \
            D # feature

绝大多数代码都会应用于master，但feature也需要它，即提交＆＃34; D＆＃34;应始终将master的HEAD作为其父级。我的第一直觉是始终如一地重新定位feature，但是当我推出新的重新定义的功能时，我正在改变历史，对吧？

## Breaks History For Other Developers!
A -- B -- C -- E # master
                \
                 D # feature

现在我不知所措。我最初的解决方案是cherry-pick，但最终导致了一个令人难以置信的糟糕的git历史记录，并且当人们忘记将他们的提交放在这两个地方时错过了提交。

在这种情况下，连续rebase是否可以接受？如果没有，我怎么能实现我正在寻找的东西？

Answer 1

这是一个更清晰的解决方案，可以在每次提交时将master合并到您的功能分支中，这样可以保持干净的提交历史记录，而无需编辑历史记录。

这也可以让你维护你的功能分支的版本，而不会在你工作时受到重新设置，只在你需要的时候从主设备执行合并。

简而言之，你可以这样做：

git checkout feature; git merge master