Can someone comment on the usefulness of the master branch in Git Flow?

Question

I'm relatively new to Git, but not to release engineering. It seems that in Git Flow one could omit the master branch and not lose any information. If the master is required by convention or design, then the functional use of the dev branch could be migrated to master (I'm supposing this to preempt an answer like "you have to have a branch called 'master' ").

However as a matter of clarity and housekeeping I can see the usefulness of the master branch (the anxious period where a bug has been found in a released version of the source and we need it stat!), and the overhead is basically zero. I'm just pointing out that it doesn't provide any information not contained in the other branches and potential tagging in the approach of the original article. Did I miss something?

Answer 1

The master branch does have an implicit assumption - that all the releases occur in numeric order - for example that 1.1.0 will always occur at a later date than 1.0.1. If you're lucky enough to work on a project like this, then it's great.

On more complex projects where you may need to maintain multiple releases at once (for example the Linux kernel) you may need to make 1.0.1 AFTER you've made 1.1.0. While you could stuff all these into the master branch in this order, the master branch really isn't representing anything useful.

These sort of projects are more more likely to tag the release branches, and ignore the master branch completely.

Answer 2

Here's a paragraph from Atlassian's Gitflow Workflow

Hotfix Branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with master. (...)

---

You mention that you're relatively new to git. Gitflow is not the only kid in town. You may check out Git Feature Branch Workflow, and other flows...

Answer 3

Even though rebasing a published branch is most certainly not perceived as best practice, yet we (small team of devs) found ourselves in the situation were we cleaned up, and rearranged our develop branch from time to time, which sometimes resulted in changed hashes for commits. Having dedicated milestone commits with tags on master certainly helped when organizing our work.

You can also apply git-hooks exclusively on certain events on your master branch.

Answer 4

It seems that in Git Flow one could omit the master branch and not lose any information.

On most city's streets you could remove all but one building's street number and not lose any information[1]. What you would lose is the ability to easily do things that routinely need to be done - like find the specific building you're looking for without having to could from some reference building.

What the master branch stores is the order and timing of releases (and hotfixes) becoming "final". Assuming you tag releases and follow some conventions you can store all of that information without the master branch. But:

1) The user has to define the relevant conventions (such as tag names), whereas all the information conveyed by the master branch is found in structures defined by git

2) Your information quality depends on how well people to follow the rules. In a tag-the-release-branches-only approach, if someone deletes or moves a tag for any reason, then you lose information. It's much harder to lose the information encoded in the commit history behind master.

3) The master branch makes the information easier to use. Need to add a hotfix to the current release? (Or just need to check out the current release?) Use master and don't worry that you could key in the wrong tag name and end up doing the wrong thing.

---

[1] Or another example based on a conversation with a coworker years back: A radio station could just post their song list, and you wouldn't lose any information relative to having them broadcast each song.

The point is, you're asking for comment on the usefulness of a structure, to counter the observation "it doesn't add information". But that's not very meaningful. When systems are used by people, stripping them down to the minimal representation of information almost always removes useful functions.

The only thing in my experience that could even be represented as close to a counterexample would be relational data modeling, where you want to strip away redundant representations (normalize). But even then, what you really want is to keep redundant structures (like indexes) but ensure that they're systematically maintained by the software instead of being updated by the user - because a database without indexes is often just not useful.

Answer 5

The Git Flow branching model, while being very popular and also very successful, has one flaw that makes it somewhat unfit for Git if you think about it: Branches in Git are not lines, and commits do not belong to a branch. Instead, branches are pointers to a single commit within the history graph of Git, and all commits reachable by the starting commit are considered to be on the branch.

So assuming strict lines in the branching model and a clear branch-ownership of changes—while useful to understand the idea—does not match how that exactly looks in Git.

That is why theoretically, a separate master line makes a lot of sense when looking at the branching model: On the master line only those commits that actually “release” the product are visible. But in practice, by merging, you are moving all the commits basically over to that branch.

In addition to that, Git Flow also assumes a clear release strategy with properly versioned and planned releases. But a lot of things are not actually based around releases but have a more continuous release system (e.g. continuous delivery). As such, one may find that adhering to Git Flow strictly does not work that well for a particular project.

In the end, it is just a suggestion. There are many different workflows with Git, which all have their own benefits. You and your team should think about how you want to work and then design your workflow around that. Take some ideas from prominent workflows like Git Flow, but don’t be focused too much on following it completely.