Nicolas Sebrecht-3 wrote: > > 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. > Actually, there's no reason you couldn't just 'git reset HEAD^' once you realise that the branch isn't ready. If you want to see the changes from master, you could just merge that into your branch. If you just want to see the content in master, you could use gitk or gitg, which allows you to view files at any commit. Personally, I merge master into my branches, test and check, and fix, then merge the branch into master. This sometimes results in a fast-forward, if you haven't made changes to master. If you don't like that, you can always use the --no-ff option, though. Good luck, Tim. -- View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3992599.html Sent from the git mailing list archive at Nabble.com. -- 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