I have some pretty good reasons to squash my commits when working with a team:
Evoid rebase nightmare where i will need to fix the same conflicts for each commits.
Evoid revert nightmare when reverting a faulty merges
Remove easilly uneeded git History (essentially bug hunting commits, trial and errror commits). And don't tell anyone to not commit unfinished work. Git was created to allow and encourage it.
Your developpement process has nothing (brunch of test red, impl test green, refactor) to do with your product History. What matters is the feature History. And that's what i want to see in the product git History.
There's a couple of tricks to have an easier time rebasing:
You can avoid "rebase nightmare" by using git rerere. It records how you resolve conflicts and allows you to replay it.
For "reverting", you just need to checkout the tree to the state that you want to revert to, and make an appropriate commit message.
I always think "tree state" first, more so than caring about individual commits. I can always link up the graph by manually putting in a parent link when merging, if I do want to show what happened in the history.
Realizing that git only cares about file contents, not diffs or commit or patches, really freed up how I can navigate "complicated" issues.
For the last two points you raise, my approach is to use --first-parent or similar flags to just look at the part of the history i care about (usually, one commit per ticket on the main branch) and link it up to product features (the ticket themselves). No need to squash.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have some pretty good reasons to squash my commits when working with a team:
There's a couple of tricks to have an easier time rebasing:
I always think "tree state" first, more so than caring about individual commits. I can always link up the graph by manually putting in a parent link when merging, if I do want to show what happened in the history.
Realizing that git only cares about file contents, not diffs or commit or patches, really freed up how I can navigate "complicated" issues.
For the last two points you raise, my approach is to use
--first-parentor similar flags to just look at the part of the history i care about (usually, one commit per ticket on the main branch) and link it up to product features (the ticket themselves). No need to squash.