3 ms·
What about squashing commits in a merge? I don't do that all the time, but it is useful for certain things. Like repeated code changes to test something in the
by dec0dedab0de 4y ago
What about squashing commits in a merge? I don't do that all the time, but it is useful for certain things. Like repeated code changes to test something in the CI/CD pipeline (that I can't replicate well locally), where only the last change that got it working is of any interest.
You can get the same effect by reverting-to/checking-out a merge commit, or doing diffs between merge commits. You can also get a fairly clean history by only showing merge commits.
My rule of thumb is that any commit that has been pushed to a shared remote should never be re-written[]. If you're going to rebase, do it on your computer before pushing, or on your own repo before opening a merge/pull request.
[] exceptions would be removing accidentally committed secrets or large files that are no longer needed.