2

We're having a debate here on our server development team, and I'm struggling. I've always used master as source of record for production, with the master branch (or some designated release branch) acting as a long-running release branch. I'm in favor of using GitFlow for our process, releasing from master and tagging the releases, but right now, all I have is instinct and past experiences.

I'm not specifically looking for someone to tell me "this process is better than that process", but instead, to provide some evidence as to why a long-running branch (like master) plus tagged releases is a good (or a bad) thing. Does anyone have any specific evidence that it's better or worse than short-running release branches with tags on the short running ones?

edit: Information was requested about our development process: We're actually in flux right now. We've just migrated from SVN to GIT, and are in the process of decomposing a monolith into microservices (or at least decomposed monoliths). Essentially, we support multiple deployment environments, with a clone of each acting as an integration environment, and a development environment independent of the integration environment. The development teams verify work in the local environment and that gets pushed to integration for testing, then services get deployed to production from there. We currently have over 500 services in the monolith, and will likely end up with ~300+ separate microservices or so. Coupled with the dependency projects, we will likely end up with around 600+ separate git projects when we're all finished.

Improve this question
4
  • I'm afraid even asking for evidence will still produce opinion based answers to this question. Even if there is evidence, the question as it stands is too broad without knowing more about the development process your team uses.
    – Greg Burghardt
    Commented Nov 22, 2019 at 16:58
  • We're actually in flux right now. We've just migrated from SVN to GIT, and are in the process of decomposing a monolith into microservices (or at least decomposed monoliths). Essentially, we support multiple deployment environments, with a clone of each acting as an integration environment, and a development environment independent of the integration environment. The development teams verify work in the local environment and that gets pushed to integration for testing, then services get deployed to production from there.
    – Robert K
    Commented Nov 22, 2019 at 17:00
  • 1
    Please add this information to your question. It is too difficult to find this info in a comment.
    – Greg Burghardt
    Commented Nov 22, 2019 at 17:01
  • 2
    I don't understand this question. So long as you deploy to production from some branch, you have a branch (whatever it's named) that reflects what's in production. Unless you do something silly like develop in production. I always put a note in the git log when we release. It's the same commit that changes the version number.
    – candied_orange
    Commented Nov 22, 2019 at 17:22

3 Answers 3

Reset to default
8

Using the master branch as the canonical source for code in production makes it easier for developers to clone the repository and immediately have production code in front of them. It's as simple as:

git clone your-repo

If a different branch is used for production code, then the master branch still needs to represent something, otherwise it will cause confusion.

I worked on a project where we had a development branch (literally called "development") and then created a release branch from that. The master branch became this weird no-man's land of code that people forgot to update. This was annoying, because I was constantly reminding people — experienced team members included — that they needed to check out the development branch or a release branch.

Making it easy to clone the repository and see production code is basically the only reason. Otherwise just decide what "master" represents and stick with it, as long as you avoid the no-man's land situation I had, where "master" was never really used.

Improve this answer
3
  • 1
    It sounds like a large part of the issue here would have been solved by simply deleting the master branch if it didn't have any use, and setting development as the default branch of the repo.
    – bdsl
    Commented Mar 10, 2023 at 14:16
  • “If a different branch is used for production code, then the master branch still needs to represent something, otherwise it will cause confusion.” It represents the latest shared history that everyone bases their new work on. That was its original purpose.
    – Guildenstern
    Commented May 1, 2023 at 16:04
  • 1
    @Guildenstern: Greg's point is that in that particular project, it actually did not represent the latest shared history that everyone bases their new work on - there was a different branch that did that instead.
    – Alexander The 1st
    Commented May 1, 2023 at 23:48
4

Well, how else do you know what’s in prod? Download the live copy and recursive diff? Guess? Etc.?

In other words, it provides a useful comparison point and a useful assumption about whats live (though it is helpful to regularly check this assumption, which git fetch + some plumbing can easily show).

Improve this answer
4
  • 1
    The alternate solution is to create a release branch for testing, then tag the release branch when going to production. The release branch is shortly-used (but kept around) though, and only used until it is deployed. It would stick around for eternity as a record of what was / is deployed.
    – Robert K
    Commented Nov 22, 2019 at 16:52
  • 1
    Well, that could be a relevant question detail
    – D. Ben Knoble
    Commented Nov 22, 2019 at 16:59
  • 1
    @RobertK I think you should edit the info on the alternate solution into your question. The difference that I can see is if you need to support multiple releases at the same time (e.g you have customers on v3 and v4) then having a release branch is necessary, as you will provide fixes for v3 on the v3 release branch, and fixes for v4 on the v4 release branch. Company I worked at had about 3 or 4 active releases at time and used that structure.
    – DaveG
    Commented Nov 22, 2019 at 19:54
  • > know what’s in prod? You look at the record made when code was deployed to prod. Hopefully your deployments are automated, so each deployment should be recorded somewhere.
    – bdsl
    Commented Mar 10, 2023 at 14:17
1

The only benefit is if you want a stable name for “latest release”. That’s it.

You might just need to know what the latest version is. Maybe you don’t need a moving pointer named “master” or “production” or something like that.

If you do want it then you can use a branch that fast-forwards to whatever the latest “production” commit is. But keep in mind: if people don’t end up needing that name then they might just end up forgetting to update it.

(Let me quickly check what commit master is on at my job… oh, it’s the initial commit. We use a branch called develop as the main branch. We have no other eternal branches.)

Every release to production will probably get its own version tag (git-tag(1)). Or at the very minimum it will be associated with the commit it was built on (like with git-describe(1)). I would also prefer if every build on remote test installations (which are totally ad hoc) are also marked in such a way that we know what commit it was built on, because we want to know what code tree it was that produced a given stacktrace. (Same goes for production of course.)

Now let’s say you have five recent versions and you have fifteen different customers who are all on one of them, because

  1. Some version was made for one single customer so you didn’t need to update all of them
  2. Some version was deemed pretty safe for one product line but not for another one so deploying to those other customers was put on hold until a later release
  3. You wanted to upgrade customer A and B and needed a signoff from a contact person at each one but one of the contact persons had taken an early weekend and it’s Friday 13:00

What have you gained from the fact that your branch master (or release or production…) is effectively a synonym for Git tag 154.56.6 (the latest version)?

Improve this answer
3
  • 1
    Some of this answer gets a bit distracted by the name master, rather than the concept of "some designated release branch". For instance, it's not really relevant that you have a dead branch called master in your repo; you might still have a branch called "release" or "production" or "gold" that serves the purpose outlined in the question. The other parts of the answer about it not being useful in environments where there are multiple production deployments is more relevant.
    – IMSoP
    Commented May 1, 2023 at 17:56
  • @IMSoP I don’t really think it fixates on “master” given that I start the post with “stable name for “latest release”” and then in the next paragraph say ““master” or “production”” (as in: whatever name you have). It’s like the “default branch”: it gets a bit tedious to say “master or main or whatever your default branch name is”. But I’ll update the answer a bit. Thanks for the feedback. :)
    – Guildenstern
    Commented May 1, 2023 at 18:06
  • @IMSoP “you might still have a branch”—Good point. We don’t have any other eternal branches than develop. I’ve edited that in now. Thanks.
    – Guildenstern
    Commented May 1, 2023 at 18:08

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.