Git and CI for Testers

Git in plain words

Git is a version control system: software that records every change to a set of files, who made it and why, and lets many people work on the same code without overwriting each other. Almost every software team uses it. The website you open it in (GitHub, GitLab, Bitbucket, Azure DevOps) adds pull requests, reviews and pipelines on top.

Repository

A repository (repo) is the project: all the code, plus its complete history. A company often has several: one for the iOS app, one for Android, one for the backend, one for the website. That matters to you: a bug in “the app” might be fixed in the backend repo, which is deployed separately.

Commit

A commit is one saved change. It has:

• a hash, a unique ID such as 7f3d0b1c…, usually shortened to 7 characters;
• an author and a date;
• a message, ideally with the ticket key: Use current menu prices when reordering (FD-327).

Commits are what builds are made of. “Which commit is this build from?” is the most precise way to ask “does this build have the fix?”.

Branch

A branch is a separate line of commits. A developer creates fix/FD-327-reorder-prices from main, commits there, and nobody else is affected until it’s merged. Many branches exist at once: one per feature or fix in progress.

Pull request and code review

A pull request (GitHub, Bitbucket, Azure DevOps) or merge request (GitLab) says: “please merge my branch into main”. The PR page shows:

• the diff: which lines changed, in which files;
• comments from code review, where at least one teammate reads the change and approves it or asks for changes;
• the checks: CI results for exactly this change (green ticks or red crosses).

Testers rarely review code, but reading a PR’s title, description and list of changed files tells you a lot about what to test. “Changed: PriceCalculator.kt, CartViewModel.kt” is a strong hint that cart totals deserve a regression check.

Merge

When the PR is approved and the checks pass, it’s merged: the branch’s commits become part of main. Sometimes two branches changed the same lines; that’s a merge conflict, and a developer resolves it by hand. Merges are a classic place for a fix to get lost or for an old bug to come back, which is one reason regression testing exists.

Branch patterns you’ll meet

Teams organize branches differently. Here are the names you’ll see most:

Branch	Typical use	What it means for you
main (or master)	The shared, up-to-date code. In many teams, always releasable.	Most staging builds come from here.
develop	In some teams, the integration branch for the next release, with main holding only released code.	Ask which branch your test builds come from.
feature/…, fix/…	One story or bug, short-lived.	PR builds come from these, if your team makes them.
release/…	A version being stabilized, e.g. release/2.1.0. Only fixes go in.	Release candidates are built from here.
hotfix/…	An urgent fix to what’s live, often made from the release.	Small, risky, fast. Test the fix and the critical flows.

Two broad styles exist. GitFlow-style teams use develop, release and hotfix branches. Trunk-based teams keep branches very short and merge to main many times a day, often hiding unfinished work behind feature flagsFeature flagA switch that turns a feature on or off without releasing a new build.Open in glossary →. Neither is “the right one”, and most teams use some mix. On your first week, ask: “Which branch do staging builds come from, and how do I get a build for a PR?”

Versions and build numbers

Two numbers identify an app build, and testers need both.

	Example	Who sees it	Changes when
Version	2.1.0	Users, in the store and the app	A release is planned
Build number	412	The team, in TestFlight, the About screen, CI	Every build, even of the same version

The version usually follows semantic versioningSemantic versioningA MAJOR.MINOR.PATCH version format where each number signals how big a change is.Open in glossary →, MAJOR.MINOR.PATCH: 2.1.0 → 2.1.1 is a fix, 2.1.0 → 2.2.0 adds features, 2.x → 3.0.0 is a big or breaking change. Teams use it loosely, but it tells you how wide your regression should be.

Many builds share one version: 2.1.0 might go through builds 405, 411, 412 and 415 before release. That’s why “I tested 2.1.0” is not enough, and “2.1.0 (412)” is.

iOSAndroidWeb

TestFlight lists builds as 2.1.0 (412): version, then build in brackets. Many apps also show both in their own Settings › About screen.

Android has a version shown to users and a whole-number build code that must increase with every upload to Google Play. You can see the version in Settings › Apps › [app], and builds in Firebase App Distribution or Play Console testing tracks.

Websites rarely show a version. Teams often put it in a page footer, an HTML comment, a /version or /health endpoint, or the console on load. Ask where it is, and note it in bug reports just like an app build. See DevTools for Testers.

Dev note: Where the two numbers live

On iOS the version is CFBundleShortVersionString (“Version” in Xcode) and the build is CFBundleVersion (“Build”). On Android they’re versionName and versionCode. You’ll see these names in tickets and CI logs.

TestFlight and Firebase App Distribution shows how mobile builds reach your phone and how to check which one you have.

Environments, and how a change travels

An environmentEnvironmentA setup of servers, data and configuration where the software runs, such as dev, staging or production.Open in glossary → is a complete copy of the system (app, servers, database) for a purpose:

Environment	Used for	Data
Dev (or a PR preview)	Developers trying changes; sometimes PR builds for testers	Test data, often unstable
StagingStagingA pre-release environment that mirrors production as closely as possible.Open in glossary → (or QA, test, UAT)	Testing a build that’s close to release	Realistic test data, sandbox payments
ProductionProductionThe live environment that real users use.Open in glossary →	Real users	Real data, real money

Names vary: some teams have a separate QA environment before staging, some have per-PR preview environments, some call staging “pre-prod”. The idea is the same: the closer to production, the more stable and realistic.

