On Fri, Aug 26, 2011 at 2:16 PM, gitlist <gitl...@myword.co.uk
<mailto:gitl...@myword.co.uk>> wrote:

    A questions about branches and workflow...

On 26/08/2011 10:36, Vineet Naik wrote:
I am not a git expert but I would reset the doSomething branch  (
without  --hard ) to the commit when the code was uploaded to the
server. Then stash the changes and merge the doSomething into master
branch. Then create a new bugfix branch from master.

After fixing the bugs and commiting in bugfixes branch, checkout
doSomething and apply the stashed changes.

Later also merge bugfixes into master.

Here is a nice branching model to follow in future

Thanks for the reply. It's not really bugfixes that's the issue, it's how to handle overlapping development of two features. Feature 1 is being tested by the customer; I need to start work on Feature 2. But where to begin the Feature 2 branch?

What I've realised today is that it's quite possible that Feature 2 (much simpler) could be tested and deployed long before Feature 1 - IOW overtake it. I can't risk any of the unfinished code from Feature 1 going on the production server, so I have to start Feature 2 from the current master, as deployed, even if that means having to pull out some work which is on the Feature 1 branch.

I suppose I should not have allowed so much work to build up on the Feature 1 branch.

I've saw the nvie model some time ago and found it very useful in establishing a workflow. It's just this overlapping it doesn't seem to address.


Roddie Grant

You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to