git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
CMChris Mear <chrismear@gmail.com>
Date
Aug 10, 2010, 22:05 UTC
Message-ID
<AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com>
In-Reply-To
<AANLkTi=h2MbSKmQk9p6w44WORAa8XzkpF0nBXKOgJ4T1@mail.gmail.com>
On 10 August 2010 21:20, Bradley Wagner <bradley.wagner@hannonhill.com> wrote:
Show 18 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.

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
Previous: Ævar Arnfjörð BjarmasonNext: Joshua Shrader
Message 3 of 6 in “workflow for working on feature branches and incrementally incorporating "master" changes”
  1. Bradley WagnerAug 10, 2010
  2. Ævar Arnfjörð BjarmasonAug 10, 2010
  3. Chris MearAug 10, 2010
  4. Joshua ShraderAug 10, 2010
  5. Bradley WagnerAug 13, 2010
  6. Jon SeymourAug 10, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.