my job is to build to spec and get things working

NOT to fuck around with git's exotic features so the fucking commit history "looks nice"

its called a version control system for a reason. SO YOU CAN CONTROL YOUR FUCKING VERSIONS

IF YOU WANT A NICE PLOT, GO READ A BOOK OR WATCH A DRAMA MOVIE AAAAAAAAAAAAAAAAAAAA

Which exotic feature are we talking about?

Warning, if you say rebase imma say gtfo.

unfortunately rebase and much worse (cherry picking, squashing, on and on). in my mind, git should be used with fetch, pull, commit, push, and merge. that's all. no risk of loss of history or modification ever

When i feel like reading a nice story with a clean plot, i just look at my well-curated git history.

And there is nothing exotic about rebasing, cherrypicking and squashing.

Conventional commits ftw

I must say that decently written commit messages and a good history is a requirement same as good documentation.
Don't have to overdo it but if you make a mess of it you basically undermine the reason we have a version history.

If I have to wade through 15 pipeline experiment commits to see what changed I'm going to kick you out of the team. (And yes this is a real world example)

@hjk101 see, i don't get this, because if you are at HEAD, you see the final solution they arrived at. if they are on a branch (which they should be on anyway), merge the branch and delete the old one. case closed

or waste your time mentally masterbating showing people how "cool" git stuff is by literally trying to change the past when it won't matter on the projects current status anyway

@hjk101 especially message that you can read in git blame xD

@fullstackcircus if you only care about head you don't need versioning at all. A single backup will suffice.

You have versioning for the history. So if you have a good history it's usable for all kinds of things. Just from this week I can give you a few examples:

1. Had to remove a temporary traffic tag that was created for another team. Searched the git log and reverted the commit from a year ago. Without the commit I would have forgotten one step.
2. Something funky was going on with V1 of an endpoint that had recently gotten a V2 aswell. Looked through the history, just scanning commit messages and could find the change made a month ago that introduced the weird behaviour.
3. Other team made a scheduling change so our users would see the downstream effect a day later. The clown that made the change was sick but the ticket and committee message just stated change made. Not the reasoning. Nobody on the other team knew. Changing it back can fuck something up. You won't see that in our repo. You will always find the reasoning behind settings changes. You just have to look at the history.

Again you don't have to overdo it I like to have a fast forward only history but if you like to have merge commits that is fine by me. If you like to break down some work in multiple meaningful commits in a single MR/PR, fine by me you don't have to squash. But if you have multiple broken or work in progress commits you better squash the shit out of it. If you forgot the ticket number you better use your fancy git skills to add it in there. If there are multiple merge commits in your feature branch rebase it or squash on merge please.
Your shit doesn't have to be pristine just highly usable for debugging etc.

??

@hjk101 can i introduce you to the startlingly common "you can only have one commit per major version, so rebase as your last action no matter what" method of maintaining public projects? if i make a commit where i fix the bug your public project has been stuck on for years, and the commit message is "ONE FUCKING SEMICOLON", and the total change count is -1 +1 (GCC 8 doesn't appreciate non-ASCII semicolons and someone had a mac), i'm not fucking rebasing for no reason to fulfill your bot actions, i'll just maintain my own fucking fork. rebasing to have a "clean" commit history can wipe out a lot even when people aren't being super clean and precise with commit messages.