1

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.

  • 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 Nov 22 '19 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 Nov 22 '19 at 17:00
  • 1
    Please add this information to your question. It is too difficult to find this info in a comment. – Greg Burghardt Nov 22 '19 at 17:01
  • Edited... thank you :) – Robert K Nov 22 '19 at 17:09
  • 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 Nov 22 '19 at 17:22
4

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

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 | |
  • 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 Nov 22 '19 at 16:52
  • 1
    Well, that could be a relevant question detail – D. Ben Knoble Nov 22 '19 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 Nov 22 '19 at 19:54

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.