0

First let me phrase my understanding of GitHub flow before asking the question:

In GitHub flow, we have a main branch, and feature/topic/bugfix/whatever branches branching off that main branch. Once ready, this topic branch is then merged into the main branch. It is important to make this separation between the development branches and main branch in order to have main always pointing to a good-to-go commit. Usually, those merge commits to main will be tagged with a version number.

So my question is: Why is it important to have the main branch always pointing to a good-to-go-commit? Why can't we rely on the tags on the merge commits to point us to a ready/stable version commit? What is the added value of a git ref pointing to the latest good commit?

EDIT

My question refers to GitHub flow, as the title say. GitFlow introduces additional complexity so I still didn't think about whether or not this question is relevant to GitFlow. Anyway, that is discussed in Isn't the master branch just a surrogate of tagging in the gitflow

10
  • Does this answer your question? Isn't the master branch just a surrogate of tagging in the gitflow model?
    – gnat
    Jul 29, 2021 at 6:41
  • Partially. This thread refers to Git flow (Which I stated in the question that I haven't considered yet), and indeed the discussion in the comments chain of the question is more relevant to Gitflow. I would like hear people's thought regarding to GitHub flow.
    – YoavKlein
    Jul 29, 2021 at 7:00
  • Are you referring to Gitflow or Github Flow? The two models are not the same. Jul 29, 2021 at 13:13
  • I think you are kind of looking at it backwards, it's not that having a separate string of deployable commits is so much better than having a list of tags, it's the ability to branch off and independently develop / experiment / mess around in a distributed collaborative environment that's important (and git's super cheap branching model makes this easy). Jul 29, 2021 at 14:36
  • The main branch doesn't always point to a good-to-go commit. The PR branch may have been tested before it was merged to main, but the merge operation may result in a new version of the code that's never been seen before. It's possible that merging what's on the feature branch with what changed in main can create something bad. So the result of the merge has to be tested before use.
    – bdsl
    Sep 23, 2023 at 16:26

2 Answers 2

4

It's important to have the main branch pointing to a good, stable commit in GitHub flow because that's what GitHub flow says.

Generally speaking, we give things names to make it easier to talk about them. People have developed branching models like Gitflow and GitHub flow to solve problems that they were experiencing on their teams or in their organizations. By giving these sets of rules, policies, and norms a name, they make it easy for people to talk about or discuss the pros and cons of the approach. If you say "Gitflow" or "GitHub flow" to someone familiar with the concept, they already understand how you work with no further details and someone who doesn't know about it can easily find reference material.

If you don't like the approach in GitHub flow, then perhaps Trunk-Based Development is a more suitable approach. This approach centers around commits to the main branch and creating release branches for release hardening and patching while allowing the main branch to continue along for the next release. Their website provides quite a few details into their rationale and even when it's not appropriate to use their model.

To answer your specific questions:

Why is it important to have the main branch always pointing to a good-to-go-commit?

It's not. See Trunk-Based Development for an example where the head of the main branch may not be a "good-to-go" commit, depending on the practices of the team and the requirements to release. It is, however, a requirement of GitHub flow because that is the definition of GitHub flow chosen by the creators.

Why can't we rely on the tags on the merge commits to point us to a ready/stable version commit?

There's no reason why you can't. I'm not sure if there's a well-documented and widely used version control strategy that takes this approach - I can't think of one at the moment. However, GitHub flow has chosen to not rely on the tags, but to rely on the head of the main branch to reflect the most recent stable release.

What is the added value of a git ref pointing to the latest good commit?

Easy access. It's a common theme across branching strategies that it's easy to access the "good" or releasable (or released) commits. Whether that's the head of the main branch, a tag, or a release branch (perhaps also using tags for patch releases). It doesn't matter how it's achieved, just that the people using the repository understand the structure and how to create a build of a given quality, either a release build, a release candidate, or perhaps bleeding-edge development.

