最少的命令来重新建立私有分支 [英] Least number of commands to rebase private branch
问题描述
我仍在对Git充满信心，因此仍在谨慎地尝试其中的一些要素.
I'm still in the process of getting confident with Git so am still treading carefully with some elements of it.
我在工作时需要重新设置我的私有分支的命令列表(因此到完成时它不会过期)
The list of commands I have for rebasing my private branch as I work (so it does not become out of date by the time I'm finished) is:
# Prepare the new private branch
git checkout develop
git pull origin develop
git checkout -b new-feature
# work, commit, work commit, time to rebase...
git checkout develop
git pull develop origin
git checkout new-feature
git rebase develop
# continue working...
我想知道的是，我是否可以保存一些步骤，并在需要重新设置基准时执行以下操作:
What I'm wondering is if I can save a few steps and do the following when I want to rebase:
# on the new-feature branch
git fetch
git rebase origin/develop
# continue working....
还是当我将我的私有分支与developer合并时会引起问题吗?如果可以的话，如果我已经在私有分支中完成了此工作，是否需要将origin/develop与develop合并?
Or will that cause problems when I come to merge my private branch with develop? If it's ok, do I need to merge origin/develop with develop if I've already done that in my private branch?
推荐答案
上面概述的获取和重新设置很好.对于第二个问题，我不太确定您要问的是什么，因此以下内容将覆盖所有基础.
The fetch-and-rebase as outlined is just fine. For the second question, I'm not quite sure what you're asking, so the below covers all bases, as it were.
(请注意，除非您将git pull主要是git fetch后跟git merge，除非您将其配置为例如执行rebase.我假设您在下面仅使用git merge已经做了足够近的fetch.)
(Note that git pull is mainly just git fetch followed by git merge, unless you configure it to do rebase for instance. I'm going to use only git merge below, on the assumption that you've done a sufficiently-recent fetch.)
假设您在origin/develop上正在进行的活动，并在Origin/develop上提交D1的起点，这就是您将得到的:
Here's what you'll get, assuming ongoing activity on origin/develop and a starting point at commit D1 on origin/develop:
... - M6 <- master, origin/master
\
D0 - D1 <- develop, origin/develop
\
N0 - N1 <- HEAD=new_feature
现在您要做git fetch，他们"已经添加了D2和D3.我将忽略主服务器和原始服务器/主服务器，假设他们没有移动(如果有的话也没关系)，为本地设备留出更多空间:
Now you do git fetch and "they" have added D2 and D3. I'll leave out master and origin/master, assuming they haven't moved (if they have it doesn't matter anyway), leaving more room for local stuff:
D2 - D3 <- origin/develop
/
D0 - D1 <- develop
\
N0 - N1 <- HEAD=new_feature
所以现在(使用HEAD=new_feature，所有都指向提交N1)，您可以执行以下操作:
So now (with HEAD=new_feature, all pointing at commit N1) you do:
git rebase origin/develop
和git这样做，进行两个新的提交N0'和N1':
and git does this, making two new commits N0' and N1':
N0' - N1' <- HEAD=new_feature
/
D2 - D3 <- origin/develop
/
D0 - D1 <- develop
\
N0 - N1 [abandoned]
被放弃的提交最终会消失(我将它们留在下面)，同时您添加N2，并且它们添加D4.因此，您git fetch和git rebase origin/develop给出:
The abandoned commits eventually fall away (I'll leave them out below) and meanwhile you add N2, and they add D4. So, you git fetch and git rebase origin/develop, giving:
N0' - N1' - N2 [abandoned]
/
| N0''-N1''-N2' <- HEAD=new_feature
| /
D2 - D3 - D4 <- origin/develop
/
D0 - D1 <- develop
和以前一样，遗弃"的东西可以被遗忘，这为您提供了一个很好的干净的变更历史记录(无论是多少次重新建立了基础)，这些历史记录从origin/develop的末尾开始延伸.
As before, the "abandoned" stuff can be forgotten-about, which gives you a nice clean history of your changes (however many times rebased) extending out from the end of origin/develop.
在此过程中的任何时候都可以，但不必:
At any point along the way you can, but do not have to:
git checkout develop && git merge origin/develop && git checkout new_feature
由于您尚未在D1上添加任何提交，因此这只是快速前进，因此develop指向与origin/develop相同的提交.
Since you haven't added any commits onto D1, this just fast-forwards, so that develop points to the same commit as origin/develop.
假设您尚未操作本地develop，但是现在是时候在new_feature中进行合并了，现在您有了:
Let's say you haven't manipulated the local develop yet, but it's time to merge in new_feature, and you now have this:
N0''-N1''-N2' <- HEAD=new_feature
/
D2 - D3 - D4 <- origin/develop
/
D0 - D1 <- develop
大概您希望通过上图中的提交N2'与端点origin/develop合并.您当然可以立即执行以下操作:
Presumably you'll want to merge up through commit N2' in the above diagram with the endpoint of origin/develop. You can certainly do this now:
git checkout develop # get HEAD onto develop breanch
git merge origin/develop # fast-forward local develop branch
为您提供了这一点(我会理顺D1和D2之间的纽带):
which gives you this (I'll straighten out the kink between D1 and D2):
N0''-N1''-N2' <- new_feature
/
...D1 - D2 - D3 - D4 <- HEAD=develop, origin/develop
但更有趣的问题是，您是否希望最终结果是:
but the more interesting question is, do you want the final result to be:
N0''-N1''-N2' <- new_feature, HEAD=develop, origin/develop
/
...D1 - D2 - D3 - D4
还是应该像这样:
N0''-N1''-N2' <- new_feature
/ \
...D1 - D2 - D3 - D4 ------------ M <- HEAD=develop, origin/develop
?如果要合并提交M，则最后一个git merge命令将需要一个--no-ff参数，并且需要获取指向该提交D4的本地develop首先.在这种情况下，您必须进行快进合并以使develop标签指向D4:
? If you want that merge commit M, your final git merge command will need a --no-ff argument, and you need to get the local develop pointing to commit D4 first. In that case, you must do the fast-forward merge to get the develop label to point to D4:
git checkout develop # set HEAD=develop
git merge origin/develop # fast-forward develop to origin/develop
git merge --no-ff new_feature # create merge commit M on local develop
git push origin develop # and push local develop to origin/develop
但是，如果您不想要合并提交，那么在执行最终的merge时，develop指向的位置并不重要，因为它只会快速-向前.因此，您应该这样做:
If you don't want the merge commit, though, it doesn't matter where develop is pointing when you do the final merge, as it is just going to fast-forward. So, instead, you would do this:
git checkout develop # set HEAD=develop
# git merge origin/develop # optional: not needed, but harmless
git merge new_feature # fast-forward local develop to new_feature
git push origin develop # and push local develop to origin/develop
通常总是先弄清楚我要最终完成什么提交图".如果您可以绘制所需的图形，那么无论从现在到现在，都更容易弄清楚如何到达那里.
It's always a case of figuring out "what commit graph do I want to end up with" first. If you can draw the graph you want, it's a lot easier to figure out how to get there from wherever you are now.
这篇关于最少的命令来重新建立私有分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