Here’s the journey of one fix:

CI and CD

Continuous integration (CI) means every change is merged often and automatically built and checked. The checks run on a CI server (GitHub Actions, GitLab CI, Jenkins, Bitrise, CircleCI and many others) within minutes of a push.

CD means one of two things, and people mix them up:

• Continuous delivery: every change that passes the pipeline is ready to release; a person decides when.
• Continuous deployment: every change that passes is released to production automatically, with no human step.

Mobile apps rarely do continuous deployment in the strict sense: every release goes through store review, and users update in their own time. Websites and backends can do either.

The pipeline

A pipeline is the sequence of automated stages a change goes through. Each stage must pass before the next starts. A typical one:

Stage	What happens	If it’s red
Build	The code is compiled into an app or site.	Nothing to test yet.
Unit tests	Thousands of small, fast code-level tests (unit testingUnit testingTesting the smallest pieces of code, like a single function, usually by developers.Open in glossary →).	A developer’s logic broke something.
Lint / static analysis	Tools check code style and common mistakes without running it.	Usually a quick code fix.
Deploy to a test environment	The build goes to dev or staging.	The environment or deployment failed, not the feature.
Automated API and UI tests	Scripts check key flows end to end (see the test pyramidTest pyramidA model recommending many fast unit tests, fewer integration tests and few end-to-end tests.Open in glossary →).	A real bug, a changed screen the test didn’t expect, or a flaky test.
Manual testing	You: new features, risky areas, real devices, exploration.	You report what you find.
Release	A build is promoted to production or submitted to the stores.	Check the release notes and the RC.

Not every team has every stage, and manual testing isn’t always drawn in the pipeline tool. But this is the order in which a change gets more expensive to fix: a problem found by a unit test costs minutes, one found in production costs much more.

Where the tester fits

Testing a PR or feature-branch build

If your team produces builds for PRs, testing one before merge is a powerful habit: bugs are found while the developer still has the change fresh in mind, and they never reach main. Write the build and commit in your comment (“Checked on PR-418 build, a1c9e2f: works on iPhone, one issue on Android”). Remember that a PR build doesn’t include other work merged in the meantime, so you’ll still check the merged result on staging.

Which build contains the fix?

This is the question that saves the most wasted time. Before you retest:

If the ticket doesn’t say which build, ask in a friendly way, and suggest adding the field. It’s one of the cheapest process improvements a tester can make.

Reading a red pipeline

You don’t have to fix a pipeline, but you should be able to read one at a basic level:

• Which stage failed? A failed build means there’s nothing to test. A failed deploy is an environment problem. A failed UI test may be a real bug.
• Which test, and what did it say? The log usually names the test and the error: “Timed out after 30 s waiting for map tiles”, “Expected €10.50 but was €9.50”.
• Is it related to the change? A pricing fix and a failing map test probably aren’t. A pricing fix and a failing cart-total test probably are.
• Is it new? The test’s history shows whether it failed before on unrelated changes.

Then say what you see, kindly: “PR #418 is red on TrackingMapTest, which timed out. It also failed on main twice this week. Looks flaky; can you re-run it?”

Flaky tests

A flaky testFlaky testA test that sometimes passes and sometimes fails without any change to the code.Open in glossary → passes and fails on the same code with no change, because of timing, test data, network or test order. They’re dangerous because they teach people to ignore red: “oh, that one always fails”. One day the red is real.

• Re-running once to unblock work is common. Re-running silently until it’s green is not.
• A flaky test is a bug in the test suite. It needs a ticket and an owner.
• Many teams quarantine a flaky test (run it, but don’t let it block merges) until it’s fixed. See Regression and Smoke Suites.

Feature flags, briefly

A feature flagFeature flagA switch that turns a feature on or off without releasing a new build.Open in glossary → lets code ship switched off and be turned on later, for some users or everyone, without a new build. For you, that means: a fix or feature can be in the build but not active. Check the flag state for your test account before you reopen a bug, test both states, and write the flag state in your results. For rollouts and flag strategy, see the interview question How do staged rollouts and feature flags change your work?

Optional: commands you’ll see

You don’t need a terminal to do any of the above. But developers paste git output into chats, and some teams ask testers to switch a local web project to a branch. These three commands only show information or switch which version you’re looking at on your own computer. They don’t change anything on the shared repository.

$ git log --oneline -3
7f3d0b1 Merge pull request #418 from fooddash/fix/FD-327-reorder-prices
a1c9e2f Use current menu prices when reordering (FD-327)
5b2e9c4 Show opening hours on the menu screen (FD-318)

git log lists commits, newest first: short hash and message. Here you can see that the fix (a1c9e2f) was merged in 7f3d0b1, after 5b2e9c4. So a build made from 5b2e9c4 doesn’t have it.

$ git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

git status tells you which branch you’re on and whether you have local changes. “Up to date with origin/main” means your copy matches what was last downloaded from the shared repository; it doesn’t download anything by itself.

$ git checkout fix/FD-327-reorder-prices
Switched to branch 'fix/FD-327-reorder-prices'

git checkout <branch> switches your local files to another branch, for example to run a web project with a fix locally. Newer git versions also offer git switch <branch> for the same thing. If a developer asks you to do this, ask them to walk you through it the first time.

Common mistakes