Git And Branching

Why this matters

Backend engineers ship code with teammates and automation. Git and branching let you: work in parallel without overwriting each other, review changes safely, and trigger CI/CD pipelines for builds, tests, and deployments. Strong branching habits reduce merge conflicts, speed up releases, and make rollbacks predictable.

• Real tasks you will do: cut a feature branch, push commits, open a pull request, resolve conflicts, squash or rebase, and merge to main to trigger CI.
• Typical CI/CD hook: merging to main or pushing a tag automatically runs tests and deploys.

Who this is for

• Backend engineers starting with team-based Git workflows.
• Developers moving from solo projects to collaborative repos and CI/CD.

Prerequisites

• Basic command line usage.
• Git installed and configured (user.name, user.email).
• Comfort editing files and running commands in a terminal.

Learning path

• Step 1: Core Git concepts (commits, branches, remotes).
• Step 2: Feature branching workflow with clean history.
• Step 3: Conflict resolution and safe rollbacks.
• Step 4: Branching strategies for teams and CI triggers.

Concept explained simply

Git is a timeline of snapshots (commits). A branch is just a movable label pointing to the latest snapshot in a line of work. When you commit, the branch pointer moves forward.

Mental model

Imagine sticky notes on a wall, each representing a commit. A branch name (like main or feature/login) is a bookmark pointing to the last sticky note in a series. Merging means connecting two lines of sticky notes so they share a common path. Rebasing means picking up your notes and placing them on top of another line, one-by-one, to create a linear story.

Core commands you will use

# Set identity (once per machine)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Create and move between branches
git switch -c feature/login     # create + switch
# or: git checkout -b feature/login

git switch main                 # go back to main

# Commit workflow
git add .
git commit -m "feat: add login endpoint"

# Sync with remote
git fetch --all                 # update remote refs
git pull                        # fetch + merge current branch
git push -u origin feature/login

# Merge vs rebase
git merge feature/login         # merge into current branch
# or
git rebase main                 # replay your commits on top of main

# Undo safely
git revert <commit_sha>         # creates a new commit that reverses changes

Worked examples

Branching strategies (short compare)

• Trunk-based: small, frequent merges to main. Encourages fast CI and fewer long-lived branches.
• Git Flow: long-lived develop, release branches, hotfix branches. More ceremony; useful for scheduled releases.

Most backend teams with CI/CD prefer trunk-based with short-lived feature branches and protected main.

Merge vs Rebase (when to choose)

• Merge: safe for shared branches, preserves full history. Good for team PRs.
• Rebase: clean linear history, but rewrite-only your own branch that no one else has pulled.

Resolving conflicts quickly

1. Run git status to see conflicted files.
2. Edit the <<<<<<< and >>>>>>> sections to keep the correct lines.
3. git add <files> then continue: git merge --continue or git rebase --continue.
4. Retest locally; then push.

Exercises

Practice locally. If you do not have a repo yet, initialize one in an empty folder with git init.

Exercise 1 — Feature branch to main (mirrors ex1)

1. Create a file api.md with one line: /healthz returns 200.
2. git add . and git commit -m "docs: add health endpoint".
3. git switch -c feature/add-user-endpoint.
4. Edit api.md to add a /users section. Commit with a clear message.
5. git switch main then git merge --ff-only feature/add-user-endpoint.

• Done when: git log --oneline shows your feature commit on main and feature/add-user-endpoint is fully merged.

Exercise 2 — Create and resolve a merge conflict (mirrors ex2)

1. On main, add line in config.json: { "timeout": 1000 } then commit.
2. Create branch A: git switch -c tune-timeout; change to "timeout": 3000, commit.
3. Return to main, change to "timeout": 1500, commit.
4. Merge A into main: git merge tune-timeout and resolve the conflict by keeping the value you prefer, then complete the merge.

• Done when: conflict is resolved, commit exists on main, and config.json contains your chosen value.

Common mistakes and self-check

• Mistake: Rebasing a shared branch. Self-check: Did anyone else pull your branch? If yes, prefer merge.
• Mistake: Long-lived branches. Self-check: Has your branch lived more than a few days? Aim to split and merge earlier.
• Mistake: Vague commit messages. Self-check: Can a teammate understand the why in under 5 seconds?
• Mistake: Force push without lease. Self-check: Always use --force-with-lease to avoid overwriting others' work.

Practical projects

• Small service repo: implement two endpoints on separate feature branches; merge both using fast-forward and ensure history stays linear.
• Rollback drill: introduce a deliberate bug, deploy to a mock environment, revert via git revert, and verify tests pass.
• Release tagging: create a v0.1.0 tag on main after merging features; simulate CI running on tags.

Mini challenge

Your service has a production bug introduced in the last merge. Create hotfix/response-500 from main, commit the fix, merge it to main, and create tag v0.1.1. Keep history clean and avoid rewriting main.

Next steps

• Protect main: require reviews and passing CI before merge.
• Learn CI triggers: run tests on pull requests and main merges.
• Adopt a small-batch workflow: smaller PRs, faster feedback, fewer conflicts.

Quick Test

Take the quick test to lock in concepts. Everyone can take it; only logged-in users get saved progress.