Process of updating a local branch from another with tracking

Process of updating a local branch from another with tracking

[Robert Dailey]

I have the following alias defined:
sync = "!f() { cbr=$(git rev-parse --abbrev-ref HEAD); git co $1 &&
git pull && git co $cbr && git rebase $1; }; f"

The goal is to basically update a local branch which tracks a branch
on a remote, and then rebase my local topic branch onto that updated
local branch.

I do this instead of just rebasing onto origin/master. Example:

git checkout master
git pull --rebase origin master
git checkout topic1
git rebase master

I could do this instead but not sure if it is recommended:

git checkout topic1
git fetch
git rebase origin/master

Any thoughts on the alias I created? I'm a Windows user and still new
to linux stuff, so if it sucks or could be simplified just let me
know.

And as a secondary question, just curious what people think about
rebasing onto a remote tracking branch. When I do merges I usually
refer to the remote branch, but during rebase I use the local branch
instead, but I don't know if there is any functional reason to not
skip the local branch and go straight to the remote tracking branch
(it saves a step).

Re: Process of updating a local branch from another with tracking

[Chris Packham]

On 13/02/14 10:55, Robert Dailey wrote:
> I have the following alias defined:
> sync = "!f() { cbr=$(git rev-parse --abbrev-ref HEAD); git co $1 &&
> git pull && git co $cbr && git rebase $1; }; f"
> 
> The goal is to basically update a local branch which tracks a branch
> on a remote, and then rebase my local topic branch onto that updated
> local branch.

Generally speaking there is little benefit in manually keeping a local
branch that just tracks a remote one because you already have a "remote
tracking branch" which gets updated whenever you fetch from that remote.
So you could be doing something like

  git fetch origin # or whatever other remotes you may have configured
  git rebase origin/master # or whatever branch you're tracking

You can also tell git this kind of information when you create your
topic branch and git will to this all for you.

  git checkout -b topic1 origin/master
  git pull -r # -r makes pull run fetch + rebase instead of pull + merge

If you already have a topic branch and you want to tell it what remote
branch (upstream) to track you can do that too.

  git checkout topic
  git branch -u origin/master
  git pull -r

> I do this instead of just rebasing onto origin/master. Example:
> 
> git checkout master
> git pull --rebase origin master
> git checkout topic1
> git rebase master
> 
> I could do this instead but not sure if it is recommended:
> 
> git checkout topic1
> git fetch
> git rebase origin/master

I do it all the time. Actually I set the upstream and I can just use
'git pull -r'.

> Any thoughts on the alias I created? I'm a Windows user and still new
> to linux stuff, so if it sucks or could be simplified just let me
> know.

Aliases are fine to save yourself some typing. In this case I think you
can just set the upstream branch and use 'git pull -r'. There is a
config option to make this the default but you probably want to be
comfortable with the difference between merging and rebasing before you
set that.

> And as a secondary question, just curious what people think about
> rebasing onto a remote tracking branch. When I do merges I usually
> refer to the remote branch, but during rebase I use the local branch
> instead, but I don't know if there is any functional reason to not
> skip the local branch and go straight to the remote tracking branch
> (it saves a step).

Branches are branches. You might use multiple local branches to separate
dependent topics that you're working on. You might do the same with
remote branches if you have topics based on other peoples work.