3

I've seen branching models with a develop and master branch (with features being merged into develop first), where the master branch was always entirely part of the history of develop and would be fast-forwarded after the build runs and all tests pass. And I've seen others where the master branch would contain actual merge commits from develop, release or hotfix branches (so fast-forwarding wouldn't even be possible anymore). I believe the latter is the case in gitflow.

What are the benefits/drawbacks/trade-offs of each approach? It would seem to me that the first approach ensures that all code that went out to production is also in the develop branch. But it's unclear how hotfixes are dealt with then.

2

In Gitflow Workflow, an hotfix is a branch that is created from master and in the end is merged back in master AND in develop.

The general (and well known) idea behind the "don't directly commit on master", is to have in master, a state of your code that is completely safe to deploy in production.

However, it can serves other means. For Github, the master also serves as a tracking tool to know when a feature is put in production. If you commit on another branch and then fast-forward master on it, you will lose the merge commit, and by extension, you'll just put a lot of tiny commits in your master timeline, losing the ability to revert a whole feature by simply revert the previous merge.

Another problem with this approach, is to know WHEN you can release/deploy. If everyone commit on master, you will have to synchronize all the development to have a coherent state of your code. For monolithic releases with a clear scope, it can be ok, but in my case, as an integration developer, features come and go and you have never a single point in time when "all features are done".

However, not commit in master does not mean having a branch master and a develop. As pointed in the Github presentation, if you do a feature branch workflow, you can work only with a master, creating a branch for each feature, and merges them back in master (without fast-forward) at the end.

In my humble opinion, Git Flow (master/develop + features/hotfix/release branches) is more adapted in a context where you don't really know when you'll have to release it (not at each feature done), and when the last release is often the one to hotfix. A gitflow chart can be convoluted, while a feature branching workflow is often more simple to read. The "noise" is often due to release/hotfix commit in what will be deleted branch some minutes after.

Example for Gitflow

Example for gitfow

Example of graph for Feature Branching Workflow

Example for feature branch workflow

  • If you commit on another branch and then fast-forward master on it, you will lose the merge commit, and by extension, you'll just put a lot of tiny commits in your master timeline, losing the ability to revert a whole feature by simply revert the previous merge ==> that's not true: if you fast-forward master on develop, you only have the merge commits from the feature branches into develop. In the gitflow picture there aren't more commits in develop than in master. – herman May 23 '17 at 12:07
  • The interesting part is the opposite : there is additional commit on master than in develop, specially the one for "Tag 1.0". If you create a branch "test", commit two times in it, and then merge --ff master, master will have the additional two commits, nothing more. If you specify the --no-ff, you'll have a third commit, the "Three-Way merge" that is a clean point of when the merge has been done. You dont have that in -ff. For information, gitflow is a --no-ff unless for feature branch with a single commit in them. – Jonathan Schoreels May 23 '17 at 12:15
  • None of the two cases I described allow for master to be fast-forwarded on a branch "test". Both assume having a master and a develop branch, but one uses -ff merge from develop to master (not from any other branches). Hence, if other (feature) branches are merged to develop with an explicit commit, fast-forwarding master will mean master will also only have the merge commits in its linear history. – herman May 23 '17 at 12:42
  • Note that I tagged this question "gitflow" because I know that at least the official gitflow model has merge commits in master that are not in develop. But some people seem to use an adapted model where master can be fast-forwarded on develop, for example after all tests pass. – herman May 23 '17 at 12:46
  • the name "test" was an arbitrary name for "another branch". Suppose the following scenario : You have two branches, master & develop (develop forked from master, as usual). You code a feature "Feature" in 3 commits in one day (T), "FeaturesCommit1", ""FeaturesCommit2", ""FeaturesCommit3". 2-3 days after (T+3), the manual test are all passed, and you can now merge Feature in master. If you use fast-forward, you'll have the 3 previous commit in your master. If you don't use fast-forward (git merge --no-ff master), you'll have a three-way commit merge that tell you that the feature has been – Jonathan Schoreels May 23 '17 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.