Follow a change from local Git history through review and a safe, evidence-backed pipeline deployment.
55 min 230 XPSkills: Git history and diffs, Branches and merging, Pipeline diagnosis, Pipeline secrets
What you'll be able to do
›Inspect staged diffs, commits and history before sharing a change
›Create branches and resolve merge conflicts with tests and review
›Match pull request approvals and pipeline results to the current commit
›Define ordered jobs, retained artefacts and an approved deployment gate
›Diagnose failed pipeline logs and protect runtime secrets
1. Version control starts locally
Imagine keeping labelled copies instead of guessing which final-new folder is newest. Git records file changes and their history.
A repository is a local database of saved snapshots. The working tree contains files you edit. The staging area selects changes for your next commit, a saved snapshot.
Run git init to start a repository. Run git status to see untracked files, which Git does not yet record, and modified files.
Project documentation file (README). Use git add README.md to select that file. A remote, a repository elsewhere, is optional for local history.
Version control tracks changes, but it is not a complete backup strategy. Losing a laptop can lose every commit not copied elsewhere.
Version control starts locally
2. Commits, diffs and history
Think of a commit as a labelled photograph of your project. It records a snapshot, its parent reference, author information and message.
The parent reference links to earlier history. Each commit receives an object identifier, often called a Secure Hash Algorithm (SHA) identifier.
Make small commits. Explain why the change was needed in each message. A commit does not deploy software, or put it into use.
Author text alone does not prove approval. Before committing, inspect your changes with a diff, a comparison showing changed lines.
Run git diff for unstaged changes. Run git diff --staged for selected changes. Then run git commit -m "Require approval before deploy".
Run git log --oneline to list commits. Run git show a12b to inspect one commit.
In a diff, + marks added lines and - marks removed lines. Context lines stay unchanged. Never stage a credential, a secret used to gain access.
Commits, diffs and history
3. Branches and merging
Imagine a bookmark that follows your latest draft. A branch is a movable name pointing to a commit, not another server.
Run git switch -c approval-gate to create a branch for your work. New commits move its tip, the latest commit it names.
The main branch stays unchanged. Switching branches changes the files available for editing. Check git status first.
Commit unfinished work or safely set it aside before switching. When ready, switch to main and merge under your team review process.
A merge combines development histories. If main is an ancestor, an earlier commit in the same history, Git can fast-forward its pointer.
Fast-forwarding moves the branch name ahead without joining separate histories. If both branches advanced, a merge can join them.
A successful merge does not prove the combined software behaves correctly. Run the tests.
Branches and merging
4. Resolve conflicts deliberately
Imagine two people changing the same sentence differently. Git may need a person to decide how to combine their changes.
This is a merge conflict. It does not mean either contributor is wrong. Run git status to find unmerged paths, or affected files.
In text conflicts, <<<<<<<, ======= and >>>>>>> mark the competing versions. Read both changes and understand their intent. Ask the other author if needed.
Edit the file into the intended combined result. Remove conflict markers. Run relevant tests, then git add the resolved path.
Run git commit to finish the merge. Do not choose one entire side blindly. Do not delete tests to make it pass.
Run git merge --abort if you need to stop and return to the state before merging. Protect unfinished work before starting.
Resolve conflicts deliberately
5. Remotes and pull requests
Imagine sharing a project notebook with colleagues while keeping your own copy. A remote names another repository by its Uniform Resource Locator (URL), its address.
The usual remote name is origin. Run git clone to create a local copy of an existing repository.
git fetch origin downloads stored Git objects. It updates remote-tracking references, local names recording remote branch positions, without merging into your branch.
git pull fetches and then integrates changes according to configuration. git push sends local commits and updates a remote reference when permitted.
A pull request asks colleagues to review a branch before integration. This hosting workflow is not a core Git command.
Review the diff, requested reviewers and checks for the exact latest commit. Later commits can make earlier approvals and successful runs outdated.
Protect the destination branch. Require fresh checks and approval. Avoid force pushing shared history, which can replace commits colleagues rely on.
Remotes and pull requests
6. Pipelines turn commits into repeatable work
Imagine a workshop where each station must finish before the next starts. A pipeline automates a repeatable sequence of work.
A trigger starts the pipeline, such as a pull request update, push or deliberate manual action. A stage groups related work.
A job is one unit of work. A runner is the computer or process executing jobs. Independent jobs can run in parallel.
Dependencies specify which jobs must finish first. A green lint job alone does not show that every stage passed.
Here, stages run in this order: lint, test, policy check, deploy. Lint checks style and common mistakes. Tests check behaviour.
The policy check verifies required controls, or safeguards. Deployment changes the target environment. It must wait for successful checks and approval.
An artefact is saved output, such as a test report or release bundle. Retain its run identifier (ID), commit SHA and digest.
A digest is a fingerprint calculated from data. These records connect tested output to the release being deployed.
The lab uses YAML Ain't Markup Language (YAML), a text format for structured data. Its teaching schema defines allowed fields, not service-specific syntax.
Pipelines turn commits into repeatable work
7. Read the first useful failure
Imagine a delivery stops because the van broke down. The undelivered parcel is a result, not the original problem.
Start with the failed run ID, commit SHA and job. Read the first meaningful error and nearby lines, not only the final exit 1.
An exit status is a number reporting how a process finished. A nonzero value reports failure. A skipped deployment may only be a consequence.
Run 42 for a12b shows test_access.py: expected 403, received 200, then exit code 1. This points to an access-control test failure.
Access control decides who may do what. Here, status 403 means access was forbidden. Status 200 means the request succeeded.
Reproduce with the same inputs. Fix the cause and rerun checks for the new commit. Preserve the failing log and link the replacement run.
Do not bypass the test. A green run for another SHA does not prove this change safe.
A runner outage means execution infrastructure failed. A failed assertion means a test expectation was not met. Diagnose before deciding to retry.
Read the first useful failure
8. Keep secrets out of code and logs
Imagine giving a delivery driver a temporary key to one door. Deployment credentials should also grant limited access for limited time.
Keep credentials in a secret store, a controlled place for sensitive values. Supply a reference only to the approved deployment job at runtime.
Runtime means when the job executes. Prefer short-lived credentials with narrow scope, meaning permission to do only the required work.
Masking hides values in logs, the records of job activity. It reduces accidental exposure, but printing a secret remains unsafe.
Untrusted pull request code must not receive deployment credentials. Never put a token, an access secret, into YAML, commit messages, artefacts or shell echo output.
If a token enters history or logs, revoke it immediately, meaning invalidate it. Rotate it by issuing a replacement when needed.
Restrict access to exposed records and investigate use. Deleting the newest file does not erase old snapshots or copied logs.
Review who can access runners, secret stores and retained artefacts. These are part of the deployment boundary separating trusted work from untrusted access.
Keep secrets out of code and logs
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The change you did not mean to include
Scenario sim+30 XP
Read the brief and answer both questions.
Incident brief
Priya edited README.md and deploy.yml but only wants the README in this commit. Both are still unstaged.
Fill in the teaching pipeline from the requirements. Its schema defines the file structure. The file cannot run directly on a hosting platform.
Pull request events run checks, not deployment. Require main and approval before a trusted run after merging may deploy. Use only shown fields. Do not add credential values or executable commands.
Required pipeline contract
Trigger: pull_request. Ordered stages: lint, test, policy_check, deploy. Each job uses its stage name and run command lint, test, policy-check or deploy. Dependencies: test needs lint; policy_check needs test; deploy needs policy_check. Deploy requires approval and branch main. Test saves test-report with include_commit_sha and include_run_id true. Deploy secret_ref DEPLOY_TOKEN, secret_scope deploy, expose_to_pull_requests false, log_secrets false. No other secret values or fields.
Accept only statements supported by the exact commit and run evidence. Reject stale evidence, failed runs and exposed credentials.
Verdicts are accept or reject. Every rejection needs one reason code from: stale-evidence | failed-check | secret-exposure.
Commit and run review
GP-1 | Head b34c is ready because run 41 passed for a12b; no b34c run exists.
GP-2 | Run 42 for b34c failed test_access: expected 403, received 200. Deploy should stay blocked.
GP-3 | Run 43 for c56d passed lint, test and policy_check; deployment is waiting for a named approver, so it has not deployed yet.
GP-4 | A token printed by run 44 is safe because the latest commit deleted it. The token is still valid.
GP-5 | Run 45 tested d78e; release artefact digest and SHA d78e match the approved deployment record.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · IT Fundamentals
IT Fundamentals Capstone
Understand estate audit, control testing, evidence pack and test the resulting controls with reproducible evidence.
