Re: Working on merged branches whilst seeing current master

The 11/11/09, rhlee wrote:

I use branches for features. I have a branch and I merged it into my master
branch as I thought it was finished. But it turns out I wasn't and so I need
to work on it again.

I have made some more changes (branches and merges) on master. So what I
should do is checkout that branch, work on it committing along the way and
then merge it again onto my master branch.

However I though I am working on a feature branch I want to be also working
from the master branch as reference.

If the feature branch is merged to the mainline, it should really mean
that the feature is ready : the feature branch life stop here. This also
means that if you see that this feature was not as ready as you thought,
you have to restart a _new_ feature branch off of the mainline.

That's why there is the "next" branch in the git releases process. This
way, we can test the feature branches without touching master for some
time.

                                     Yes I know I probably should not be
working like this. My branches should be wholly independent. But I doing web
development not kernel development so there is much less modularity and
branches/features have a tendency to creep into one another.

This should not be the case. Modularity in the release process and the
development strategy is not tied to "what I am developing". I'm doing
some web development too and have no difficulty around this point.

Or should I just create a new branch? But if I do this there is no link
between the old and new branch.

Yes, feature branches have no reason to live after they are merged to
the mainline.

-- 
Nicolas Sebrecht