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

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

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"?

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

> 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.

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

To elaborate on Chris's response, as an alternative to merging to
feature from master repeatedly, you may want to take a look at git
rerere. The "Discussion" section at
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.htmlexplains a workflow where this feature is useful. You don't rebase,
and so preserve where the feature originally branched, but you also
avoid multiple merge commits from master that may clutter the commit
history. Essentially, you do a merge, resolve any conflicts, and then
back out of the merge with git reset --hard HEAD^. This removes the
merge commit, but rerere remembers all of the conflicts that you
resolved. When you repeat this process the next time, you won't have
to re-resolve conflicts that you've already taken care of.

Essentially, the history looks like you've developed the feature in
complete isolation of master, and fixed all of the conflicts at once
during the only publicly visible merge commit from feature back to
master. But what you've really done is solved the conflicts little by
little, so the final merge isn't a huge pain in the *ss.

This is probably a more advanced use case, and so might not be the
best approach to a team just getting their feet wet with Git, but
still, it's a workflow that does what you're asking.

> On 10 August 2010 21:20, Bradley Wagner <[hidden email]> 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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [hidden email]> More majordomo info at http://vger.kernel.org/majordomo-info.html>

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

I use a single branch, working, as a working branch. I NEVER publish
the tip of this branch. Rather, it always contains my working tree
which consists of:

- a base, which is a merge of:
- completed work I have yet to publish
- the upstream branch, as pulled at some previous time
- fixes from other people that have yet to be integrated into the upstream
- a linear series of one or more commits that I am currently working on
- the tip, or HEAD of the working branch.

* the base of my branch is a merge hell, but I don't care, because it
is built from well known, relatively stable dependencies - I can throw
it away and rebuild it any time relatively easily.

* my working tree remains stable - it always contains stuff I have
recently worked on, or stuff I want

* my topic branches remain clean and uncluttered with merges, so I can
release them to others without dragging unwanted stuff along

* merges tend to be trivial, since they are based on stable work.
rebases are usually easy, because they are used only used on a
relatvely small amount on unpublished, unstable work

This only downside to the workflow is the complexity of using an extra
branch (working-base) to track the base of the working branch. If you
forget to update it, you can accidentally do some stupid things (which
can be fixed by using the info in git reflog).

In fact, this workflow is so useful to me, that I believe it needs its
own git porcelain to assist with the management. I am, in fact,
developing two commands to do just this: git base and git work.

git base manages the base of the branch (using a reference called
refs/bases/<branch>) while git work helps to manage the workflow of
maintaining the base of the branch. With these two (as yet unpublished
commands), the workflows above become as simple as:

> 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.
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [hidden email]> More majordomo info at http://vger.kernel.org/majordomo-info.html>

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

> > 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?

> 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