On Mon, 2013-03-11 at 10:54 -0500, Ryan Hodson wrote:
> 1) Use the topic branch as a short-lived branch that just serves as an
> isolated environment for you to do some work on a particular feature.
> This means you would delete it as soon as you merge it into master,
> because that "feature" is done, at least for the time being. When you
> want to start work on it again, create a new topic branch for it, and
> repeat.

> 2) Use the topic branch as a long-running feature branch. If you were
> to do this, you should *not* merge it into master until it's
> completely done. This means the topic branch would co-exist with the
> master branch as long as you're still working on it. If you need to
> pull in updates from master, then you would either a) rebase the topic
> branch onto master or b) merge master into the topic branch (but *not*
> the other way around).

I do #2... I work and merge from master periodically, then when I'm
ready to deliver I merge my topic branch back to master and I'm off
doing other things.  But then after a while I often pick back up the
branch to implement further features etc.  It's this last bit that seems
outside the norm... but I do it fairly often.

So your opinion is that it's better to delete the branch after I merge,
then recreate it later, rather than trying to force it to point to the
master post-merge commit so I can ff-merge it later?

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to