Does git-flow enforce linear histories on some branches

Question

I am still trying to move from git towards git-flow. I know I can use any kind of git feature within git-flow, but I am mostly interested in what it handles automatically.

Let's assume there are two developers Alice and Bob, working on feature A and B respectively. When Alice is done, she can do a git flow feature finish A to create a merge commit on her local develop branch based on commit C. Now if Bob finishes his feature at the same time, and he fetched the same stuff, his merge commit will also be based on C. Now if Alice pushes and then bob fetches again, he will have to merge or rebase and we end up with a non-linear history on the develop branch, in case he merges.

Is this correct so far, or does git-flow somehow handle this situation automatically? If there is some automatic mechanism, what will have to be set up for this to work?

The simplest solution would probably be to always fetch develop before finishing features. However I am not sure that this is actually possible, depending on the way the repository is shared (might not be available at that time).

EDIT (clarifications of the problem):

As the answers suggest, my example was not clear. So first a picture of what I think is the problem:

C is the initial commit on the develop branch.

Alice creates some feature work on the feature branch:

develop    feature/A
|           |
v           v
C-A1-A2-A3-A4

At the same time Bob also does work for another feature

C-A1-A2-A3-A4
 \
  B1-B2-B3-B4

Now Alice finishes the feature and the merge commit is added to develop (I want that).

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA

Now Bob finishes the feature and again a merge commit is added to develop (I also want that, just at another place:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA <- develop for Alice
 \
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

However now either Alice or Bob has to merge develop, creating an additional commit:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA-MAB <- I don't want this MAB commit
 \               / 
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

What I would like to have instead would be something like this:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA-MB
 \               / 
  B1-B2-B3-B4- -

As you can see, the history is still non-linear, however the main line of the develop branch only contains the merge commits from features (and no additional merge commits as in the other case).

What I like about this, is that you can easily follow changes in the history and see if they belong to former feature branches or if they were merges in develop. All this information can be derived directly from the DAG.

Also if you use good messages for your merge commits on develop, in the second case you can easily derive a changelog, by always following the first parent on develop. However in the second case you sometimes need to follow the first parent only and sometimes more than one parent. And I cannot see an easy way when to do which that I could code up.

Answer 1

git-flow does nothing like that.

It's intended to support the branching model described here (which is really just a pretty picture for the kinds of things Git developers recommend). That picture includes merges. You'll see the same all through the text. Under each type of branch, you'll see the types of branches they should be merged into. There are example commands, using --no-ff to forcibly avoid linear history, and instead record merge commits.

This is a workflow that really uses Git, and one of Git's core strengths is branching and merging. This workflow thrives on merging; nonlinear history is not only unavoidable but desired.

You should read the section titled "Incorporating a finished feature on develop" from the description of the workflow. A short quote:

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

...

Unfortunately, I have not found a way to make --no-ff the default behaviour of git merge yet, but it really should be.

You want those merge commits. You really do.

Answer 2

Jefromi is right about that there is no harm in having that MAB merge in the history.

There is a way to avoid this commit, by the way that the one (lets say this is B), who pushes his feature merge to the central repo, does not merge the other merge commit (here MA) into the own history. Instead the second one has to destroy the local merge commit(MB), and redo the merge, where the first parent now is not C, but the merge commit of the first one(MA). So the second developer now creates a merge which contains the other merge and the own branch (the new MB).

Personally I wouldn't care about the MAB commit, but doesn't want to explain all the steps needed to get the MAB free history to people new to git.