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 It might help you
keep things organized. This is another option if you need something a
little more flexible:

Hope that helps.


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 
For more options, visit

Reply via email to