Paul, It sounds like you have one of two options:
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). Either way, you should pick one or the other. You typically shouldn't have a long-running feature branch that you continuously merge into master. As you've discovered, this makes for a lot of superfluous merge commits. We have a number of developers making lots of changes and our git repo is > REALLY complicated That sounds...not good. You should generally be able to make sense of your git repository. If you have so many branches and cross-merges laying around that you can't understand your history, you probably need to enforce some integration rules about which branches can get merged into which other branches and when they're allowed to do this. Have you read through http://nvie.com/posts/a-successful-git-branching-model/? It might help you keep things organized. This is another option if you need something a little more flexible: http://scottchacon.com/2011/08/31/github-flow.html. Hope that helps. Ryan -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
