git - 如果它迫使你留在本地，为什么要使用 rebase？

Question

很抱歉提出关于 merge 与 rebase 的哲学辩论，但我有一个实际问题，涉及典型的公司工作流程(不是开源项目工作流程，可能有所不同)。

rebase ，如pointed here , 如果您已推送更改，则不应使用。之所以如此，是因为其他人可能已经从您的分支分支出来，然后重写该分支的历史记录(通过强制推送)会让他们很难。

因此，使用 rebase 的正确方法是仅在本地提交。但至少根据我的短暂经验，这是不可取的:

• 如果您的计算机被盗怎么办？
• 如果您因磁盘故障而丢失数据怎么办？
• 如果您必须在两个地点工作(例如 this person)怎么办

在本地保留功能分支对我来说是违反直觉的。不仅由于上述几点，还由于以下用例:您正在处理一项功能，但要么被拖到更紧急的事情上，要么去度假，要么生病。同事必须完成它。然后你 rebase 并推送(除非你生病了，在这种情况下它会留在本地并且没有人可以完成它)，另一个人完成它。

那段时间master有变动。但是另一个人已经基于一个远程分支，所以他应该使用 merge，或者 rebase 和 force-push(如果其他人的分支同时基于那个分支，这同样可能会搞砸)。

这些听起来像是边缘情况，但事实并非如此。这些情况中至少有一个(在家工作、生病、去度假、完成别人的工作等)经常发生。

那么，在这些用例中使用“ rebase ”是一种好方法，还是 merge (使用额外的“merge 提交”)是更安全、更直接的选择？

Answer 1

所以我倾向于支持 rebase 。 Git 图历史很重要。你希望它有一些关于功能分支以及它们如何 merge 的信息，但是一旦你有更多的人，图表很快就会变得一团糟。您常常想了解过去几天发生的事情，而图表的质量是能否从 git 图表中获取该信息的区别。

另外，请注意，强制 push 功能分支并不是什么大不了的事。强制推送的问题是你必须通过非 git 方式通知人们 git 事件——在 Slack 上 ping 他们，等等。这显然不适用于开源项目或有多个贡献者的分支。但是大多数特性分支只有一个贡献者，所以他们可以随心所欲地强制推送。即使有两三个人在处理它，你也很少可以通过强制推送来解决它——我们组织的典型情况是在打开 pull 请求之前和 merge 之前。您偶尔会在工作进行到一半时这样做，以便从上游获得一些东西，但通常您不需要这样做，除非您愿意。

当我们 merge 时，我们做了两件事——我们在 master 之上 rebase ，然后我们与 --no-ff merge 。这会创建一个带有空左侧路径的 merge 气泡，它 (1) 将提交分组在一起，并且 (2) 使直接进入 master 的提交脱颖而出(这些偶尔有效——修补程序、小改进、拼写错误、空格等)。

这种方法的警告是需要一段时间来学习。你不能使用 GitHub merge 按钮(它没有达到我们的预期)，你必须有足够的 git chop 来做一个 rebase 并注意图表。我遇到的大多数开发人员都不在那里。每个新的团队成员都需要一段时间来理解这一点，并且通常会把历史搞砸一两次(我们有 git hooks 可以提供帮助)。但我发现这种权衡是值得的。好处是:

• 功能分支不是本地的。
• 历史保持得很干净。
• 主题提交通过 merge 气泡分组。
• 用力 push 通常不是问题，因为 (1) 它很少发生，并且 (2) 你要么单独工作，要么最多结对工作。

作为旁注，“不要将已经推送到原始位置的东西 rebase ”对我来说总是听起来像是新手规则。是的，当您不知道自己在做什么时，您可能会把事情搞砸。但是，一旦您精通 git，就该轮到训练轮了。