You must log in or register to comment.
YOLO! I like my commit history to tell a story of hope, defeat, pain, ennui, and triumph. A story filled with cursing and humor. The code is WHAT was done. Comments in the code are WHY something was done. Commit logs are for entertainment purposes, and for batching changes together in bite sized chunks to make PR reviews easier.
That’s how I do it anyway…
Clean git histories are fun for the people who care, but they are also mostly useless.
I’ve been around a lot of arguments about the commit standards in teams and it’s always boiled down to the “I don’t care, but I don’t want to spend time doing anything special” people vs the “do the things the way I like because I can think of three reasons it’s technically superior but not practically useful to do so” people.
Bikeshedding at its finest
A great gain from a systematic approach of creating clean history is a better understanding and higher discoverability of issues.
Looking into change history is rare. But designing your changes, being deliberate, structured allows for easier and safer reviews and merges. And spotting issues early is always cheaper and better.
It also helps tremendously in determining what changed between versions. And when necessary finding and reverting regressions.
Cleaning up your history before making a PR can make it easier to review so I always try to do that, but it’s not something that should be over done because it can quickly eat up more time than its worth if you go overboard
Doesn’t squashing on merge achieve exactly the same thing? (As long as pull requests are kept small, of course.)
To a degree, if pull requests are small enough, then yes.
Often, a changeset includes different aspects and concerns though, and individual commit messages allow you to document and reason them. Squashing makes you lose the concern separation.
When reviewing, even relatively simple changes separated into their concerns helps me a lot.
It’s a matter of preference and necessity, and the changeset and it’s environment at hand.
Not squashing before review, squashing on merge (i.e. after review). Squashed merges make these easy, regardless of whether the original commits in the pull request were messy:
- determining what changed between versions
- finding and reverting regressions
Yes, this is the
do the things the way I like because I can think of three reasons it’s technically superior but not practically useful to do so" people.
Camp I was talking about. You’ve your reasons, you’ll bikeshed about it for months and no one gets anywhere and no one is happy aside from the people that enjoy the arguments
I’ve never really needed to use rebase, but my workflow is probably kinda weird:
- I just start programming from the dev branch
- At some point once I have stuff to commit, I do
git checkout -b new_feature_branch, and so move my changes to a different branch - I commit a bunch of stuff into that branch, usually just with commit messages of “working on new_feature”
- Once I’m done, and I have - lets say - 10 commits in that branch:
- I do
git reset head~10meaning all 10 commits are reverted into staged changes - I now do 1 new commit of all the changes, with a decent commit message to explain the new feature
- I
git push -fthe new commit back to origin (of feature branch) - I PR the feature branch to dev, and merge it
It works pretty well for me, but I was told its weird, and I should rebase instead
The benefit with rebase is if you want to have maybe 4 commits insteadd of 10. When reviewing a large pr, I find that it’s helpfull if it’s broken up into a couple of coherent commits so that I can review it commit by commit. It’s easier to follow the logic of why something is being changed if it’s associated with a specific commit.
Sometimes squashing the entire commit is the right choice, in which case you can do what you’re doing or use some built in feature to do that.
You do you. People generally discourage rebase because it rewrites history but that’s what you’re doing anyway. You can achieve the same result with revase --interactive and following the instructions to squash all your in progress commits into a single commit. That way you don’t have to figure out how many commits between your in progress and dev(for your reset command) as the rebase will handle it for you.
