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.
@halfbyte I was having this exact discussion on Reddit this week. I value proper git history as a way of communicating with other contributors and future me. I wish squash on merge was banned! 😆
I always work in a branch, with one or more commits grouping related changes in a logical order and frequently amending them as necessary to keep it clean. After PR approval, it's a standard merge commit which preserves the history of how that code came to be. So I get a nice graph showing related smaller commits.
@Odaeus @halfbyte Team atomic commit here, except I usually massage my local messy history at the end of the dev process.
I'd rather have one auto-squash commit than a string of wip/typo commits, although I personally squash them manually before handing it off for review. With side tasks (eg cleanup) or major dev steps, I want them and their explanation in separate commits.
This not only helps with future research but makes code reviews much easier when you can handle cohesive bits one by one.
half/byte
Andrew France
Thomas Jachmann