Version Control with Git & GitHub

FDEs rarely work alone — code goes to customers, gets reviewed, and must be recoverable. Git tracks changes; GitHub hosts the repo and adds collaboration. This tutorial covers the essentials every FDE needs.

Table of Contents

• Why Version Control for FDEs
• Core Git Commands
• Branches and Pull Requests
• Best Practices

Why Version Control for FDEs

Git records every change with a message and author, so you can revert a bad customer tweak or show what you changed. GitHub adds a shared home for the code, reviews, and issue tracking.

Why useful: When you edit a customer's integration live, Git is your undo button and your audit trail.

Core Git Commands

git init            # start tracking a folder
git add .           # stage changes
git commit -m "Add ticket summarizer"
git push            # send to GitHub

Explanation: init starts tracking; add stages files; commit saves a snapshot with a message; push uploads it. Each commit is a restorable point.

Common Mistake: Committing secrets or large data files. Use .gitignore for .env and outputs.

Branches and Pull Requests

git checkout -b feature/summarizer   # new branch
# ... make changes ...
git commit -m "Add summarizer"
git push -u origin feature/summarizer

Explanation: a branch is an isolated line of work. You open a Pull Request (PR) on GitHub to propose merging it — teammates or the customer review before it lands.

Best Practice: One feature per branch; keep PRs small so reviews are fast.

Best Practices

• Write clear commit messages ("Fix date parsing for EU tickets", not "fixes").
• Pull before you push to avoid conflicts.
• Note: For customer-private code, use private repos and limit access.
• Common Mistake: Working directly on main and breaking the shared baseline.