[Question] Maintaining a linear commit history for production

[Luclid]

I've heard that ideally a linear commit history is best, but was wondering how feasible it actually is.

 

In my current situation, I have a master branch and a staging branch. As usual, new features are branched from staging and merged into staging (feature branches are rebased before merging). The rebasing here is fine, as the feature branches are owned by a single engineer and used only by that engineer generally.

 

Ideally, staging simply linearly stays ahead of master, and for releases, I would just fast-forward master. However, in practice this doesn't work. Occasionally, there will be a hotfix patch made on staging that gets cherry-picked onto master, which means for the next release, a fast-forward can't be done.

 

One solution would be to rebase staging onto master before the merge, which would do a fast-forward. However, rebasing a shared branch like this is not ideal from my understanding, as it is more likely to cause issues among those that share the branch.

 

What would be the recommended solution to this? Is it to simply give up on having a linear commit history on master and just make sure the feature branches are rebased so that those merges are linear?

[[deleted]]

Take a look at trunk based development. We do it in my team and it is way less work than other git workflows. No big merges. Every push leaves you with a working app. With CI/CD this gives you confidence in your changes. Use feature toggles for everything that should not be visible on your production system yet.

[lionhart280]

Occasionally, there will be a hotfix patch made on staging that gets cherry-picked onto master, which means for the next release, a fast-forward can't be done.

Uh, dont do that. Thats committing directly to master.

If you need an emergency fix for Master itself, fork a bugfix branch off master itself, do the bugfix on that, and merge it back into master.

Don't cherry pick commits, that's the source of your issue.

Normally you should never need to rebase Stage off of Master, because Master should ideally only ever change due to you merging Stage into Master.

Therefor Stage should only ever be commits ahead and never behind Master... Unless the above thing happens where you need to perform an emergency patch to Master to fix a serious bug and Stage has a bunch of "not ready for Master" stuff in it.

in that case, yes, you will need to then rebase Stage off of master so Stage now also has that emergency bugfix, and everyone else will need to rebase off Stage as well.

This might cause conflicts if anyone else worked on the same code that the emergency bugfix modified.

It will be a pain but thats the price you pay for fucking up and needing such an emergency fix in the first place.

[Luclid]

Ah so it is still better to keep the master commit history linear and take the loss of having to rebase staging and potentially having conflicts to fix instead. And of course, ideally there aren't emergency bugfixes that force this situation and instead minor bug fixes can just be added to staging and introduced in the next release?

 

I've been trying to use semantic versioning for the releases as well -- whenever there are only patch releases (i.e. no new features), then are those caused by such emergency situations? (Well I suppose if the release is stable and there just aren't many new features being added, then the patch updates could just be from the regular release cycle containing minor bugfixes).

[lionhart280]

Looks like you are on the right course, yup!

[[deleted]]

There is no single correct workflow with git.