0

简洁版本:

我想从本地分支 (A) 创建一个本地分支 (B) 并使其跟踪 (A) 正在跟踪的同一个远程分支。我怎么能在一个命令中做到这一点?有什么办法可以将此行为设置为默认值?

完整解释:

我最近从使用 git-svn 转换为“纯”git。我的工作流程有一个方面非常令人沮丧,我正在尝试找出一种方法来恢复该工作流程。这是 git-svn 的情况:

  • 创建一个跟踪远程分支 (X) 的新本地分支 (A)
  • 做一些工作,做一些本地提交。
  • git svn rebase-- A 重新定位到 X 的 HEAD
  • 做一些工作,做一些本地提交。
  • 有一个分支想法,从(A)创建一个新的本地分支(B)
  • 做一些工作,做一些本地提交。
  • git svn rebase-- B 重新定位到 X 的 HEAD
  • 等等

在纯 git 世界中,我遇到的问题是,虽然 (A) 跟踪远程分支,但 (B) 并没有继承它。我知道我可以通过git branch --set-upstream (B) (X). 我正在寻找的是一种让这种跟踪行为自动继承的方法,所以我不必记住这样做,然后当我git pull --rebase在 (B) 上不起作用时感到非常沮丧。

我意识到这样做的“问题”是它可能会失去由(A)制成的(B)的遗产。我只是不在乎那个。

有任何想法吗?

4

3 回答 3

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

但是……整个工作流程都围绕着遥控器作为“真相的来源”。更多的 git 方式,恕我直言,将您的本地视为真相的来源,并使用中央存储库中的共享内容对其进行更新。都是一样的,只是从不同的角度来看。

以下是我如何处理您的工作流程:

创建一个新的本地分支 (A) 来跟踪远程分支 (X) 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 分支上做额外工作的事实。如果你这样做了,你就不会有你在本地对 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)
于 2012-05-18T16:36:56.013 回答
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>
于 2012-05-18T19:24:56.227 回答
0

掸掉 ol' bash& perlscripting 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 revs 更改)更接近管道的方法来识别远程跟踪分支,那就太好了,但是 AFAICT 配置文件对于该信息具有权威性,并且解析这似乎比解析更痛苦git branch -vvv

于 2012-05-21T12:39:02.610 回答