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.
@katafrakt Just a clearer history with less noise, I guess. Again, depends a bit on the project, but I think a "commit per ticket" approach can make reading the history a lot easier.
On the flip side, which is a more indirect answer to your question, if you don't squash, you need to be much more deliberate with your local history (or massage the history before merging) and that seems wrong or at least annoying to me.
@halfbyte there are trade-offs, for sure. If people on the team do "wip, wip, fix, test, fix lint" commits, then perhaps squashing is a better solution.
But then you need some rigor as well. I used to work on a team that practiced long-living branches and when I was trying to browse file's git history to find how a given piece of code got there, I stumbled upon commits with 18k lines of changes (squashed from 200 commits). That's just useless and definitely a lot of noise in my books.
@katafrakt Hm, interesting. I guess that's where my pragmatism would kick in and say "Rules are there to be broken". If I want to make that refactoring, I'm making that refactoring.
I think what we're seeing here is that a lot of this is actually more about company culture and collaboration than about technical merits.
Who woulda thunk. :)
@katafrakt Oh, yeah for sure. I am guilty of long-living branches on some projects but more for a lack of time - I usually try to be very deliberate of quickly delivering small, isolated changes.
I guess I find the combo of pseudo trunk based development and then still having long lived branches because people context switch so much and reviews take ages probably the worst of both worlds.
If you have good examples of public histories that you personally like, I'd love to see them.
@halfbyte for my personal projects I recently use rebase merges. Here's an example PR that, when squashed, would land as "improve tests" single label, but I prefer each reason for change to live in a separate commit:
https://github.com/katafrakt/palaver/pull/47/commits
But this is just a small, single-person project. I don't think I have an example of a larger public project at hand.
half/byte
Paweł Świątkowski