half/byteOct 16

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.

Show threadhalf/byteOct 16

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.

Show threadPaweł ŚwiątkowskiOct 16
@halfbyte as someone who really dislikes squash merges (and also had to work with them for past 3 years), the first question I'd like to ask is: why to you want as few commits as possible in your main branch? What's the value of this?
Show threadhalf/byteOct 16

@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.

Show threadPaweł Świątkowski

@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.

Oct 16 at 9:03amWeb
Show threadPaweł ŚwiątkowskiOct 16
@halfbyte and for me personally squashing and 1:1 relationship between commit ant ticked discourages making ad-hoc generic improvements to the codebase, because they either get filed under a misleading commit title, or you need to create an artificial ticket or separate pull request for them.
Show threadhalf/byteOct 16

@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. :)

Show threadhalf/byteOct 16

@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.

Show threadPaweł ŚwiątkowskiOct 16

@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.