2

Pardon my ignorance here, but I'm attempting to put the "git-flow" model into practice (manually, without the git-flow toolset).

One concept I found interesting was the idea that there would be a master branch for which every commit was a bona-fide workable release. So you have your v1.0.0 commit on master tagged, then your v1.1.0 tag, and that's a nice 2-commit-long log when viewing master. But then you're ready to release v1.2.0 and your develop branch has 1000 intermediate commits, but you're ready to sign off and push the button to say "all right, it's release time".

My goal is to add a third commit onto the master timeline. I can see that the --squash option will let you add a single commit onto the master, so you view the master log and see your three commits: v1.0.0, v1.1.0, and v1.2.0. As lengthy and verbose as the develop branch may be, the squashing gets you down to a neat history for master where each version is an official release...no chance of grabbing an intermediate development commit off that!

It works, but the thing that troubled me is that looking in the network graph this produces a "disconnected" commit. There's no apparent relationship that Git understands tying this squashed third commit to all those thousands of additions to the develop branch. It seems to float alone, unlike the git-flow diagrams which are hand-drawn and always point things to things.

git flow hand drawn

Other options for merging which get the "merge arrow" (a.k.a. the multiple parents) seem to have the side effect of establishing a connection to the intermediate commits. So suddenly master isn't just these 3 blessed commits...it has expanded to include the full history of all these 1000 commits on develop. Kind of seems to defeat the purpose, if the point of master was to be a branch containing only releasable versions...but suddenly every intermediate state has a commit on master. 1003 instead of 3 master commits.

Git visualization is a bit sinister in that it glosses over duplication in branches. So the diagrams I see drawn on git-flow are pictures and not terminal printouts of git log etc. I am unsure what one is to expect from a statement like saying that master only consists of releasable versions.

Long story short: I can't find options that retain the "arrow-looking" relationship between develop and master at a release point unless they carry the full commit history. Should this worry me if I look at git-flow diagrams which have lots of arrows? In the scenario I outlined, should I look at the master history and see every intermediate develop version that was merged and a 1003 commit history, or the 3 commit history?

Roman
  • 19,581
  • 6
  • 68
  • 84
HostileFork says dont trust SE
  • 32,904
  • 11
  • 98
  • 167
  • If I understand you correctly, the option you're is [`--no-ff`](http://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff). – Roman Nov 30 '14 at 21:14
  • @R0MANARMY I have tried it, but it still connects the history. :-/ – HostileFork says dont trust SE Nov 30 '14 at 22:35
  • I guess it depends on what you mean by "look at master history." If you mean just using `git log` then eerl is probably right and you `--first-parent`. – Roman Dec 01 '14 at 00:00

1 Answers1

6

Is git-flow supposed to see a more compressed history on master than develop?

No. Basically (ignoring hotfixes and release candidate branches): master = develop + merge commits.

In the scenario I outlined, should I look at the master history and see every intermediate develop version that was merged and a 1003 commit history, or the 3 commit history?

That depends a bit on what particular view on the master history you request. But generally, you should see a history of 1003 commits.

History in git-flow

More generally, and picking up on some of your implied assumptions: using git-flow about preserving and connecting commit history. So merging with --squash is an absolute no-go, as it (as you have already observed) does not connect master with the line of development that lead to its release state. Quite to the contrary, you absolutely want to make sure that every commit to master is always a merge commit -- completely the opposite of what --squash does. That's why you always merge with --no-ff in git-flow. (In contemporary versions of Git, you can set the merge.ff option to false and stop worrying about forgetting --no-ff.)

Also note that Vincent Driessen's original git-flow article does examine these questions.

The Perils of Flattening

Be aware, that flat (linear) views will have to use a flattening strategy to simplify the full graph into a linear appearance. This flattening can be confusing.

As an example to think about, consider the second cyan node and the fifth yellow node in your example graph. Assume now, that the second cyan commit was made a day after the fifth yellow commit.

---1-----------------7----------10~~ master
    \              /           /
     2---3---4---5--6-----8---9~~~~~ develop

(I know that this is a rather contrived example in the context of git-flow. Without release-candidate branches, it is highly unusual to release "the second newest" commit from develop by merging it into master.)

If you now flatten this history from master perspective, how would you want it to be represented? Should you primarily use chronological ordering, thus giving you:

   10  9  8  7  6  5  4  3  2  1

(This chronological ordering is what default git log and Github's "commits" view will give you.)

Or would you want the commits integrated by a merge commit all appear next to each other?

   10  9  8  6  7  5  4  3  2  1

(This "topological" ordering is what e.g. git log --topo-order will show you.)

Or do you want only commits stemming from one ancestral line?

   10  7  1

(This most closely corresponds to asking "show me only the direct commits to master", which seems to be part of what you expect to see. In a git-flow setup, git log --first-parent on master will show you this view.)

earl
  • 40,327
  • 6
  • 58
  • 59