Re: Working on merged branches whilst seeing current master

[Nicolas Sebrecht <nicolas.s.dev@gmx.fr>]

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