4 ms·

>Some people get it in their heads that their commit history needs to be "clean". It doesn't... I do not care about git commit history at all. Do not squash. D

>Some people get it in their heads that their commit history needs to be "clean". It doesn't... I do not care about git commit history at all. Do not squash. Don't do anything other than commit, push, and merge PRs. I don't delete old branches, I don't do anything beyond the basics. I don't even use rebase. It has never bit me in the ass at all in all the years I've been running this team. The less I have to do with git, the better.

kgeist 2y ago
At our organization, no one squashes or rebases either. We never delete branches. It's been like this for around 15 years. Not a single problem.
- leptons 2y ago
  I guess it depends on the developers and how they choose to commit. On my team we don't commit unless we're ready to push, so we aren't creating 100s of commits for every feature or bug fix. Some developers seem to think they need to commit every 2 seconds for every tiny little change. That's just seems like a waste of time to me, and it also creates the need to squash and do more stuff with git. Anything that distracts me from writing software and putting work into the code is a distraction, and git is a distraction. I don't really want to deal with git as often or as much as some developers seem to use it constantly to commit everything... git commit -m "added a blank line"
  - kgeist 2y ago
    Dunno for me it's great to commit if I just made substantial work but it's not ready yet. It's assuring that my work won't be accidentally lost if I mess up. Especially it's great to commit at the end of the day or if I just wrote tests which all pass. Stuff works, I can move on, and forget about it. Next day when I write more code, and something breaks (but worked yesterday) I can easily see the diff between yesterday and today and see what changed and where I'm currently at. Commit messages remind me of what I did, step by step. Then I push to the dev environment and if QA finds bugs, I commit new changes which fix the bugs. It's also great for the reviewer - they only have to look at the single bugfix commit, the rest of the code is fine (already reviewed). I don't find a use for squashing, modern tools allow to see several commits as one diff.
dgfitz 2y ago
When I learned about git commit squashing I was sincerely disturbed.
- hathawsh 2y ago
  Exactly. We have a beautiful tool that can maintain an unbroken historical record without being a burden... and then we use it to rewrite history? Nooooo!!
marcosdumay 2y ago
I can't say I have never had a problem. I have surely seen a handful of cases where squashing and rebasing to keep history clean would make my work way easier. But the squashing and rebasing would waste way more time than those would gain. I guess if you are managing a popular public repository, at some point the trade-off inverts.

kgeist 2y ago

At our organization, no one squashes or rebases either. We never delete branches. It's been like this for around 15 years. Not a single problem.

leptons 2y ago
I guess it depends on the developers and how they choose to commit. On my team we don't commit unless we're ready to push, so we aren't creating 100s of commits for every feature or bug fix. Some developers seem to think they need to commit every 2 seconds for every tiny little change. That's just seems like a waste of time to me, and it also creates the need to squash and do more stuff with git. Anything that distracts me from writing software and putting work into the code is a distraction, and git is a distraction. I don't really want to deal with git as often or as much as some developers seem to use it constantly to commit everything... git commit -m "added a blank line"
- kgeist 2y ago
  Dunno for me it's great to commit if I just made substantial work but it's not ready yet. It's assuring that my work won't be accidentally lost if I mess up. Especially it's great to commit at the end of the day or if I just wrote tests which all pass. Stuff works, I can move on, and forget about it. Next day when I write more code, and something breaks (but worked yesterday) I can easily see the diff between yesterday and today and see what changed and where I'm currently at. Commit messages remind me of what I did, step by step. Then I push to the dev environment and if QA finds bugs, I commit new changes which fix the bugs. It's also great for the reviewer - they only have to look at the single bugfix commit, the rest of the code is fine (already reviewed). I don't find a use for squashing, modern tools allow to see several commits as one diff.

dgfitz 2y ago

When I learned about git commit squashing I was sincerely disturbed.

hathawsh 2y ago
Exactly. We have a beautiful tool that can maintain an unbroken historical record without being a burden... and then we use it to rewrite history? Nooooo!!

marcosdumay 2y ago

I can't say I have never had a problem. I have surely seen a handful of cases where squashing and rebasing to keep history clean would make my work way easier. But the squashing and rebasing would waste way more time than those would gain. I guess if you are managing a popular public repository, at some point the trade-off inverts.