How product companies actually manage their git branches

Every git tutorial shows you the same tidy picture. A main branch, a develop branch, a few feature branches that merge back without trouble. Then you join a product company, ship your first change to production, and it looks nothing like that picture.

I have shipped code to production two very different ways. One of them I hate. The other I now use in my own projects.

Both get your code to the same place, live in front of users. The difference is simple. Does your change move forward, or do you copy it by hand?

The way I hate: copying the change into every branch#

In the first setup you keep one branch for each place your code runs. One for prod, one for uat, one for stage. Three branches, sitting side by side.

You write your change against prod. But you cannot test on prod, so to try it on stage or uat you do this. You cut a new branch, copy your change onto it (that copy step is called a cherry-pick), open a pull request, and ship it once it is approved. Then you go back and merge the real change into prod.

So now the same change has been copied into three branches by hand.

And every copy is a chance to get it slightly wrong. Miss a commit. Fix a conflict a different way. Grab a slightly older version. So the thing you tested on stage is not always the thing that goes live. You test one copy and ship another.

It works. Plenty of teams run this way for years. But it asks a person to keep three branches exactly the same, forever. People are not good at that.

What I do instead: move one change forward#

The second setup also has three branches: prod, preprod, and stage. But this time only prod is the real one. preprod and stage are just copies of prod. You can rebuild them from prod whenever you want, and they stay in sync with it.

The change moves in one direction. You cut a branch off prod, make your change, and open a pull request into stage. Once it looks good there, you open a pull request from stage into preprod. Once that looks good, preprod goes into prod.

Everyone else's changes ride the same path. Approved on stage, they move up to preprod. Solid on preprod, they move up to prod. The change only ever moves forward, one step at a time.

Nothing gets copied. The exact change you tested on stage is the exact change that reaches prod, because it was never re-made. It was just moved.

Why the copy way breaks down#

Forget the branch names. The whole difference is direction.

The first way moves your change sideways. You keep the same change in three branches and copy it between them by hand. So:

• the same change lives in three places, and each one can slowly drift,

• what you tested may not be what you ship,

• the branches grow further apart the longer they sit,

• and someone has to remember every copy, or it quietly goes wrong.

The second way moves your change forward. There is one real branch, the others are just copies of it, and the change is moved, never re-made. What you tested is what you ship. Nothing can drift, because stage and preprod can always be rebuilt from prod.

The rule: move it forward, never copy it#

If you ever get to choose how your team ships, pick the way that never asks a person to keep the same change identical in two branches at once.

Let the extra branches be copies of prod. Let your change move in one direction. Move it forward, never copy it sideways.

That is the whole idea. The rest is just branch names.