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’m generally happy (within reason!) to amend / tidy up commits before considering them done, etc, but there are definitely things people do with git that make me wonder why they insist on making life difficult for themselves.
(Monorepos for example. If you’ve combined everything into one repo to the point that it’s unmanageably large with git alone and you have to start building custom tools to handle it, that feels self-inflicted.)
half/byte
ben