Question

现在，我最常用的工作流程之一就是：

git checkout branch
git rebase master
git checkout master
git reset --hard branch

换句话说，我想将一个分支重新绑定到这个分支并将其设置为新的rebase。是否内置了这个或你是否必须开始制作别名和东西？

Answer 1

我不确定你为什么要运行这些命令。让我们来看看这些命令的作用。假设你有一个分支。

A - B - C [master]
     \
      D - E [branch]

git checkout branch
git rebase master

A - B - C [master]
         \
          D1 - E1 [branch]

好的，这是使用rebase更新master的分支的正常方法。

git checkout master
git reset --hard branch

A - B - C
         \
          D1 - E1 [branch] [master]

你最终将分支“合并”为主人。这是处理合并的一种方法。我认为你这样做是因为你有一个很好的线性历史。

将git reset --hard branch替换为git merge branch，您可以做得更安全一些。这样更安全，因为如果master是分支的直接祖先，那么master将快进到分支，你将获得相同的效果。

但是如果主不是分支的直接祖先呢？ git merge branch将合并，你仍然有一个明智的历史。但是如果你跑git reset --hard branch那么主人就会被抛弃。例如，假设由于某种原因，您忘记了git rebase master或者它失败了，或者您在它之后运行了另一个命令，结果就是这样。

A - B - C [master]
     \
      D - E [branch]

git reset --hard branch会悄悄地抛弃大师。这个错误很难被发现。

A - B
     \
      D - E [branch] [master]

git merge master将执行合并，而主人仍然有意义。

A - B - C - F[master]
     \     /
      D - E [branch]

除此之外我得到了一个丑陋的合并提交和一个更加丑陋的历史

并非所有合并提交都很难看。丑陋的是“更新”提交，只是家务。这就是你用git checkout branch; git rebase master避免的。但是当最终合并一个功能分支时，你想要一个合并提交，以保留一个分支存在的事实，它的用途，以及它中的提交。该上下文对于理解您的代码非常重要。

我建议你改为：

git checkout branch
git rebase master
测试分支是否有效
git checkout master
git merge --no-ff branch

正常更新分支，结果与以前一样。

A - B - C
         \
          D1 - E1 [branch] [master]

然而它变得与众不同。第一个更改，以及为什么不应该自动执行整个过程，是为了验证分支在合并到主服务器之前 。这可以避免打破主人。在rebase之后，branch将与将合并到master中的分支完全相同，因此测试分支也会验证合并的master。

第二个更改是使用git merge --no-ff强制合并，即使不需要合并也是如此。结果就是这样。

A - B - C ------- F [master] \ / D1 - E1 [branch]

这样更好，因为两者都会为您提供线性历史记录（即。git log会将提交显示为F，E1，D1，C，B，A），并保留D1和E1作为分支一起完成。这是未来人们试图解开代码的重要环境。分支中的提交通常非常小，如果在分支的上下文中理解它们会更有意义。

当你进入下一个分支时，你仍然会得到一个漂亮的线性历史。结果是一系列近似特征气泡，没有纵横交错。

A - B - C ------- F ------- I [master] \ / \ / D1 - E1 G1 - H1 [branch2]

最后，合并提交提供了一个提供有关分支的更多上下文的位置。您可以描述分支的用途，或只是问题跟踪器中问题的链接。

未来的代码考古学家会感谢你。

＆＃34;反向变革＆＃34;或者＆＃34;重新考虑这个＆＃34;在git

1 个答案: