While we all have a different way of managing our GitHub workflow, we all have to deal with one annoying thing: conflict.

When a pull request modifies a file that has been modified in the meantime, GitHub shows you the famous Resolve conflicts button. This indicates the pull request cannot be merged until the conflict is resolved.

A conflict!

The main issue with the default GitHub workflow is that nothing notifies you that a pull request conflicts. This is a problem when you regularly contribute to projects and end up following a few pull requests. They might need your attention, but nobody notifies you.

The same applies to contributors sending pull requests to your project. They might need to resolve the conflict for their pull request, but they won't know until a maintainer asks them to do so.

The good news is that we can make things better.

Two Ways of Noticing Pull Requests

There are two significant ways we can make conflicting pull request standup and be acted on:

  • Make them stand up in the pull request lists.
  • Send a notification to the pull request author for immediate action.

Adding a Label & Posting a Comment

When displaying a list of pull requests, GitHub also displays the labels near its title. This is an excellent opportunity for us to state that a pull request might need some attention.

To notify the pull request author, posting a comment mentioning its name is simple enough.

Here's a set of Mergify rules that implements that:

pull_request_rules:
    - name: add label on conflict
      conditions:
         - conflict
         - -closed
      actions:
        label:
          add:
            - conflict
        comment:
          message: Could you please fix the conflicts @{{author}}? 🙏
    - name: remove label on conflict
      conditions:
         - -conflict
         - -closed
      actions:
        label:
          remove:
            - conflict

This is pretty straightforward: when an opened pull request conflicts, Mergify adds the label named conflict and posts a comment. The opposite happens when the conflict is not there anymore, and the label is removed.

This is perfect: the author is notified that it needs to take action.

If a maintainer browses the pull request list, they can see in a snap that the pull request is in conflict. They might decide to, e.g., not review the pull request until the author resolves the conflict.

Fixing Conflicts

When the conflict is fixed, Mergify will remove the label, making sure the pull request is now seen as clean.

Now more conflict!

We've implemented this workflow on our principal code repository for a while now, and it is a time saver!