Should unit tests run on every git branch?

Yes, run unit tests on every branch that opens a pull request, because the suite exists and the trigger takes minutes to add. A spike branch you will delete can go without a run.

Should the develop branch be unit tested in CI?

Yes, in a Git Flow repository run the unit tests on develop after each merge as well as on feature branches. Two features that pass alone can fail together on develop and stay unseen until the release branch.

Should tests run on pull requests or on push?

Run tests on the pull_request event for branches and on push for main. On GitHub a pull request run tests the branch merged into its base, while a push run tests the branch alone.

Can I skip tests on documentation-only branches?

Yes, skip the test job on Markdown-only changes with a job condition, not a workflow path filter. GitHub keeps a required check from a path-filtered workflow pending, which blocks the merge, while a job skipped by a condition reports success.

Should tests run on every branch?

Verdict

Yes

Yes, run the unit and integration tests on every branch that opens a pull request, make that run a required check before merge, and run the tests again on main after each merge.

Why

Blast radiusinternal
Change frequencyconstantly
Detectabilitysame-day
Reversibilitywith-effort
Test costtrivial

Yes, run the tests on every branch that opens a pull request; rule R11 gives Test. The typical case is a team that merges feature branches into main, where CI runs the suite before each deploy. Blast radius is internal, because a change that breaks the suite turns main red for the team and holds the deploy, while main's own run keeps the bug from customers. Change frequency is constantly, because the team merges most days. Detectability is same-day: without branch runs the failure first shows on main after the merge, when teammates have already pulled it. Reversibility is with-effort, because a reverted merge needs a second revert before the fixed branch can merge again. Test cost is trivial: the suite exists, and a trigger in the CI file takes minutes to add.

When the decision changes
When	Decision	Why
Every merge deploys to customers with no test run on main, and the branch changes how the service charges cards	Test mandatory: the branch run is a required check that covers every charge path, and a second person reviews the tests	Blast radius rises to money and Reversibility to costly, because a wrong charge reaches customers and needs refunds
A spike branch that you will delete without merging, and that nobody else checks out	Do not run tests on a spike branch; trigger CI on pull requests, so a branch without one uses no runner time	Blast radius falls to none, because nothing from the branch reaches main or another developer
The branch changes only Markdown files, which the reviewer reads rendered in the pull request	Do not run the test suite on a Markdown-only branch; skip the test job with a job condition	Detectability moves to immediately and Reversibility falls to trivial, because a wrong sentence shows in the preview and a revert leaves nothing behind
The end-to-end suite takes 90 minutes on the only shared staging server	Do not run the end-to-end suite on every branch; run it on main after each merge, and keep the unit and integration suites on branches	Test cost rises to heavy, because branches queue for the one server, while main's run still shows the failure the same day
Feature branches merge into develop, and develop reaches main only when a release branch is cut	Test: run the suite on develop after each merge as well as on every feature branch	Detectability moves to eventually, because two features that pass alone can fail together on develop; the decision holds, since the run still costs one trigger line

What breaks if you don't test

A branch that renames a configuration key passes review, because nobody ran the suite on it. Main's run fails twenty minutes after the merge. By then two more branches have merged on top, three developers have branched from a red commit, and the deploy of an unrelated fix waits while someone finds which merge broke the build.

What you lose if you over-test

A 12-minute suite on a pull request with eight pushes uses 96 runner minutes, and triggering both push and pull_request on all branches doubles that. A flaky test in a required check blocks every branch at once, and developers learn to press rerun without reading the failure.

How to test

On GitHub Actions, trigger the workflow on pull_request and on push to main. A pull_request run tests the branch merged into its base, so it also catches conflicts with main.
Make the test job a required status check on main.
On GitLab, enable merged results pipelines; a plain merge request pipeline tests the source branch alone.
Run the end-to-end suite on main after each merge.

Procedure and references

When the answer changes

Nobody but you pulls or deploys the repository.
A merge deploys to customers with no run on main, and the code handles money.
The suite takes longer than the reviews it waits for.

Real incident + Code example

The revert that dropped half a feature

On a team I worked on, CI ran only on develop. A branch that renamed a configuration key merged, develop failed after two more merges landed on top, and we reverted the merge commit. A week later the author merged the fixed branch again, and only the fix arrived: in the words of the git-revert documentation, a reverted merge "declares that you will never want the tree changes brought in by the merge". The release shipped without the rename, and QA found it three days later. Now every branch runs this workflow before merge:

name: tests
on:
  pull_request:                # every branch with a pull request
  push:
    branches: [main, develop]  # and the merge result on main and develop
concurrency:
  group: tests-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Sources

FAQ

Should unit tests run on every git branch?: Yes, run unit tests on every branch that opens a pull request, because the suite exists and the trigger takes minutes to add. A spike branch you will delete can go without a run.
Should the develop branch be unit tested in CI?: Yes, in a Git Flow repository run the unit tests on develop after each merge as well as on feature branches. Two features that pass alone can fail together on develop and stay unseen until the release branch.
Should tests run on pull requests or on push?: Run tests on the pull_request event for branches and on push for main. On GitHub a pull request run tests the branch merged into its base, while a push run tests the branch alone.
Can I skip tests on documentation-only branches?: Yes, skip the test job on Markdown-only changes with a job condition, not a workflow path filter. GitHub keeps a required check from a path-filtered workflow pending, which blocks the merge, while a job skipped by a condition reports success.