9 Practical Git Pull Request Patterns to Streamline Your Workflow

My daily work and open‑source contributions often involve Git and GitHub, so I collected several useful pull‑request (PR) patterns.

1. Isolated PR

When to use

Working on a feature branch.

Spotting unrelated bad code (e.g., a small bug, inconsistency, or style violation) that needs immediate fixing.

What to do

Pause current work (commit or stash).

Checkout master branch.

Create a new branch.

Fix the code and commit.

Switch back to the feature branch and continue work.

After the feature branch merges to master, rebase the new branch onto the updated master.

This satisfies the need for a quick fix while keeping the feature branch clean, making review easier.

2. Optimistic Branch

When to use

A branch (branch A) cannot be merged yet (e.g., CI failures, reviewer busy).

You need to base another change on the code of branch A.

What to do

Create a new branch B from branch A.

After branch A merges to master, rebase branch B onto master and resolve any conflicts.

This strategy works well in most cases, though large changes on A may cause conflicts.

3. Clever PR

When to use

The modification does not really need review.

You still want teammates to be aware of the change.

What to do

Make the change on a branch.

Open a PR.

Immediately merge the PR yourself.

GitHub notifies teammates via email, allowing them to comment if needed.

4. Stealth Commit

When to use

The previous PR has been reviewed and merged to master.

You need a tiny change (e.g., copy‑paste tweak or bug fix) without notifying others.

What to do

Push the new commit directly to master.

5. The Roger Roger Comment

When to use

You received actionable feedback on a PR.

You have made the corresponding changes.

What to do

Leave a comment that includes a reference to the updated PR.

GitHub automatically increments the reference count on the diff link, so teammates get an email notification, can click the diff, and continue the review.

6. Slow‑Crawl Commit

When to use

You introduced a small formatting bug (extra spaces, missing newline, etc.).

A logical change actually belongs to a previous commit.

The code cannot be submitted (tests failing) but you need to revert to a stable state for testing.

What to do

For the first two cases, amend the previous commit.

For the third case, create a “crawling” commit and iteratively fix it (or revert) until the code can be properly committed.

7. Force‑Modify Branch

When to use

You need to fix a remote feature branch (e.g., a terrible commit message).

What to do

Amend the commit locally.

Force‑push the feature branch to the remote repository.

Force‑pushing is generally discouraged, but it works fine for non‑master branches; GitHub preserves PR comments.

8. Reformat‑and‑Isolate

When to use

You want to reformat code while also making functional changes.

What to do

Create a commit on master that contains only the reformatting.

Rebase your feature branch onto the updated master.

This keeps the diff presented to reviewers clear, as formatting changes are isolated.

9. Prototype PR

When to use

You want feedback on an idea before writing a full implementation.

What to do

Create a branch and do some exploratory work.

Open a PR whose purpose is discussion, not final code.

When consensus is reached, close the PR and delete the branch.

Start a new branch and PR for the actual implementation.

I used to think a PR should be opened only when code is finished. Now I realize a PR is a great way to start a discussion—GitHub’s inline comments, replies, notifications, and diff comparison foster code and design conversations and help prevent developers from drifting into dead‑ends.

English: Jake Benilov Translator: 伯乐在线-奇风余谷 URL: http://blog.jobbole.com/43288/