DevOps / Basic: shared foundations / Lesson 2
Git, review, and small reversible changes
Use version history as evidence for collaboration and recovery while separating a reviewed commit from a deployed outcome.
On this page
Lesson goals
- Distinguish working tree, index, and committed snapshots.
- Prepare a coherent change and review evidence.
- Separate source reversal from service recovery.
Understand the three local views
Git distinguishes the working tree, the index, and committed history. Editing a file changes the working tree; staging selects content for the next commit. A commit records a snapshot and its relationships, not merely a list of filenames. The first diagnostic transcript separates unstaged and staged differences so a reviewer can see what will actually be committed. These commands are read-only but depend on an existing repository and are therefore not runnable course scripts. Never assume a clean editor buffer means the intended content is already staged or committed.
git status --short
git diff -- app.conf
git diff --cached -- app.conf
status summarizes state; diff shows unstaged edits; diff --cached shows the next snapshot. No repository is assumed or accessed by this course.
Keep the unit of review coherent
A small change should express one understandable intent, including its tests and relevant documentation. Small does not mean splitting a required migration from the code that explains its compatibility. Reviewers need the trigger, expected behavior, evidence, and recovery implications. Large mixed changes hide defects and make reverting one concern harder. The second example is a review record that links an input contract change to its tests and rollout rule. Review is a technical conversation about risk and correctness; a green approval icon cannot compensate for missing context or an unreviewed generated file.
intent: reject-empty-booking-name
behavior: invalid-input-returns-400
evidence: contract-and-regression-checks
compatibility: existing-valid-requests-unchanged
recovery: restore-previous-reviewed-artifact
The record explains the change, checks, and compatibility boundary. It is an editorial example, not a workflow engine configuration.
Choose an integration policy
Short-lived branches and frequent integration reduce the amount of unseen divergence, but branch policy must match the teamโs workflow. Require meaningful checks on the content being merged and ensure they are rerun when that content changes. A merge conflict means Git cannot combine edits automatically; resolving markers is only the first step. Re-read the resulting behavior and run relevant checks because a conflict-free merge can also be semantically wrong. Keep protected branches and access rules explicit, and avoid bypassing them through a separate delivery account with broader permissions.
Separate history recovery from state recovery
A revert adds a commit that reverses earlier content; it does not erase history and does not automatically reverse a database migration, external message, or deployed secret. Rewriting shared history changes commit identities and can disrupt collaborators. Prefer an explicit recovery plan for shared changes and preserve evidence during incidents. If a credential entered Git, deleting the line is insufficient because history and copies may retain it: revoke or rotate the credential through the authorized process. Rebuild and redeploy a reviewed artifact when recovery requires code changes.
Connect commits to delivery evidence
Record the exact source revision, build identity, artifact digest, configuration revision, and rollout result. A branch name is a moving pointer and is not sufficient evidence of deployed content. Tags can also move unless policy prevents it. A commit identity proves which source was selected, not that the build was reproducible or the release healthy. Link these records without storing credentials. During a diagnosis, compare the intended revision with the running artifact before assuming that the latest repository change reached every instance. This link makes both rollback decisions and audit questions answerable.
Common errors and fixes
The commit omits the intended edit
- Why it happens
- Working-tree changes were confused with staged content.
- How to fix it
- Inspect the staged diff before committing.
- Prevent it next time
- Review the exact snapshot and include required new files.
A revert does not recover the service
- Why it happens
- The incident included state or configuration beyond Git content.
- How to fix it
- Use the release recovery plan and assess data compatibility.
- Prevent it next time
- Record code, artifact, configuration, and schema identities together.
Resolved conflicts still break behavior
- Why it happens
- Markers were removed without reviewing combined semantics.
- How to fix it
- Re-read the merged result and run targeted checks.
- Prevent it next time
- Keep changes focused and integrate frequently.
Check your understanding
1. A file contains a staged fix and a later unstaged debug print. Which diff describes the next commit?
Show worked solution
git diff --cached describes the staged snapshot and excludes the later print unless it was staged too. Inspect both differences to avoid accidentally adding unrelated debugging. After the commit, verify its content rather than treating the working file as the historical record.
2. A leaked token was removed in a new commit. What remains necessary?
Show worked solution
Revoke or rotate the token using the approved credential process, assess access and exposure, and prevent new disclosure. History removal may be a separate coordinated task, but it cannot make a copied secret safe. Preserve a safe incident record without reproducing the token.
Key takeaways
- Git distinguishes the working tree, the index, and committed history.
- Short-lived branches and frequent integration reduce the amount of unseen divergence, but branch policy must match the teamโs workflow.
- Record the exact source revision, build identity, artifact digest, configuration revision, and rollout result.