git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mear <chrismear@gmail.com>
To: Bradley Wagner <bradley.wagner@hannonhill.com>
Cc: git@vger.kernel.org
Subject: Re: workflow for working on feature branches and incrementally  incorporating "master" changes
Date: Tue, 10 Aug 2010 23:05:16 +0100	[thread overview]
Message-ID: <AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=h2MbSKmQk9p6w44WORAa8XzkpF0nBXKOgJ4T1@mail.gmail.com>

On 10 August 2010 21:20, Bradley Wagner <bradley.wagner@hannonhill.com> wrote:
> 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.

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

  parent reply	other threads:[~2010-08-10 22:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-10 20:20 workflow for working on feature branches and incrementally incorporating "master" changes Bradley Wagner
2010-08-10 21:02 ` Ævar Arnfjörð Bjarmason
2010-08-10 22:05 ` Chris Mear [this message]
2010-08-10 22:26   ` Joshua Shrader
2010-08-13 20:38   ` Bradley Wagner
2010-08-10 22:32 ` Jon Seymour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com' \
    --to=chrismear@gmail.com \
    --cc=bradley.wagner@hannonhill.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).