简短版本:
我想从本地分支(A)创建一个本地分支(B),并使其跟踪(A)正在跟踪的同一个远程分支。我怎么能在一个命令中做到这一点?有什么办法可以将此行为设置为默认行为吗?
完整说明:
我最近使用git-svn转换为“纯”git。我的工作流程的一个方面真的令人沮丧,我正试图找到一种方法来恢复该工作流程。以下是git-svn的用法:
git svn rebase
- A被重新定位到X的HEAD git svn rebase
- B被重新定位到X的HEAD 在纯粹的git世界中,我遇到的问题是,当(A)跟踪远程分支时,(B)不继承它。我知道我可以通过git branch --set-upstream (B) (X)
明确地设置它。我正在寻找的是一种自动继承这种跟踪行为的方法,所以我不必记得这样做,然后当git pull --rebase
无法工作时(B)让所有人感到沮丧。
我意识到这与“问题”在于它可能失去(B)由(A)制成的遗产。我只是不在乎。
有什么想法吗?
答案 0 :(得分:0)
您正在尝试将集中式工作流应用于分布式系统。你需要考虑在本地做事,而不是集中做事。共享(中央)存储库只是您想要与他人共享内容的地方,或者您检索他们想要共享的内容。
这基本上就是你所要求的。但是,我不认为这是最好的工作流程。请参阅下面的修改版本。
Create a new local branch (A) that tracks a remote branch (X)
git clone <url> my_repo
Do some work, make some local commits.
work, work work
git add .
git commit -m "commit of work"
A is rebased up to the HEAD of X. We're operating on the same branch
we want to rebase from the remote, so we can do it all with one command in
this case.
git pull --rebase
Do some work, make some local commits.
work, work work
git add .
git commit -m "commit of work"
Have an offshoot idea, make a new local branch (B) from (A)
git checkout -b idea
Do some work, make some local commits.
work, work work
git add .
git commit -m "commit of work"
B is rebased up to the HEAD of X
git rebase origin master
但......整个工作流程围绕遥控器作为“真相来源”。这样做的方式就越多,恕我直言就是把你的本地视为真相的来源,然后用中央存储库的共享内容来更新它。这是同样的事情,只是从不同的角度接近它。
以下是我的工作流程:
创建一个跟踪远程分支(X)的新本地分支(A) git clone my_repo 做一些工作,做一些本地提交。 工作工作工作 git add。 git commit -m“提交工作”
A is rebased up to the HEAD of X. We use two commands here, but doing
it this way makes it easy for me to view the differences before
doing the rebase, if I choose.
git fetch
git rebase origin/master
Do some work, make some local commits.
work, work work
git add .
git commit -m "commit of work"
Have an offshoot idea, make a new local branch (B) from (A)
git checkout -b idea
Do some work, make some local commits.
work, work work
git add .
git commit -m "commit of work"
B is rebased up to the HEAD of X
git fetch
git rebase origin/master
当然,这两种情况都取决于您在将origin / master重新定位到您的想法分支之前没有在本地主分支上执行其他工作的事实。如果你这样做了,那么你就不会在本地对master进行过提交,这样做会更有效:
git fetch
git checkout master
git rebase origin/master --(make sure master is up-to-date locally)
git checkout idea
git rebase master (apply idea on top of the updated local master)
答案 1 :(得分:0)
嗯,最简单的解决方案,但可能是部分解决方案,就是这样做:
git checkout -b B <remote>/X
git merge A
如果您在需要B之前已经将A推回到X,则不需要第二步。根据遥控器检出B会自动设置跟踪。
至于一步:
function myGitCo () { git checkout -b $1 $3; git merge $2 } # <smiley>
答案 2 :(得分:0)
熄灭了'bash
&amp; perl
编写脚本mojo并制作此解决方案,将其放入名为my-new-branch
的脚本中:
#/bin/bash
REMOTETRACKINGBRANCH=`git branch -vvv | perl -ne '/^\*[^\[]*\[[^:\]]+[:\]]+.*$/ && s/^\*[^\[]*\[([^:\]]+)[:\]]+.*$/\1/ && print;'`
if [ -z "$REMOTETRACKINGBRANCH" ];
then
echo "ERROR: No remote tracking branch." 1>&2
exit 1
else
git checkout -b $1 && git branch --set-upstream $1 $REMOTETRACKINGBRANCH
fi
我确信这可能会更简短,但是我厌倦了用shell逃避正则表达式并且暴力强迫它使用perl。
如果有一个更容易解析(并且不太可能像git rev那样更改)更多的plumbing-ish方法来识别远程跟踪分支,那将是很好的,但是AFAICT配置文件对于该位信息具有权威性,解析这似乎比解析git branch -vvv
更令人痛苦。