Use version control to manage source code, including commits, branches, merges, pull requests and remote repositories

What this dot point is asking

NESA wants you to use Git for source control: create commits, work on branches, push to a remote, open pull requests, and merge. You should be able to describe the feature-branch workflow that almost every professional team uses.

The answer

Why version control

• History: every change is recorded, with the author, timestamp and message.
• Collaboration: many developers can work on the same project without overwriting each other.
• Branching: experimental work lives separately from the main code.
• Rollback: if a change breaks something, revert to a previous state.
• Bisect: when a bug appears, Git can binary search through history to find which commit introduced it.

Git is by far the most common version control system. GitHub, GitLab and Bitbucket are hosted Git services.

Core concepts

• Repository (repo): the project, including all its history.
• Commit: a snapshot of the project at a moment in time. Identified by a SHA-1 hash. Each commit points to its parent.
• Branch: a movable pointer to a commit. The default branch is usually main (or master).
• HEAD: the commit you currently have checked out.
• Remote: a copy of the repo hosted elsewhere (GitHub).
• Pull request (PR) / Merge request (MR): a proposal to merge a branch into another, reviewed before being accepted.

The standard workflow

The feature-branch graph below shows how a branch diverges from main, accumulates commits, and is merged back. The merge commit on main has two parents.

# Start: clone the remote repo
git clone https://github.com/team/project.git
cd project

# Create a branch for your feature
git checkout -b feature/add-login

# Make changes, then stage and commit them
git add login.py templates/login.html
git commit -m "Add login form with bcrypt verification"

# Make more changes, more commits...
git add tests/test_login.py
git commit -m "Add tests for login flow"

# Push the branch to the remote
git push -u origin feature/add-login

# Open a pull request on GitHub.
# After review and approval, merge into main.

# Sync local main and clean up
git checkout main
git pull
git branch -d feature/add-login

Commit messages

A good commit message explains the why, not just the what. Format:

Add login form with bcrypt verification

Previously, login compared passwords as plain text strings, which
left the database vulnerable to a credential dump. This commit
hashes passwords with bcrypt at signup and uses checkpw at login.
Existing users will need to reset their passwords on next login.

The first line is the subject (50 chars max). A blank line, then the body wrapped at 72 chars.

Merging strategies

When a pull request is merged, three options:

• Merge commit: creates a new commit on main that has both parents. Preserves the branch history exactly.
• Squash and merge: combines all commits on the branch into a single commit on main. Cleaner history, loses fine-grained detail.
• Rebase and merge: replays the branch's commits on top of main as individual commits. Linear history, requires care.

Most teams use squash-and-merge for clean main history.

Conflict resolution

When two branches change the same lines, Git cannot merge automatically. It marks the conflict in the file:

<<<<<<< HEAD
return "v2"
=======
return "v3"
>>>>>>> feature/new-version

You edit the file to pick the correct content, then:

git add conflicted_file.py
git commit

.gitignore

Some files should never be committed: build artefacts, secrets, IDE settings, node_modules. List patterns in .gitignore:

# Python
__pycache__/
*.pyc
venv/

# Secrets
.env
config/secrets.yml

# IDEs
.idea/
.vscode/

# Build output
dist/
build/

Pull requests in detail

A pull request triggers:

• Automated checks (test runner, linter, type checker, security scanner).
• Human review (the team approves or requests changes).
• Optional protections (require at least N approvals, require all checks to pass, require up-to-date with main).

Only after all checks pass and reviews are approved can the PR merge. This is the gate that keeps main in a working state.

Tags and releases

A tag marks a specific commit (typically a release):

git tag -a v1.0.0 -m "Initial public release"
git push --tags

Worked example: a team of four

Four developers work on the same code base.

• Each clones the repo locally: git clone ....
• Each works on their own feature branch: git checkout -b feature/their-task.
• They commit small, focused changes throughout the day.
• At the end of a unit of work, they git push -u origin feature/their-task and open a PR.
• The other three review the PR, leave comments, request changes.
• CI runs the test suite on the PR.
• Once approved and passing, the PR is squashed-and-merged.
• The developer pulls main (git checkout main && git pull) and deletes the merged branch (git branch -d feature/their-task).

Conflicts arise when two PRs change the same lines. The second PR to merge has to update from main and resolve the conflict locally before merging.