Forward Deployed Engineer 101: Version Control and Code Review (Git, Pull Requests, Collaborative Coding)

Version Control and Code Review (Git, Pull Requests, Collaborative Coding)

Version Control & Code Review: Field-Ready Study Guide for Forward Deployed Engineers (FDEs)

What This Is

Version control (Git) and code review (Pull Requests) are the backbone of collaborative, high-stakes engineering—especially when deploying in constrained environments (air-gapped networks, classified systems, or disaster response zones). As an FDE, you’ll often work in teams where a single misplaced commit can break a live system, violate compliance, or delay a critical mission. Example: You’re on-site at a defense contractor, deploying a real-time sensor fusion pipeline. The customer’s security team flags a hardcoded API key in your main branch during a pre-deployment audit. Without proper Git hygiene (e.g., .gitignore, pre-commit hooks, and PR reviews), you’d be scrambling to rewrite history under pressure—while the mission clock ticks.

Key Terms & Concepts

• Git Rebase vs Merge:
• Rebase rewrites commit history (cleaner, but risky in shared branches).
• Merge preserves history (safer for teams, but can clutter logs).

• FDE Rule: Rebase local branches, merge shared branches (e.g., main).

• Pull Request (PR) / Merge Request (MR):

• A formal request to merge code into a protected branch (e.g., main, prod).

• FDE Use Case: PRs are your audit trail—critical for compliance (e.g., ATO, CMMC). Always require 2+ approvals for production changes.

• Git Hooks (Pre-Commit, Pre-Push):

• Scripts that run automatically before commits/pushes (e.g., linting, secret scanning).

• FDE Tool: Use pre-commit with hooks like detect-secrets to block API keys in code.

• Git LFS (Large File Storage):

• Manages large binaries (e.g., ML models, firmware) without bloating the repo.

• FDE Trap: Air-gapped environments may not support LFS—plan for manual transfers.

• Squash Merging:

• Combines all PR commits into one before merging (keeps main clean).

• FDE Rule: Use for feature branches; avoid for hotfixes (preserve history for debugging).

• Git Submodules:

• Embeds one repo inside another (e.g., a shared library in a customer’s private repo).

• FDE Use Case: Critical for air-gapped deployments where dependencies must be vendored.

• Signed Commits (GPG):

• Cryptographically signs commits to prove authorship (required for classified systems).

• FDE Command: git commit -S -m "..." (configure GPG keys in GitLab/GitHub settings).

• Git Bisect:

• Binary search to find the commit that introduced a bug.

• FDE Example: Customer reports a crash in v1.2.3. Run git bisect start v1.2.3 v1.0.0 to pinpoint the faulty commit.

• Protected Branches:

• Branches (e.g., main, prod) that require PRs, approvals, and status checks.

• FDE Rule: Enforce this before the first deployment—retrofitting is painful.

• Git Worktrees:

• Lets you work on multiple branches simultaneously (e.g., debugging main while fixing a hotfix).

• FDE Command: git worktree add ../hotfix hotfix-branch.

• Git Patch Files:

• Portable diffs (.patch) to apply changes without network access.

• FDE Use Case: Deploying fixes to an air-gapped system via sneakernet.

• Code Owners (CODEOWNERS file):

• Automatically requests reviews from specific teams (e.g., @security-team for sensitive changes).
• FDE Example: Add *.yaml @infra-team to ensure Kubernetes manifests are reviewed by ops.

Step-by-Step / Field Process

1. Initialize a Repo for High-Stakes Work

• Action: Create a repo with immediate protections.
  bash git init echo "*.env" >> .gitignore # Block secrets echo "*.key" >> .gitignore git add .gitignore git commit -m "Initial commit: add .gitignore"
• FDE Step: Push to a private remote (GitLab, GitHub Enterprise, or customer’s on-prem Git server).
  bash git remote add origin git@customer-gitlab:project/repo.git git push -u origin main
• Enable Branch Protection:
• Require PRs, 2 approvals, and status checks (e.g., CI/CD pipeline passes).

2. Develop a Feature in Isolation

• Action: Create a feature branch with a clear scope.
  bash git checkout -b feat/sensor-data-validation
• FDE Rule: Branch names should include:
• Type (feat, fix, docs, hotfix).
• Jira ticket (e.g., PROJ-123).
• Short description (kebab-case).
• Commit Early, Commit Often:
  bash git add src/validation.py git commit -m "feat: add sensor data checksum validation (PROJ-123)"
• FDE Tip: Use Conventional Commits for auditability.

3. Open a PR with Context

• Action: Push the branch and open a PR with a template.
  bash git push origin feat/sensor-data-validation
• PR Template Must Include:
• Problem: "Customer’s sensor data is corrupted in 5% of payloads."
• Solution: "Add checksum validation with fallback to last known good value."
• Testing: "Tested locally with 1000 synthetic payloads; CI pipeline runs integration tests."
• Screenshots/Logs: Attach error logs or before/after metrics.
• FDE Rule: Tag relevant teams (e.g., @security-team for crypto changes).

4. Review & Iterate

• Action: Address feedback without rebasing shared history.
  bash git add src/validation.py git commit -m "fix: handle null checksums (addresses @alice's review)" git push origin feat/sensor-data-validation
