现在,我比较常用的工作流之一是这样的:
git checkout branch
git rebase master
git checkout master
git reset --hard branch换句话说,我想将一个分支重设为这个分支,并将其设置为新的重定基。有没有内置的,或者你必须开始做别名之类的东西?
发布于 2017-03-16 02:57:29
我不知道你为什么要运行这些命令。让我们来看看这些命令是做什么的。假设你有一个分支。
A - B - C [master]
\
D - E [branch]A - B - C [master]
\
D1 - E1 [branch]好的,这是使用rebase更新master分支的正常方式。
A - B - C
\
D1 - E1 [branch] [master]您最终将分支“合并”为master。这是处理合并的一种方法。我假设你这样做是为了你有一个很好的,线性的历史。
您可以使用git merge branch替换git reset --hard branch,这样做会更安全一些。这更安全,因为如果master是分支的直接祖先,那么master将快进到分支,您将具有相同的效果。
但是如果master不是branch的直接祖先呢?git merge branch将合并,并且您仍然有一个合理的历史。但是如果你运行了git reset --hard branch,那么master就会被丢弃。例如,假设由于某种原因,您忘记了git rebase master或它失败了,或者您在它之后运行了另一个命令,结果如下所示。
A - B - C [master]
\
D - E [branch]git reset --hard branch会悄悄地把师父赶出去。这个错误很难被发现。
A - B
\
D - E [branch] [master]而git merge master将执行合并,master仍然有意义。
A - B - C - F[master]
\ /
D - E [branch],除非我得到一个丑陋的合并提交和一个更丑陋的历史记录
并不是所有的合并提交都很难看。丑陋的是“更新”提交,只是内务。这就是使用git checkout branch; git rebase master时要避免的事情。但是,当最终合并一个功能分支时,您希望合并提交来保留分支存在的事实,它的用途,以及其中的提交内容。该上下文对于理解您的代码非常重要。
我建议你这样做:
works
--no-ff branch
像平常一样更新分支,结果就像以前一样。
A - B - C
\
D1 - E1 [branch] [master]但之后情况就不同了。第一个更改是在将分支合并到之前验证分支是否工作正常,这也是为什么不应该自动化整个过程。这样可以避免破坏master。在rebase之后,分支将与合并到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]最后,合并提交提供了提供有关分支的更多上下文的位置。您可以描述分支的用途,或者只是问题跟踪器中问题的链接。
未来的代码考古学家会为此感谢你的。
https://stackoverflow.com/questions/42816836
复制相似问题