🛠️ Real World — Git Workflows & Code Review

Real World — Git Workflows & Code Review: Picture two QA engineers, Ada and Sam, both editing API tests for the same "orders" service in the same week.

Picture two QA engineers, Ada and Sam, both editing API tests for the same "orders" service in the same week. With Bruno, their changes are just two Git branches — if they touch the same file, Git shows a normal merge conflict they resolve like any code conflict. With a cloud-synced tool, whoever saves last can silently overwrite the other's edits unless the team has a separate, manual coordination process. So why does that matter, if the team is small enough that Ada and Sam simply tell each other what they changed? Because the guarantee you actually need isn't "we remembered to talk" — it's "the tool refuses to lose work even when we forget". Verbal coordination scales to two people on a good week; it does not survive a third engineer, a vacation, or a hotfix at 6pm. Git's merge conflict is annoying precisely because it is loud, and loud is the correct behaviour when two people edited the same assertion. There is a second thing plain-text files buy you that a cloud workspace cannot: review. An API test change becomes a pull request diff a colleague can read line by line — the same code review muscle your team already uses for Java or Python, now applied to the tests guarding your endpoints. "Why did this assertion get deleted?" becomes an answerable question with a name and a date attached, instead of a mystery nobody can reconstruct.

API Tests Living Next to the Code

In a typical setup, a backend repo has a tests/api/ folder containing a Bruno collection right alongside the source code it tests. When a backend developer renames a field or changes a status code, the .bru files for the affected endpoint sit in the same pull request — a reviewer sees the API change AND the test change together, instead of trusting that "someone updated Postman somewhere."

A Real Pull Request — Catching a Breaking Change Before Merge

Code Review for API Changes

This is the practical payoff of everything in the Core Concepts tab: because a .bru file is plain text, GitHub/GitLab renders a proper diff — red line removed, green line added — exactly like a code change. A reviewer who has never opened the Bruno app can still read "this test now expects user_name instead of userName" and immediately understand the blast radius of the change, asking "did the mobile app get updated for this rename too?" before it ever reaches production.

🎬 From git push to bru run: How CI Runs a Collection

GitHub Actions Runner

bru run --env staging

The developer pushes a commit containing both the backend code and the related .bru collection. Both live in the same pull request.

Step 1 — GitHub Actions catches the pull_request event and spins up a clean ubuntu-latest runner. This runner has NO prior state.

Step 2 — the checkout step also pulls in the .bru files (they're just code too), then `npm install -g @usebruno/cli` installs the CLI.

Step 3 — `bru run --env staging --reporter-junit results.xml` runs the whole collection from the terminal — no GUI needed at all.

Step 4 — if every assertion passes, exit code 0 returns, the deploy gate opens, and the PR becomes mergeable.