2

我们目前有 3 名开发人员在一个功能分支上工作。我们不断向 feature_branch（和 origin/feature_branch）提交和推送 WIP 提交，每隔一天我们将 master 合并到 feature_branch，以确保我们及时了解正在发生的所有其他更改。

我们的 feature_branch 现在包含大约 100 个提交（包括许多合并提交），可以很容易地压缩成一个或两个提交。到目前为止，当一个功能分支上的工作完成时，我们只是将它合并回 master，这导致意大利面日志和检查点提交被推送到 master。

相反，我们想要变基。如果我们决定我们在 feature_branch 上的工作已经完成，并且没有开发人员会从/向这个分支拉取或推送新的提交 - 并且是时候将我们的更改合并回 master，rebase 会违反 rebase的黄金法则吗？
在阅读了这个主题之后，在 master 之上 rebase interactive 听起来是个好主意（然后合并回 master，这将是一个 ff 合并），但我只是想确保我没有遗漏任何东西。

此外，在我们不断将 master 合并到其中后，重新调整 feature_branch 有什么问题（为了保持更新）？压缩合并提交可以吗？

谢谢！

4

2 回答 2

2

rebase 与 merge 的选择在某种程度上是一个品味问题。您拥有的链接（使用“rebase 的黄金法则”来避免对已发布的提交进行 rebase）使用了一个雅致的规则，该规则使临时用户的事情变得简单。但是，只要您和他们都知道如何处理它们，您和您的同事就不能事先同意允许对已发布的提交进行变基处理。

git 的 git 存储库中有几个故意重新设置的分支，称为next和pu（pu代表 Pick Up，而不是 skunk-odor :-)）。当你git fetch最新的 git 时，你会经常看到这样的东西：

 + 104e649...1352ede next       -> origin/next  (forced update)
 + cf10e94...a619c8c pu         -> origin/pu  (forced update)

注意forced update,git fetch打印是因为更新不是快进并且仅因为+fetch refspec 中的 而发生。

于 2016-04-21T09:28:18.243 回答
1

实际上，这取决于您通常的工作流程，我不认为变基总是错误的。

例如，如果您使用基于 Garrit 的工作流程，通常与 master 一起变基，将您的提交压缩为单个提交，然后将其推送到 master 以合并它。（基本上，您要掌握一个补丁，其中包含由于您的变基操作而已经部分合并的代码）。在这里你可以找到关于这个一直使用变基的工作流的更详细的解释。

于 2016-04-21T09:24:35.243 回答