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