I'm currently having a discussion about "how to git" with a team I'm working with.
What I'm realizing is that a) I've always been super pragmatic (which is an euphemism for "super sloppy") with this and b) different people value very different things in a git history.
To me, for example, the local history of a pull request is super important and I very rarely amend a commit.
Some people in that company work very differently and basically work in one commit they frequently rebase.
On the main branch, otoh, I want as few commits as possible, but ideally with very useful commit messages.
So, I squash on merge.
Some people, after finishing their work in that singular, massage the git history into atomic commits they will then merge.
I think I understand the value of atomic commits, but to me this feels backwards.
I'm willing to learn, though so I'm enjoying our discussions.
I also think that this is super context sensitive. Larger teams need to think more carefully about their git history and it's been a while I've been on larger teams.
The snark part of me wonders, though, if people who claim that "git is too complicated" are simply using git in a completely different way than me that causes their problems in the first place. Complex massaging of git histories very rarely comes up in my workflows.
@halfbyte I think we’ve also all got our personal scar tissues from things that have burnt us in the past.
Many years ago a colleague took a branch he’d been working on for something like 6 months, with hundreds of commits (many of them quite fiddly - it was work to get a codebase to run against redshift as well as postgres) and just squashed merged it.
I was super anti squash merge for many years as a result
@pointlessone @halfbyte intentional focus on PRs being small enough ( https://ruby.social/@fglc2/115383442942052868 )
I went with the flow when I joined the company and in 4 and a bit years I don’t feel like I’ve ever regretted it
@halfbyte but the last few years I’ve been in a world where prs are intentionally very small (less than 200 lines diff usually, often a lot less) and there I’m happy with a squash merge. I do occasionally make a change, usually a small, subtle one where I wish it would make it as its own commit into the final history so that when I inevitably git blame that line in a years time I get to the explanation for it.
half/byte
fglc2
PointlessOne 