Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/13rac1/block-fixup-merge-action

Github Action to block merge of Pull Requests containing fixup! or squash! commits
https://github.com/13rac1/block-fixup-merge-action

fixup git-history github-action github-actions

Last synced: 3 months ago
JSON representation

Github Action to block merge of Pull Requests containing fixup! or squash! commits

Awesome Lists containing this project

README 

        
# Block Fixup Commit Merge Action



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.



## Background



* [The Git fixup workflow](https://dev.to/koffeinfrei/the-git-fixup-workflow-386d)

* [Git commit fixup and autosquash](https://blog.sebastian-daschner.com/entries/git-commit-fixup-autosquash)

* [GIT tip : Keep your branch clean with fixup and autosquash](https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)

* [You should use rebase/fixup in IntelliJ IDEA more often](https://augustl.com/blog/2019/using_rebase_fixup_in_intellij_idea/) - Applicable to any use of git.

* [Fixup your Code Reviews with git rebase --autosquash](https://rietta.com/blog/git-rebase-autosquash-code-reviews/)



## Setup



Create a file in your project named: `.github/workflows/git.yml` Add the

following:



```yaml

name: Git Checks



on: [pull_request]



jobs:

  block-fixup:

    runs-on: ubuntu-18.04



    steps:

    - uses: actions/[email protected]

    - name: Block Fixup Commit Merge

      uses: 13rac1/[email protected]

```



Optionally, setup Branch Protection to block merging of PRs against the `master`

branch with `fixup!` commits.



[Example PR blocked by a `fixup!` commit:][example-pr]



[example-pr]:https://github.com/13rac1/block-fixup-merge-action/pull/1



[![PR merge blocked](images/block-fixup-example.png?raw=true)](images/block-fixup-example.png?raw=true)



## Why



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:



1. Make a feature branch.

2. Add commits implementing features and fixing bugs. Rebase and force push all

   you want for now. This is _your_ branch.

3. Create a Pull Request and add Reviewer(s.) Rebasing commits is not allowed

   for now. This is not _just your_ branch.

4. Reviewer(s) request changes.

5. Create commits using `git commit --fixup=` to prepare changes to

   existing commits. Make new commits only when the change is outside the scope

   of existing changes.

6. Reviewers see new commits and approve the PR.

7. This is _your_ branch again. Clean up the history to make an ideal set of

   commits `git rebase -i --autosquash`, and merge.



Note: Rebasing is still allowed for the entire branch to integrate `master`

branch changes as needed.



## FAQ



### When using as a required check of a Pull Request, how can it ever succeed once it fails?



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:



```bash

git rebase -i --autosquash

git push origin HEAD -f

```



Then all checks re-run, and you can merge the Pull Request.



## License



MIT