Love using git commit --fixup
or git commit --squash
to make cleanups to
your Git history, but forget to git rebase -i --autosquash master
before
merging?
Have I got a Github Action for you!
This Action is as an assistant to be sure you squash fixup commits before merging to your main branch.
Create a file in your project named: .github/workflows/git.yml
Add the
following:
name: Git Checks
on: [pull_request]
jobs:
block-fixup:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v2.0.0
- name: Block Fixup Commit Merge
uses: 13rac1/block-fixup-merge-action@v2.0.0
Optionally, setup Branch Protection to block merging of PRs against the master
branch with fixup!
commits.
Example PR blocked by a fixup!
commit:
Change Requests are part of a Pull Request code review. There are multiple methods to make the updates, some are better than others. The regular method is to add additional fix/update commits, including commit message titles such as "Code Review changes." There's a better way.
Git commits are the historical record of project. The commit messages tell a story, each commit or Pull Request describing a change. FutureYou™ and CurrentCoWorkers™ needs to know the end result of each change, but no one cares about edits required to make that change. We just want to read the book, no one cares what the editor told the author while writing the book.
One solution is to use Github's "Squash merge" feature. This works well for small PRs. A few small commits can be squashed into a single commit. The "edits" removed.
The problem occcurs when you have multiple unique commits a PR: a dependency
update, followed by a refactor, then a bug fix. It is all one contained change,
but FutureYou™ may just want to see that bug fix. Keep it separate. A solution
is using git rebase
to edit commits during the code review; this becomes
confusing for reviewers, commits can suddenly disappear. "Fixup Commits" are
better.
Fixup Commits can added to the end of the git history during a code review, then squashed into their respective commits after the PR is approved. The workflow is:
git commit --fixup=<SHA>
to prepare changes to
existing commits. Make new commits only when the change is outside the scope
of existing changes.git rebase -i --autosquash
, and merge.Note: Rebasing is still allowed for the entire branch to integrate master
branch changes as needed.
A final squash and force push is required to clear the check failure before merge.
The historical unsuccessful check does not block the merge. Only the most recent Action run matters. Once the code review has been completed, the Pull Request approved, and all other Actions/Checks (Travis/Circle/Jenkins) pass, the final step is cleaning the history by applying the fixup commits:
git rebase -i --autosquash
git push origin HEAD -f
Then all checks re-run, and you can merge the Pull Request.
MIT