Please help with a Git sanity check

[iamgigglz]

I work in a small dev house with a handful of Devs, all with different ideas of how Git should work. This obviously causes chaos.

As "Senior Dev" (supposedly) I'm trying to bed down a coherent strategy for us to all follow, but I'm getting push-back from my old-school boss.
My suggestion is thus:

• Main, Test and Dev branches maintained as 1:1 with our deployed Live, Test and Dev environments. (We use the "Dev" environment for internal local testing)
• Feature branches are created off Dev, potentially with individual dev contribution branches off each feature branch (although it's usually 1 dev per feature).
• Squash commit from feature branch into Dev branch, deleting feature branch at the same time.
• If further changes are required for that feature, you create a new branch off Dev for that. Squash commit and delete when done.
• Changes are then merged up from Dev to Test to Main when needed.
• Branches for "Hot-fixes" (shudder) are made off the Test branch. When done, squash commit & delete, and deploy to Test for testing. Merge up to Main when done. Changes would obviously have to be merged down to Dev asap.

I know this isn't necessarily best practise etc but I'm trying to keep it as simple as possible.
My boss doesn't like the idea of losing the detailed commit history in the squash, especially the "git-blame" detail when multiple devs are involved. My argument is that git-blame shouldn't replace comments, documentation and links to work items.

What say you, oh wise forum?

 

[Dr Jack]

Every halfway sane git strategy has something to be said both for and against it; it's a matter of picking a compromise rather than choosing the best possible approach.

I think there is value in using squash to clean up a feature branch so that you're not getting a bunch of WIP commits fuggling up the history and you don't want to couple the rate of commits during dev to the rate of commits you'd want in the history but I also think that completely squashing history on a branch is a bad idea. In my view, blame is orthogonal to comments, documentation, etc and it both provides information they don't and shouldn't. Blame is useful for finding when bugs entered the code, for understanding how and why code changed over time, and for knowing who to go and talk to about why something has changed and is the way it is.

I favour rebase over merge where possible.

 

[iamgigglz]

...and for knowing who to go and talk to about why something has changed and is the way it is.

My objection to this is I don't remember the rhyme or reason behind every line of code I changed a year or more ago. If a given (squash) commit can be tied to a work item/ticket/whatever then the question is answered without devs having to remember the reason behind every logic decision they've ever made.

I favour rebase over merge where possible.

Weird how I can go 20 years in the industry without ever really using or understanding rebase. I'll look into it, thanks.

 

[GeorgeStorm]

I mean doesn't seem that unreasonable to me, keeping commits can be helpful but can also result in madness/things being more difficult to trace back etc (speaking as someone who is definitely not a git power user).
Most of it depends on how your work items flow is, and general attitude to comments etc as to me you're ultimately each arguing for details to leaning more on one side vs the other.

 

[iamgigglz]

I'm beginning to realise that the right answer is that there is no right answer. As always, dev work is as much art as it is science

 

[Dr Jack]

My objection to this is I don't remember the rhyme or reason behind every line of code I changed a year or more ago. If a given (squash) commit can be tied to a work item/ticket/whatever then the question is answered without devs having to remember the reason behind every logic decision they've ever made.

People are always going to forget stuff, yeah, and with the wrong team people can use blame in knobish ways but it is weird sometimes what you remember. I don't see limited use of squash as incompatible with linking commits with an item/ticket/whatever.

Weird how I can go 20 years in the industry without ever really using or understanding rebase. I'll look into it, thanks.

Basically it pretends your merge happened at the end of the current tree rather than branching off when it did which lets you have a linear history rather than one that branches in complicated fashion and has all sorts of merge commits in it. In most cases git will just do it without bothering you with the details. If you do need to deal with a number of merge conflicts then I think a merge is better.

 

[mid_gen]

I think it really depends on your habits. If you’re encouraging people to make daily WIP commits against larger ticket items, then squash is valuable in keeping history uncluttered.

If you aim to keep commits to atomic units of work with a ticket for each, then no, you’d be losing valuable information if you squash.

End of the day there is no right single answer, otherwise we’d all have been out of a job a long time ago

 

[platypus]

Sqaush merge is pretty much industry standard. You get a lot of noise on wip branch work otherwise.

Since you specifically mentioned your bosses concern about git blame, detailed history isnt lost, its just not retrievable on the cli. You still have it on the PR which is a better place for it, and I'd argue the appropriate place for it: its attached to things like review comments and the discussion. Obviously you need PR permanence for that, but again I'd argue thats "proper".