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.)

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 is effectively a synonym for Git tag 154.56.6?

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)?