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