• FDE Rules:
• Never force-push to a shared branch (breaks others’ work).
• Squash trivial commits (e.g., typo fixes) before merging.

5. Merge & Deploy

• Action: Merge via PR (squash if needed).
• FDE Checklist:
  • All status checks pass.
  • 2+ approvals (including a security review if applicable).
  • No merge conflicts.
• Post-Merge:
• Delete the feature branch (keeps repo clean).
• Tag the release (e.g., git tag -a v1.2.4 -m "Add sensor validation").
• Deploy via CI/CD pipeline (or manually if air-gapped).

6. Handle a Hotfix Under Pressure

• Scenario: Customer reports a critical bug in v1.2.4 during a live mission.
• Action:
  bash git checkout -b hotfix/sensor-crash v1.2.4 # Branch from the tag # Fix the bug (e.g., add a null check) git add src/validation.py git commit -m "hotfix: prevent crash on null sensor ID (PROJ-124)" git push origin hotfix/sensor-crash
• FDE Rules:
• Test in the customer’s environment (not your laptop).
• Deploy via patch file if no network access:
  bash
git format-patch HEAD~1 # Creates 0001-hotfix-...patch
  • Transfer the .patch file via USB, then apply: bash git am 0001-hotfix-*.patch

Common Mistakes

FDE Interview / War Story Insights

1. "Tell me about a time you had to revert a bad deployment."

• What They Want: Evidence you can handle pressure, debug quickly, and follow process.
• How to Answer:
• Describe the impact (e.g., "The customer’s dashboard went blank during a live demo").
• Explain the root cause (e.g., "A merge conflict in config.yaml broke the API endpoint").
• Walk through the recovery:
  bash
git revert HEAD # Revert the bad commit
git push origin main
# Deploy the revert via CI/CD
• Highlight prevention (e.g., "We added a pre-deploy smoke test to catch config errors").

2. "A customer demands a last-minute feature that wasn’t in the original scope. How do you respond?"

• FDE Approach:
• Acknowledge the ask: "I understand this is critical for your mission."
• Clarify the trade-offs: "Adding this now will delay the current deployment by 2 days and may introduce security risks."
• Propose a phased solution:
  • Short-term: Deploy the current scope as-is, then open a PR for the new feature.
  • Long-term: Document the request in the backlog and prioritize it for the next sprint.
• Escalate if needed: If the customer insists, loop in your PM/tech lead to align on priorities.

3. "How do you handle a PR where the reviewer’s feedback is wrong?"

• FDE Approach:
• Assume good intent: "I might be missing context—let me clarify."
• Provide data: "The logs show the API returns a 403, not a 404. Here’s the curl output."
• Compromise: "I’ll add a comment in the code to explain the edge case."
• Escalate if stuck: "Let’s sync with @security-team to align on the right approach."

Quick Check Questions

1. You’re deploying to an air-gapped system and need to update a dependency. The customer’s Git server is down. What’s your first step?

Answer: Generate a patch file (git format-patch) or a tarball (git archive) of the changes, transfer it via USB, and apply it manually.
Why: Air-gapped environments require offline-friendly workflows. Patch files are portable and don’t rely on network access.

2. A teammate force-pushed to main, overwriting your changes. How do you recover?

Answer: Use git reflog to find the lost commit, then git cherry-pick or git reset --hard to restore it.
Why: git reflog tracks all local changes, even after force-pushes. Always check it before panicking.

3. You’re on-site and the customer’s security team blocks your PR because it contains a hardcoded password. The password is in a commit from 3 days ago. How do you fix this?

Answer: Use git filter-repo (or git filter-branch) to rewrite history and remove the password, then force-push to the branch (but never to main).
Why: Rewriting history is the only way to fully purge secrets. Document the change in the PR description for auditability.

Last-Minute Cram Sheet

1. Key Commands:
2. git rebase -i HEAD~5 → Squash/fixup commits.
3. git bisect start v1.0.0 v1.2.0 → Find the bad commit.
4. git format-patch HEAD~1 → Create a patch file for air-gapped deploys.

5. git worktree add ../debug debug-branch → Work on multiple branches.

6. PR Checklist:

7. [ ] 2+ approvals (including security if applicable).
8. [ ] All status checks pass (CI/CD, linting, tests).
9. [ ] No merge conflicts.
10. [ ] No secrets or sensitive data.

11. [ ] Tagged with the Jira ticket.

12. Field Traps:

13. ⚠️ Never commit to main directly—always use a PR.
14. ⚠️ Test in the customer’s environment—your laptop ≠ their firewall.
15. ⚠️ Rebase local branches, merge shared branches—keep main clean.
16. ⚠️ Use signed commits for classified systems (GPG).

17. ⚠️ Delete feature branches after merging—keeps the repo clean.

18. Acronyms:

19. ATO: Authority to Operate (compliance approval).
20. CMMC: Cybersecurity Maturity Model Certification (DoD standard).
21. IAM: Identity and Access Management (e.g., AWS IAM, GitLab permissions).

22. ACO: Approval Chain of Operations (who signs off on deployments).

23. Ports to Know:

24. Git over SSH: 22 (or 443 if 22 is blocked).
25. Git over HTTPS: 443.
26. GitLab/GitHub Enterprise: Often 80/443 (but check customer’s setup).