Remote Best Practices

The Hook (The "Byte-Sized" Intro)

The teams that never fight over Git aren't luckier — they follow simple rules. Pull before you push. Push small. Name things clearly. Clean up dead branches. These aren't advanced techniques; they're habits. And the teams that skip them spend more time fixing Git problems than writing code.

📖 What are Remote Best Practices?

These are practical habits that keep remote collaboration smooth, conflict-free, and professional. They apply to solo developers, small teams, and large organizations alike.

Conceptual Clarity

The 8 rules of smooth remote collaboration:

#	Rule	Impact
1	Pull before you push	Prevents non-fast-forward rejections
2	Push small, push often	Smaller diffs = easier reviews + fewer conflicts
3	Never force-push shared branches	Protects teammates' work
4	Use SSH keys for authentication	No credential prompts, more secure
5	Clean up remote branches	No stale clutter for the team
6	Protect `main`	Require PRs, reviews, and CI before merging
7	Keep forks in sync	Prevents massive divergence
8	Communicate before large refactors	Reduces surprise conflicts

Real-Life Analogy

Remote best practices are like rules for a shared kitchen:

Check the fridge before you go shopping (pull before push)
Put things back where you found them (clean up remote branches)
Don't move everything around without telling anyone (no surprise refactors)
Lock the spice cabinet from kids (protect main)

Visual Architecture

flowchart TD DAILY["🌅 Start of Day"] --> PULL["git pull"] PULL --> WORK["💻 Write Code"] WORK --> COMMIT["git commit<br/>(small, focused)"] COMMIT --> PUSH["git push"] PUSH --> PR["Open PR"] PR --> REVIEW["Code Review"] REVIEW --> MERGE["Merge to main"] MERGE --> CLEANUP["Delete branch"] style DAILY fill:#1a1a2e,stroke:#e94560,color:#e94560 style PUSH fill:#0f3460,stroke:#53d8fb,color:#53d8fb style CLEANUP fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Fewer conflicts: Pull-first + small pushes keep everyone close to the same state.
Faster reviews: Small PRs get reviewed in minutes; massive ones sit for days.
Trust: Teams that follow these habits trust the codebase and each other.
Velocity: Less time fixing Git problems = more time shipping features.

Code

bash

# ─── Daily workflow ───
git switch main
git pull origin main                # Always start fresh

git switch -c feature/user-profile  # Branch for new work
# ... write code ...
git add .
git commit -m "Add user profile page"
git push -u origin feature/user-profile

# Open PR on GitHub → Get review → Merge

# ─── After merge: cleanup ───
git switch main
git pull origin main
git branch -d feature/user-profile
git push origin --delete feature/user-profile

# ─── SSH key setup (do once) ───
ssh-keygen -t ed25519 -C "your.email@example.com"
cat ~/.ssh/id_ed25519.pub
# Copy to GitHub → Settings → SSH Keys

# ─── Protect main on GitHub ───
# Settings → Branches → Branch protection rules:
# ✅ Require pull request before merging
# ✅ Require approvals (1+)
# ✅ Require status checks to pass (CI)
# ✅ Do not allow force pushes

# ─── Prune stale remote references ───
git fetch --prune
git remote prune origin

# ─── Keep fork in sync ───
git fetch upstream
git switch main
git merge upstream/main
git push origin main

Remote Workflow Checklist

When	Do This
Starting a new task	Pull `main`, create a feature branch
Finished coding	Commit (small), push to your branch
Ready for review	Open a pull request
After PR is merged	Delete local + remote branch, pull `main`
Periodically	`git fetch --prune` to clean stale references
Using a fork	`git fetch upstream` + merge to stay current

Key Takeaways

Pull before you push — the simplest habit that prevents the most common error.
Push small, push often — smaller changes are easier to review, test, and merge.
Protect main — require PRs, reviews, and CI before anything reaches production.
Clean up — delete merged branches and prune stale remote references regularly.

Interview Prep

Q: What is the most common cause of push rejections and how do you prevent it? A: The most common cause is not pulling before pushing — the remote has new commits you don't have. Prevent it by always pulling (or fetching + merging) before pushing.
Q: Why should you never force-push to a shared branch? A: Force-pushing rewrites remote history. Anyone who has already pulled the original commits will have a divergent history, causing duplicate commits and forced reconciliation. It can also permanently lose teammates' work.
Q: What branch protection rules should every team enable? A: At minimum: require pull requests before merging, require at least one approval, require CI status checks to pass, and disallow force pushes. This ensures code quality, review, and automated testing before changes reach production.