🤝 Collaborative Git: Remotes, PRs, and Safety Nets

🎯 Lesson Objectives

By the end of this lesson, you will be able to:

• Connect local projects to GitHub using Remotes.
• Master the Feature Branch Workflow used by professional teams.
• Understand how to safely undo mistakes in a shared codebase without breaking history.
• Resolve Merge Conflicts using standard developer tools.

---

1️⃣ One Source of Truth: Remotes

A Remote is simply a copy of your project hosted in the cloud (like GitHub). It allows teams to sync their work.

Cloning vs. Adding

• git clone <url>: Use this when a project already exists on GitHub and you want to download a copy. It automatically sets up the remote for you.
• git remote add origin <url>: Use this when you have a local project and want to connect it to a brand new, empty GitHub repository.

---

2️⃣ Syncing: Fetch, Pull, and Push

Collaboration is a constant cycle of pushing and pulling code:

• git push origin <branch>: Uploads your local commits to GitHub.
• git fetch: Downloads current "news" from GitHub. It updates your local database of what others have done, but does not touch your files.
• git pull: Downloads the code AND instantly merges it into your files.

[!CAUTION] git pull can be scary because it forces a merge. Many pro developers prefer git fetch followed by a manual check before merging.

---

3️⃣ The Safe Undo: git revert vs git reset

In a shared GitHub repo, never use git reset --hard on a branch someone else is using. It rewrites history and can crash your teammates' work.

🛡️ The Professional Way: git revert

If a bad bug reaches the main branch, use git revert <hash>.

Instead of deleting the "bad" commit, Git creates a new "Undo" commit that reverses the changes. This keeps history linear and safe for everyone on the team.

Command	Safety	Effect
git revert	✅ Safe	Adds a NEw commit to undo old work.
git reset --hard	❌ Dangerous	Deletes history permanently. Only use on private, local work.

---

4️⃣ The Feature Branch Workflow

Professional teams never commit directly to main.

1. Branch: git checkout -b feature/login (Create an isolated space).
2. Work: Code, add, and commit locally.
3. Push: git push origin feature/login.
4. PR: Open a Pull Request on GitHub for code review.
5. Merge: Once approved, the code is merged into main.

---

🧪 Practice Exercise: The Team Simulator

Try this flow to simulate a team environment:

# 1. Create a branch for a new feature
git checkout -b lab-feature

# 2. Simulate work
echo "Adding navbar" > navbar.html
git add .
git commit -m "feat: add basic navbar"

# 3. Simulate a mistake that needs undoing
echo "Bad code that breaks stuff" >> navbar.html
git add .
git commit -m "feat: add broken analytics"

# 4. Save the day with a Revert
git log --oneline # Copy the hash of the 'broken' commit
git revert <paste-hash-here>

# 5. Check history - notice the NEW 'Revert' commit
git log --oneline

---

🖼️ GitHub Workflow

---

🎥 Lesson Video

<video controls width="100%"> <source src="/videos/lesson-5-collaborative-git.mp4" type="video/mp4"> Your browser does not support the video tag. </video>

---

📝 Project Task: Team Collaboration Simulation

1. Create a local repo and a file main.js. Commit it to main.
2. Create a branch team-feature-1 and add style.css. Commit it.
3. Modify main.js on your branch and commit it.
4. Switch back to main, and modify main.js there too. (This sets up a conflict!)
5. Try to merge your branch: git merge team-feature-1.
6. Resolve the Conflict: Open main.js, pick the best version, stage it, and commit.
7. Final check: Use git revert to undo your very first commit on the branch.