Re: workflow for working on feature branches and incrementally incorporating "master" changes

From: Bradley Wagner <bradley.wagner@hannonhill.com>
Date: Aug 13, 2010, 20:38 UTC
Message-ID: <AANLkTi=tJ1i6C5WANY0qP1Zz1aa5HBAq7+-Ft4sa=+TE@mail.gmail.com>
In-Reply-To: <AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com>

Thanks for the explanation Chris! That definitely helps.

Show 30 quoted lines

> > If you're working on a feature branch by yourself, what is a good
> > workflow for keeping the branch in up-to-date with "master" as you're
> > developing on the feature branch or is this unnecessary? Should you
> > just wait until you want to officially integrate the feature branch
> > into the "master"?
> >
> > We were doing:
> >
> > commit to local feature branch
> > push to remote feature branch
> > ... repeat....
> > rebase from master (occasionally)
> > push to remote
> >
> > but at this point the branches have diverged.
> >
> > We're coming at this from SVN, so we might just be thinking about this
> > the wrong way.
>
> Git's rebase feature is a *very* nice, clean way to keep a feature
> branch up to date with the master branch. But, as you've seen,
> rebasing can make things a bit confusing you need to push that feature
> branch to other people.
>
> I've found that a good rule of thumb is to never rewrite (i.e. rebase)
> branches that have already been shared with others. Of course there's
> nothing impossible or fundamentally bad about pushing rewritten
> branches like this. But, unless people are expecting it to happen and
> know how to deal with it when they pull, it can cause confusion,
> particularly on teams that are just getting acquainted with Git.

Two questions here.

First, the command to rebase based off another branch that is *not* the upstream branch involves --onto, correct? For example, if I've been working on branch awesome_feature and I want to rebase using all the work that's been done in master since my branch was created, would I use: "git rebase --onto master <upstream_repo_name>"

Secondly, as someone pulling a branch that has been rewritten, do I use the --force flag: "git pull --force" or will rebasing suffice?

Show 16 quoted lines

> Instead, if a feature branch is going to be shared with others, and
> it's going to be long-lived, then we keep it up-to-date by merging
> from master every now and again, rather than rebasing.
>
> On the other hand, if I'm working on a feature branch by myself, and I
> haven't shared it with anyone yet, I frequently rebase against master
> to keep things clean. I also use interactive rebase a lot to tidy up
> commits. But as soon as I've shared my branch with the team, I no
> longer do any rebasing/rewriting.
>
> If there are Git wizards on your team, it is true that they may find
> this an inflexible way of working. But I've found it to be a good
> compromise between ease of pulling and maintaining a clean commit
> history.
>
> Chris