By the end of this lesson, you will:
Definition: Git collaboration transforms individual coding into team superpowers. Multiple developers can work simultaneously while maintaining code quality and project stability.
Without Structured Collaboration:
With Git Workflows:
A pull request (PR) is a formal way to say: "Hey team, I've made some changes. Please review them before we add them to the main project."
1. Create feature branch
2. Make changes and commits
3. Push branch to GitHub
4. Open pull request
5. Team reviews code
6. Address feedback
7. Merge when approved
8. Delete feature branch
## What This PR Does
- Implements JWT-based authentication
- Adds login/logout functionality
- Includes password reset flow
## Why This Change
- Current session-based auth doesn't scale
- Need mobile app compatibility
- Security audit requirements
## Testing Done
- [x] Unit tests pass
- [x] Manual testing on Chrome/Firefox
- [x] Load tested with 1000 concurrent users
## Screenshots
<!-- Add screenshots of your changes here -->
<!-- Example:  -->
Forking creates your own copy of someone else's repository. You can make changes without affecting the original.
# Clone your fork (not the original)
git clone https://github.com/YOUR-USERNAME/original-repo-name.git
cd original-repo-name
# Add original repository as "upstream"
git remote add upstream https://github.com/ORIGINAL-OWNER/original-repo-name.git
# Verify remotes
git remote -v
# origin https://github.com/YOUR-USERNAME/repo.git (fetch)
# origin https://github.com/YOUR-USERNAME/repo.git (push)
# upstream https://github.com/ORIGINAL-OWNER/repo.git (fetch)
# upstream https://github.com/ORIGINAL-OWNER/repo.git (push)
# Fetch latest changes from upstream
git fetch upstream
# Switch to main branch
git switch main
# Merge upstream changes
git merge upstream/main
# Push updates to your fork
git push origin main
# Always branch from updated main
git switch main
git pull upstream main
git switch -c fix/typo-in-documentation
# Make your changes
git add .
git commit -m "Fix typo in installation instructions"
git push origin fix/typo-in-documentation
Then create PR from your fork to the original repository.
Focus On:
Sample Review Comments:
✅ "Consider using a Map here for O(1) lookups instead of array.find()"
✅ "This function is getting complex. Could we extract the validation logic?"
✅ "Great solution! One small thing: we should handle the null case on line 42"
❌ "This is wrong"
❌ "Why did you do it this way?"
❌ "Bad code"
Responding to Feedback:
# After addressing feedback, push updates
git add .
git commit -m "Address review feedback: add error handling"
git push origin feature-branch
Conflicts happen when two branches change the same lines of code differently.
main: A---B---C (changed line 10)
\
feature: D---E (also changed line 10)
# When merging, Git tells you about conflicts
git merge feature-branch
# Auto-merging index.html
# CONFLICT (content): Merge conflict in index.html
# Automatic merge failed; fix conflicts and then commit the result.
# Check status
git status
# Unmerged paths:
# both modified: index.html
Git marks conflicts in your files:
<!DOCTYPE html>
<html>
<head>
<<<<<<< HEAD
<title>My Awesome Site</title>
=======
<title>My Amazing Website</title>
>>>>>>> feature-branch
</head>
Conflict Markers Explained:
<<<<<<< HEAD - Start of current branch version======= - Separator between versions>>>>>>> feature-branch - End of merging branch versiongit status
# Lists all files with conflicts
Choose what to keep:
<!-- Remove conflict markers and choose your solution -->
<!DOCTYPE html>
<html>
<head>
<title>My Incredible Website</title> <!-- Our chosen solution -->
</head>
git add index.html
git commit -m "Resolve merge conflict in page title"
Keep changes from both branches:
// Before conflict:
// Branch A: function getName() { return firstName; }
// Branch B: function getName() { return lastName; }
// After resolution:
function getName() {
return firstName + ' ' + lastName;
}
# Take their version entirely
git checkout --theirs filename
# Take our version entirely
git checkout --ours filename
# Stage the resolved file
git add filename
# Configure merge tool (one-time setup)
git config --global merge.tool vimdiff
# Launch merge tool for conflicts
git mergetool
<type>(<scope>): <description>
<body>
<footer>
Examples:
feat(auth): add JWT token authentication
- Implement login/logout endpoints
- Add token validation middleware
- Include refresh token logic
Closes #123
fix(api): handle null user data gracefully
Previously the API would crash when receiving null
user data. Now it returns a proper error response.
Fixes #456
@username can you review this?
@team-name please see this change
Fixes #123
Closes #456
Related to #789
Branch Structure:
main - Production-ready codedevelop - Integration branch for featuresfeature/* - Individual feature developmentrelease/* - Preparing new releaseshotfix/* - Emergency fixes to productionProcess:
# Update your branch
git switch your-feature-branch
git merge main
# Resolve any conflicts
git push
# Create branch from current state
git switch -c feature/moved-from-main
# Reset main to previous state
git switch main
git reset --hard HEAD~1
# Push the new branch
git push origin feature/moved-from-main
This is normal! Use proper merge strategies:
You understand:
Next up: Advanced recovery techniques for when things go wrong!