Purpose
Git problems usually show up at the worst time: a merge that looked fine in review, a release branch that drifted from main, or a rollback that cannot be reproduced cleanly. This checklist helps you verify the operational basics before code moves into production use.
Use it to confirm whether your Git workflow is safe for a given change, validate the evidence you need to trust a branch or release candidate, and decide when to stop and fix history, conflicts, or missing approvals before proceeding.
How to use this checklist
Treat each phase as a gate. Do not move to the next phase until the current one has clear evidence, an owner, and a pass decision. Record the commit IDs, branch names, command output, and review results that support each check.
If you already have a branching standard, align this checklist with it. If you do not, pair it with a branch strategy review such as the Git Branching Checklist for Safer Merge and Release Workflows before approving production changes.
Phase 1: Branch setup and scope control
Use this phase to confirm the change is isolated, traceable, and based on the correct source branch. The goal is to prevent accidental drift before any merge or release activity begins.
Purpose
Verify that the branch and commit scope are explicit enough to support review, testing, and rollback.
Checklist items
- Confirm the feature or fix branch names the ticket, change request, or incident reference in a consistent format.
- Review the branch base and confirm it was created from the intended parent commit or integration branch.
- Validate that the branch contains only the required change set and no unrelated edits.
- Document the branch owner and the reviewer responsible for approval.
- Assign a clear merge target and release target if they differ.
- Confirm local and remote branch names match the team convention used for automation and policy checks.
Evidence to capture
Record the branch name, base commit, short diff summary, and the reviewer or approver identity. Include the command output that shows the branch relationship, for example git branch --show-current, git log --oneline --decorate --graph, or the equivalent in your workflow.
Acceptance criteria
The branch is traceable, scoped to one change purpose, and based on the intended parent. No unrelated files, debug edits, or emergency hotfix leftovers remain in the diff.
Owner
Developer or change author, with peer review from the assigned reviewer.
Review cadence
At branch creation, then again before every merge request update.
Common mistakes
Do not assume the branch base is correct because the code compiles. Do not merge branches that carry unrelated refactors, formatting changes, or temporary test code unless those edits are intentional and documented.
Phase 2: Commit hygiene and history integrity
Use this phase to make the history readable and safe to review. Clean history is not just cosmetic; it helps you identify exactly what changed and whether the change can be backed out.
Purpose
Verify that the commit sequence supports debugging, auditing, and rollback without ambiguity.
Checklist items
- Confirm each commit message describes one logical change and explains intent where needed.
- Review the commit sequence and validate that commits are ordered logically for review and testing.
- Validate that no accidental secrets, generated artifacts, or large binary files were committed.
- Document any force-push, amend, or history rewrite activity that affected the branch.
- Assign a reviewer to confirm whether the history should be squashed, preserved, or merged as-is.
- Test that the branch can be reproduced from a clean checkout using documented steps.
Evidence to capture
Keep the commit list, file list, and any history rewrite notes. If a rebase was used, retain the before-and-after commit references and review the history carefully; if the process is still paused or conflict-prone, use a dedicated Git Rebase Conflict Resolution for Clean Commit History workflow to verify the result.
Acceptance criteria
The history is understandable, reproducible, and free of accidental artifacts. Every commit can be explained to another engineer without guesswork.
Owner
Change author, with code review from the branch approver.
Review cadence
During active development and immediately before merge.
Common mistakes
Do not treat a successful rebase as proof that the result is safe. Do not leave vague commit messages such as “fixes” or “updates,” because they make audit and rollback analysis harder.
Phase 3: Merge safety and conflict handling
Use this phase to decide whether the change can merge cleanly and whether any conflict resolution changed the meaning of the original work.
Purpose
Confirm that the merge path preserves behavior, does not drop required changes, and does not introduce hidden conflicts.
Checklist items
- Confirm the merge target is current and contains the latest validated integration state.
- Review the diff against the merge base and validate that conflict markers are absent.
- Validate that every conflict resolution was intentional and reviewed by a second engineer when risk is high.
- Test the merged result in a clean environment that matches the target branch expectations.
- Document any file-level conflict decisions that affected behavior, configuration, or dependencies.
- Assign rollback ownership in case the merge introduces an unexpected regression.
Evidence to capture
Capture the merge commit ID, conflict resolution notes, test results, and any approval comments. If the change required a cherry-pick instead of a normal merge, verify whether the target branch differs enough to require extra validation using a targeted review like Git Cherry-Pick Conflicts: Resolve and Verify Changes Safely.
Acceptance criteria
The merge is clean, the resolved files are reviewed, and the merged branch passes the required tests without unresolved conflict markers or hidden behavioral changes.
Owner
Integrator, release engineer, or designated maintainer.
Review cadence
Before merge approval and again after the merge if the target branch changed during review.
Common mistakes
Do not resolve conflicts by accepting one side blindly. Do not approve a merge when the merged result has not been tested in the context of the target branch.
Phase 4: Test validation and regression checks
Use this phase to verify the change behaves as expected after the branch state is stable. The goal is to prove the code works in the same conditions it will face after release.
Purpose
Confirm that the branch or release candidate passes the minimum functional and regression checks required for production use.
Checklist items
- Confirm the test scope covers the changed paths, related paths, and likely failure modes.
- Review unit, integration, and smoke test results that apply to the change.
- Validate that any skipped tests are documented with a reason and an owner.
- Test environment-specific assumptions such as environment variables, secrets, and service endpoints.
- Document known failures that were accepted intentionally and are not release blockers.
- Assign test sign-off to the person who can explain the result and re-run it if needed.
Evidence to capture
Retain test logs, job links, coverage evidence where available, and notes for any failed or skipped checks. Include the exact branch or commit tested so the result cannot be misattributed.
Acceptance criteria
Required tests pass, any exceptions are documented, and there is no unresolved failure that affects the change scope.
Owner
QA engineer, developer, or release owner depending on team practice.
Review cadence
Every time the candidate changes and immediately before release promotion.
Common mistakes
Do not rely on a single happy-path test. Do not assume that unit test success means integration behavior is safe, especially when dependencies, configuration, or merge history changed.
Phase 5: Release readiness and rollback evidence
Use this phase to decide whether the branch or tag is ready for production use. This is where missing evidence becomes an operational risk.
Purpose
Verify that the release candidate has clear provenance, recovery options, and approval boundaries.
Checklist items
- Confirm the release commit or tag matches the tested branch content exactly.
- Review release notes and validate that user-visible or operator-visible changes are documented.
- Validate that configuration changes, migrations, or dependency updates are included in deployment planning.
- Document the rollback method and confirm the rollback path is still valid.
- Assign an owner for production monitoring during and after release.
- Test that rollback instructions refer to the correct tag, package, or deployment version.
Evidence to capture
Keep the release tag, release notes, approval record, deployment plan, and rollback procedure. Include the commit hash that was validated and the identity of the person who confirmed the rollback path.
Acceptance criteria
The release candidate is traceable to tested code, change notes are complete enough for operators, and rollback evidence is current and usable.
Owner
Release manager or production owner, with support from the change author.
Review cadence
Before release approval and after any late-stage change to configuration or deployment artifacts.
Common mistakes
Do not promote a tag that was not tested. Do not assume rollback is safe if the target image, package, or branch was not validated after the latest change.
Phase 6: Operational handoff and post-merge follow-up
Use this phase to close the loop after the code lands. A Git checklist is not complete if ownership, monitoring, and change evidence stop at the merge request.
Purpose
Confirm that the merged change is visible to operators, support teams, and incident responders.
Checklist items
- Confirm the merged change is linked to the ticket, incident, or release record used for approval.
- Review whether follow-up fixes, cleanup commits, or hotfix backports are required.
- Validate that monitoring, alerts, or dashboards cover the changed behavior if operational impact exists.
- Document any deferred work so it is not lost after release.
- Assign a post-release owner to watch for regressions or support questions.
- Test that the final deployed state matches the approved commit or tag.
Evidence to capture
Record the deployment reference, monitoring window, support owner, and any follow-up tasks created after merge.
Acceptance criteria
The merged change is visible in operational records, and there is a named owner for post-release verification and remediation.
Owner
Operations lead, release owner, or service owner.
Review cadence
Immediately after deployment and during the agreed monitoring window.
Common mistakes
Do not close the change just because the merge succeeded. Do not leave monitoring ownership unclear when the change touches runtime behavior, authentication, access control, or build pipelines.
Pass/fail rules
Use these rules to make the checklist actionable during review:
- Pass when every required phase has evidence, a named owner, and a documented acceptance decision.
- Conditional pass when the change is acceptable but one non-blocking item is documented with a follow-up owner and deadline.
- Fail when any phase lacks evidence, the branch base is wrong, conflicts are unresolved, tests are incomplete, or rollback cannot be performed with confidence.
A fail should stop promotion to the next stage until the gap is corrected and re-verified.
Readiness scoring
Use a simple score to estimate how complete the Git review is before production use. Score each phase from 0 to 2.
- 0 = missing or unverified
- 1 = partially verified, but evidence or ownership is incomplete
- 2 = fully verified with clear evidence
Score the six phases for a maximum of 12 points.
- 10 to 12: Ready for production use if no phase has a fail condition
- 7 to 9: Review needed; do not release until gaps are closed
- 0 to 6: Not ready; stop and correct branch, history, merge, test, or rollback issues
If any phase is a hard fail, treat the overall readiness as not ready regardless of score.
Practical checklist in one view
Use this condensed version when you need a fast review before approval.
- Confirm the branch base, scope, and owner.
- Validate commit history, messages, and reproducibility.
- Review merge safety and conflict resolution evidence.
- Test the change in the expected target context.
- Document release notes, rollback method, and deployment ownership.
- Confirm post-merge monitoring and follow-up tasks.
Final takeaway
A useful Git checklist does more than confirm that a branch exists or a merge succeeded. It proves that the change is traceable, reviewed, tested, and recoverable. If any phase cannot produce evidence, stop there, fix the gap, and re-verify before production use.
Use this guidance together with Python logging best practices and measure C# code maturity to connect the workflow with related operational context already available on the site.