6
  • 1
    I'm not criticizing, just asking for the rationale behind it. Your first paragraph can be translated to "just because". Saying that naming the model "GitHub flow" or "Git flow" iis for shared language doesn't say anything about the essence of the thing itself, so the second paragraph is completely not understood also. About the third - did I say anything about liking/dis-liking? I'm just asking for the rationale behind it. Was downvoting this answer if not the reference to "Trunk-base Development" - didn't know this one, so thanks for this.
    – YoavKlein
    Jul 29, 2021 at 11:37
  • 3
    @YoavKlein But "just because" is the answer. It solved the problems the creators were facing in a way that worked well for their teams at that particular moment in time. Then, they decided to write about it and give it a name. If you want to know more about what those problems were or what alternative solutions were considered, you'd have to explicitly ask the creators and not the general software engineering community.
    – Thomas Owens
    Jul 29, 2021 at 11:57
  • 1
    @ThomasOwens "It solved the problems the creators were facing in a way that worked well for their teams at that particular moment in time. " So what were those problems and how do these models solve them? I'm not disagreeing that they do (I find having a stable main branch to be very desirable), but your answer doesn't say why.
    – Polygnome
    Jul 29, 2021 at 12:31
  • 2
    @Polygnome The only one who can answer that question is the originator of the approach. Such a question is not appropriate for Software Engineering Stack Exchange. Questions asked here should not require the expertise of a single individual or small group, but must be reasonably answered by an engineer with proficiency in the topic. My answer represents what an expert in processes and methodologies would be able to say, without direct knowledge of the creation of the approach.
    – Thomas Owens
    Jul 29, 2021 at 13:46
  • 1
    "The only one who can answer that question is the originator of the approach." - I don't think that's true; anyone who does it, and is doing it because it has some business/operational value to them as a team/company, should be able to answer that question - the answers may not be exactly the same, but it should be possible to extract a common thread illuminating a shared underlying quality. Otherwise why even do it. Jul 29, 2021 at 14:16
0

I will be using this as my reference.

GitHub Flow centers around feature branches branched off a shared branch. Feature branches that make their way into main (previously master) by way of GitHub pull requests.

It is important to make this separation between the development branches and main branch in order to have main always pointing to a good-to-go commit.

Now you're skipping ahead a few steps. In order to have feature branches[1] you need some common base. That's the main branch. You could also get more advanced and have some feature branch a be branched from b. But in the end you will be able to trace that branching back to main (through however many steps).

  • Need to make a feature branch? Branch off main.
  • Need to synchronize with main? git merge main or git rebase main.

There are advantages to having a good-to-go base (main). That means that you can branch off and synchronize with main and not worry that something broke on that branch.

But we will get closer to the core of the issue after a few more replies.

Usually, those merge commits to main will be tagged with a version number.

No, that's not clear to me.

With GitHub Flow there is no need to habitually tag commits. Need a string to describe your commit that is slightly prettier than an abbreviated hash? Use git-describe(1).

Why do you need to make versions? At my day job (not that we use GitHub Flow but that's irrelevant) we make a new version (git-tag(1) etc.) when we deploy something to a customer. There might have been five or a hundred commits on git log --first-parent main between versions.

So my question is: Why is it important to have the main branch always pointing to a good-to-go-commit? Why can't we rely on the tags on the merge commits to point us to a ready/stable version commit? What is the added value of a git ref pointing to the latest good commit?

The “good to go” commits on main is primarily about having a good base for development.[2]

Well why should commits be good to go? The preference (not strict rule) part of this answers itself. Commits to main are already gated by pull requests. Hopefully pull request reviews will make sure that you introduce better version of main than before the merge. Most of the time. Regressions will happen.

Beyond that I sense that there is some unstated assumption about using tags that I don't understand, and perhaps there (in that unstated alternative approach) is where the rub lies? I have never used tags to either tag good to go or bad to go commits—if I had to I would probably use git-notes(1) to mark bad commits on main since they are hopefully the exception. So trying to keep main “good” and then optionally marking bad commits seems like the option with the least amount of administrative overhead, here.

Notes

  1. I'll call feature/bug fixes/hot fixes/really urgent pants-on-fire hot fixes or whatever else “feature branches”
  2. It might also be important to those who firehose all of their main commits to production or wherever else

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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