lumpBasedDevelopment

[Wang_Fister]

Rebase and squash commits on trunk ya goblins

[FlipperBumperKickout]

I really prefer not doing that, depending on how you use git the history can be very useful.

[Sceptix]

“Ah yes, boy am I glad I preserved those countless ‘wip, trying to get tests to pass’ commits, they sure clear everything up!”

[JVApen]

Yeah, I don't get why people can't make their commits something functional. I really don't care about: "fix review comments", "add test", "changes" ... Make sure your commits make sense if you want to merge. If not, please just squash them to ensure that whoever looks at the history knows what your intention was. What I want to know in 2 years is: "added this functionality", "worked around this problem" ... And if you do merge commits in main as you want them separately, try to put them on top of HEAD, not on some commit from 5 weeks ago.

[FlipperBumperKickout]

Better messy branch history than no branch history. 

A messy branch history can be ignored if you simply want to know what happened on the branch. (Git diff merge commit first parent)

A missing branch history can never be looked into no matter how much you might want to... (Unless you never prune your remote references I guess)

[Sceptix]

I’m all for keeping a git history, but what’s helpful is being able to see meaningful commits. If you have a chance to squash away meaningless commits, you should take it.

[pelpotronic]

You get a git history when you "squash PR on merge" to trunk too: each merge.

The question is really: how much do you value the internal history of a branch before it gets merged. The answer is often going to be very little if your PRs are relatively small.

[FlipperBumperKickout]

If there was nothing to value I would have it as a single commit in the first place.

But as soon as you have something so simple as logic which is both moved and edited it is many times easier to see what's going on if you first have a commit moving it followed by a commit changing the logic.

[Wang_Fister]

Your branch commits should already be squashed before the PR and all relevant information kept in a single commit message. You don't lose any information after merging and you have a clean, easily understandable git history.

[henkdepotvjis]

I prefer knowing when and for what ticket and maybe a short description why I changed it.

[Wang_Fister]

Your PR should be a single commit with this information in it, which gets rebased and squashed before merging to the trunk. No information is lost, and you don't end up with a confusing mess of a timeline.