我们目前正在开发一个功能分支的3个开发人员。我们不断提交并将WIP提交推送到feature_branch（以及origin / feature_branch），并且每隔一天我们将master与merge_branch合并，以确保我们了解所有正在发生的其他更改。
我们的feature_branch现在包含~100次提交（包括大量的merge-commits），可以很容易地压缩成一两次提交。 到目前为止，当在功能分支上完成工作时，我们只是将它合并回主服务器，这导致意大利面条日志和检查点提交被推送到主服务器。
相反，我们想要改变。 如果我们决定完成我们在feature_branch上的工作，并且没有开发人员会从这个分支中提取或推送新的提交 - 并且是时候将我们的更改合并回master，那么rebase会违反the golden rule of rebasing吗？登记/> 在阅读了这个主题之后，在主人之上进行交互式反响似乎是一个好主意（然后合并回主人，这将是一个ff合并）但我只是想确保我没有遗漏任何东西。
此外，在我们继续将master与其合并（为了保持更新）之后，重定位feature_branch有什么问题吗？是否可以压缩merge-commit？
谢谢！
答案 0 :(得分：2)
rebase vs merge的选择在某种程度上是品味问题。您拥有的链接（使用“重新定义的黄金法则”，以避免重新发布已发布的提交）使用了一个有品位的规则，可以让临时用户保持简单。但是，只要您和他们都知道如何处理它们，就没有任何内容表明您和您的同事不能提前同意允许重新发布已提交的提交。
git的git存储库中有几个故意重新分支的分支，称为next和pu（pu代表Pick Up，而不是臭臭:-)）。当你git fetch最新的git时，你经常会看到这样的事情：
+ 104e649...1352ede next -> origin/next (forced update)
+ cf10e94...a619c8c pu -> origin/pu (forced update)
请注意forced update，git fetch打印，因为更新不是快进，只是因为fetch refspec中的+而发生。
答案 1 :(得分：1)
实际上，这取决于您通常的工作流程，我不认为变基总是错误的。
例如，如果您使用基于Garrit的工作流通常与主服务器的rebase一样正常，则在单个提交中压缩您的提交，然后将其推送到主服务器以便合并它。 （基本上，您提供掌握一个补丁，其中包含由于您的rebase操作已经部分合并的代码）。 Here您可以找到有关此工作流程的更详细说明，该工作流程始终使用变基。