Reality is everyone prefers to organize code differently I prefer to have all the commit history. It is more meaningful to see all the files involved in a single stage of a commit than potentially multiple changes in one PR all blended together.
Reality is everyone prefers to organize code differently I prefer to have all the commit history. It is more meaningful to see all the files involved in a single stage of a commit than potentially multiple changes in one PR all blended together.
Except that the history is disorganized and is not organized into distinct patches that only do one thing where each patch has a well written commit message.
People seem to want to treat the VCS as a back up system rather than a system to keep track of changes. Technically you could get the former by configuring your editor/IDE to generate a commit every time you save the file, but that in itself would lead to a very large history that wouldn't be useful (meaning commands like git blame would be next to useless).
This seems like a separate problem... I know where commits come from cause the first thing I write on mine is the JIRA / Trac or other related ticket number / code. It is pretty obvious where a commit originated from if you do this. The rest is useful meaningful information. If somebody writes useless commit messages, that's on them and the rest of the team for letting them do so.
I stopped rebasing.
I think it's completely reasonable to ask all developers to get a second opinion before force pushing.
I tell people to run git log -p --reverse origin/master.. on the rebased branch and check that everything works before they push up their branch to the remote. I also tell them to run git rebase --exec "linting-command" --exec "unit-test-command" --exec "integration-test-command" and make sure that tests pass for every single commit. If they don't, then they spend time fixing it until they do.
Some of those commits may have changed (either the commit message or the diff itself). There's a git command called range-diff[1] that was added recently that allows you to diff between rebases.
> Also, they tend to involve more manual processing, and thus human error, then merges.
Before actually pushing up the rebased branch, you run a diff against the upstream tracking branch to see if any inadvertent changes were introduced. For example:
git diff @{u}..
And use the range-diff command to see the difference between the upstream tracking branch and your locally rebased branch.