2.5 — Git Workflow
Phase 1 covered git init, git add, and git commit — the three commands for solo work. This section adds the collaboration layer: branches and pull requests.
Branching — Why It Exists
Section titled “Branching — Why It Exists”Your main branch is the “official” version of your project. When you want to try something new or fix a bug, you create a branch — a parallel copy where you work without risking the official version. When you’re satisfied with your changes, you merge the branch back.
The photocopy analogy: Making a photocopy of a document to draft edits on. Once your edits are approved and finalized, you replace the original with the updated version. The original is safe the whole time you’re drafting.
This means you can experiment freely. If the experiment fails, delete the branch — the main branch is untouched.
Pull Request (PR) — The Collaboration Handshake
Section titled “Pull Request (PR) — The Collaboration Handshake”When you want your branch merged into main, you don’t just merge it unilaterally — you create a Pull Request. This is a proposal: “Here’s what I changed, here’s why, please review.”
The draft analogy: Submitting a draft for review before publishing. The PR is the review process — others can comment, suggest changes, request revisions, and approve. Nothing merges until the review is done.
Even if you’re working alone, PRs create a record of every change and why it was made. That history is valuable when something breaks three months later.
Essential Git Vocabulary
Section titled “Essential Git Vocabulary”| Term | Definition |
|---|---|
| Branch | A parallel version of your project where you make changes safely |
| Merge | Combining changes from one branch into another |
| Pull Request (PR) | A proposal to merge a branch, with description and review process |
| Merge conflict | When two branches changed the same line — Git doesn’t know which to keep, so you decide |
| Clone | Download a copy of a remote repository to your computer |
| Fork | Make your own copy of someone else’s repository on GitHub |
| Diff | A view showing exactly what changed between two versions |
| HEAD | The current position in your Git history — “you are here” |
| Stash | Temporarily save uncommitted changes so you can switch branches |
Merge Conflicts
Section titled “Merge Conflicts”A merge conflict happens when two branches both changed the same line. Git can’t decide which version is correct — it flags the conflict and asks you to choose.
Conflicts look alarming. They are not. Git shows you both versions side by side. You pick which to keep (or combine them), save the file, and complete the merge. AI is very good at helping resolve conflicts — paste the conflict and ask it to explain the options.
Recommended Practice
Section titled “Recommended Practice”For every feature or fix:
- Create a new branch with a descriptive name (
fix/login-bug,feature/user-profile) - Make your changes and commit as you go
- Open a Pull Request when ready
- Review the diff before merging — make sure nothing unexpected changed
- Merge and delete the branch
Next: 2.6 — Debugging | Phase overview: Phase 2