您可以简化您的命令:
1.
git fetch
git checkout -b my_branch origin/master
2.
git fetch
git merge origin/master
git fetch
更新远程分支,通常没有必要有当你没有的时候,一个分支的本地副本计划在这个分支上工作。
设置3210后可以省略--no-ff
。
git help config
说:
merge.ff
By default, Git does not create an extra merge commit when merging
a commit that is a descendant of the current commit. Instead, the
tip of the current branch is fast-forwarded. When set to false,
this variable tells Git to create an extra merge commit in such a
case (equivalent to giving the --no-ff option from the command
line). When set to only, only such fast-forward merges are allowed
(equivalent to giving the --ff-only option from the command line).
注意git pull
只是一个git fetch
和git merge
组合。
通常你只是想要git pull --rebase
这本质上是git fetch
加git rebase
,并创建一个更清洁的历史。
是否有任何理由让你的“周期性推动”?如果没有其他人在同一个分支上工作,那完全没问题,只需要在完成所有工作后推动。
感谢您(和克里斯托弗)的回复。为了回答你的问题,没有理由让周期性推动,而不是作为备份,以防我的盒子死亡。而且,如果有人希望我的代码能够完成他们自己的工作 - 不完全可能,直到我的代码进入主服务器,再在公共分支上进行重新绑定可能会导致麻烦,所以我明白(但我不确定为什么确切) – larryq
rebases是一把双刃剑。一方面它们往往导致更加清晰的历史。另一方面他们创建了基本上是旧内容的全新提交。如果你推动你的提交,其他人可以(理论上)在这些提交上构建自己的更改。如果您稍后决定重新提交您提交的内容,则基本上会使旧提交无效并对其进行所有更改。 - 即使你删除旧的分支,另一个可能会推动他的更改,因此也会推动旧的更改,这会导致重复的提交和解决混乱。 :) – michas
再次,非常感谢。我一直在阅读关于'git pull --rebase',并不是100%,如果我在当前(比如说)'my_branch'中调用它会发生什么。在这种情况下,命令从'my_branch'遥控器拉出来,然后重新绑定到......哪个分支?因为我没有在命令中的任何地方提及它,所以我不会假设主人。 所以它必须重新绑定'my_branch',这对我来说听起来有点奇怪,因为我总是重新设计了两个独立的分支。但我认为这是可能的,现在我想起它,为什么不呢? – larryq