Intermediate Git

Branching, Merging & Collaboration

CSCI 4513

Week 6, Lecture 12

Today's Learning Objectives

🎯 Master Git branching strategies
🎯 Resolve merge conflicts
🎯 Use Git for collaboration
🎯 Understand pull requests

🎮 Let's Visualize Git Together!

Before diving into advanced concepts, let's SEE how Git works!

We'll use an interactive game to visualize branching, commits, and merges. This hands-on exploration builds intuition!

How This Works:

🌐 Everyone go to learngitbranching.js.org
🎯 We'll work through the first 4 challenges together with your input
👥 I'll guide us, but I want to hear your ideas and thinking
💡 See how branches, commits, and merges actually work visually!

Why Change Git History?

Nobody is perfect! Sometimes you need to fix mistakes in your commit history.

Common Scenarios:

Commit too early and forgot a file
Typo in a commit message
Need to combine multiple commits into one
Want to split up a large commit
Need to reorder commits

⚠️ Warning: Only change history that hasn't been pushed to a shared repository!

Changing the Last Commit

Use git commit --amend to fix your most recent commit:

# Forgot to add a file?
git add forgotten_file.js
git commit --amend

# Want to change the commit message?
git commit --amend -m "New commit message"

--amend - Replaces the last commit entirely (creates a new commit hash)

Forgot a file? - Stage it with git add first, then --amend adds it to the previous commit

-m - Provide a new message inline; without it, Git opens your editor

Only safe for commits that haven't been pushed yet!

What Actually Happens:

--amend doesn't edit the commit—it replaces it with a new one. The old commit is destroyed and a new one is created.

⚠️ Never amend commits that have been pushed! You could destroy work others are basing their changes on.

Changing Multiple Commits

Use git rebase -i to interactively modify multiple commits:

# Edit the last 3 commits
git rebase -i HEAD~3

# Edit all commits back to root
git rebase -i --root

-i - Interactive mode; opens an editor where you choose what to do with each commit

HEAD~3 - Go back 3 commits from HEAD (the current commit)

--root - Go all the way back to the very first commit

The editor lists commits oldest-first — the opposite of git log!

Options Available:

pick - Use the commit as-is
edit - Stop to amend the commit
squash - Combine with previous commit
reword - Change the commit message
drop - Remove the commit entirely

Interactive Rebase in Action

Let's say you want to fix a typo in a commit message:

# Start the rebase
git rebase -i HEAD~2

# In the editor, change from:
pick eacf39d Create send file
pick 92ad0af Create third file

# To:
edit eacf39d Create send file
pick 92ad0af Create third file

# Then amend the commit
git commit --amend -m "Create second file"

# Finish the rebase
git rebase --continue

Step 1: Start interactive rebase for the last 2 commits

Step 2: Change pick → edit for the commit you want to fix

Step 3: Git pauses at that commit — now amend it with the corrected message

Step 4: --continue finishes replaying the remaining commits

Notice "send file" was a typo — this workflow fixes it to "second file"

💡 Tip: Commits appear in reverse order in rebase (oldest first) compared to git log (newest first).

Squashing Commits

Squashing combines multiple commits into one, keeping your Git history clean and readable.

# In interactive rebase:
pick e30ff48 Create first file
squash 92aa6f3 Create second file
squash 05e5413 Create third file

# All three commits become one!

pick - Keep this commit as the base; squashed commits merge into it

squash - Merge this commit into the one above it (the picked commit)

Result: Three commits → one commit with a combined message you can edit

The first commit must be pick — you need a base to squash into!

Why Squash?

Cleaner project history
Easier to understand changes
Standard practice on many dev teams

🎮 Git Practice Break!

Time to practice what we just learned!

Your Task:

🌐 Return to learngitbranching.js.org
🎯 Continue with the next set of challenges
💪 Apply the concepts we just covered (branching, rebasing)
🙋 Raise your hand if you get stuck—that's what I'm here for!

Splitting Up a Commit

Use git reset to split a commit that does too much:

# In interactive rebase, mark commit as 'edit'
git rebase -i HEAD~1

# Reset to commit before HEAD
git reset HEAD~

# Now add and commit files separately
git add file1.js && git commit -m 'Add feature A'
git add file2.js && git commit -m 'Add feature B'

# Continue the rebase
git rebase --continue

Step 1: Mark the commit as edit so Git pauses there

git reset HEAD~ - Undoes the commit but keeps all files in your working directory (mixed reset)

Step 3: Selectively add and commit files into separate, focused commits

Step 4: --continue finishes the rebase with your new split commits

What git reset HEAD~ does:

Moves HEAD to previous commit
Updates staging area to match
Leaves working directory unchanged

Understanding git reset

git reset --soft

git reset --soft HEAD~1

Moves HEAD only. Staging area and working directory stay the same.

git reset (mixed)

git reset HEAD~1

Moves HEAD and updates staging area. Working directory unchanged.

git reset --hard

git reset --hard HEAD~1

⚠️ DANGER! Moves HEAD, updates staging, AND overwrites working directory. Can destroy data!

┌────────────┬────────┬─────────┬─────────┐
│  Mode      │  HEAD  │ Staging │ Working │
├────────────┼────────┼─────────┼─────────┤
│  --soft    │ Moves  │  Same   │  Same   │
│  (mixed)   │ Moves  │ Resets  │  Same   │
│  --hard    │ Moves  │ Resets  │ Resets  │
└────────────┴────────┴─────────┴─────────┘

Each level resets one more thing — soft is safest, hard is most destructive

Branches Are Pointers

A branch is just a pointer to a single commit. That commit points to the one before it, forming a chain.

Key Concepts:

Commit: A snapshot of your files + pointer to previous commit
Branch: A pointer to a single commit
HEAD: A special pointer showing which branch you're on

💡 Example: When you run git rebase -i HEAD~2, Git starts at HEAD, follows the pointer to the previous commit, then follows that pointer to edit the last 2 commits.

Working with Remotes

When collaborating, you'll work with remote repositories on GitHub.

The Safety Mechanism:

Git only lets you push if your local branch is up-to-date with the remote. This prevents you from overwriting others' work!

# This will fail if remote has new commits
git push origin main

# Update your local branch first
git fetch origin
git merge origin/main
git push origin main

git fetch - Downloads new commits from the remote without merging them

git merge origin/main - Integrates the fetched remote changes into your local branch

The pattern: fetch → merge → push ensures you never overwrite teammates' work

git pull is a shortcut that does fetch + merge in one step!

🎮 Git Practice Break!

Let's practice working with remotes!

Your Task:

🌐 Return to learngitbranching.js.org
🎯 Work on the remote challenges
💪 Practice pushing, pulling, and fetching
🙋 Ask questions if you need help!

The Danger of Force Pushing

git push --force overwrites the remote repository with your local history. This can destroy your teammates' work!

# DON'T DO THIS without good reason!
git push --force origin main

--force - Overwrites the remote history with your local history, no questions asked

Safer alternative: --force-with-lease only forces if no one else has pushed since you last fetched

When Is It Appropriate?

Updating your own pull request
Removing sensitive data from history
Working on a feature branch alone

💡 Better Option: Use git push --force-with-lease for a safety check!

git revert: The Safe Alternative

Instead of forcing, use git revert to undo commits safely:

❌ Dangerous Way

# Destroys history
git reset HEAD~1
git push --force

✅ Safe Way

# Creates new commit
git revert HEAD
git push origin main

git reset + --force - Erases the commit from history and forces the remote to match — teammates lose work!

git revert HEAD - Creates a new commit that undoes the changes, preserving the full history

Key difference: revert adds to history; reset + force destroys history

Always prefer revert on shared branches — it's safe for everyone!

Best Practices for Changing History

✅ Only rewrite history on branches you work on alone
✅ Make sure teammates know when you're rewriting history
✅ Never amend/rebase/reset commits that are pushed to shared branches
✅ Use --force-with-lease instead of --force
✅ Don't push after every single commit
✅ If using -f, have a really good reason!

Golden Rule: If working on a team project, check if rewriting history is safe before doing it!

🎮 Git Practice Break!

More practice with advanced techniques!

Your Task:

🌐 Return to learngitbranching.js.org
🎯 Continue with the next challenges
💪 Practice the advanced Git techniques we've covered
🙋 Don't hesitate to ask for help!

Conventional Commits

A standard for commit messages gaining popularity in collaborative projects.

feat: add user authentication
fix: resolve login button bug
docs: update API documentation
style: format code with prettier
refactor: simplify error handling
test: add tests for login flow
chore: update dependencies

feat - New feature for the user

fix - Bug fix

docs / style - Documentation or formatting only (no logic changes)

refactor / test / chore - Internal changes that don't affect users directly

Format: type: description — always lowercase, no period at the end!

💡 Benefit: Makes it crystal clear what each commit does at a glance!

Contributing to Open Source

Most open source projects use a fork workflow where you don't have write access to the main repo.

The Three Repositories:

upstream - Original repo (e.g., TheOdinProject/curriculum)
origin - Your fork on GitHub
local - Your local clone

You can pull from upstream but can only push to origin. To contribute, you push to origin and create a Pull Request to upstream.

Setting Up a Fork

# 1. Fork the repo on GitHub (use the Fork button)

# 2. Clone YOUR fork to your local machine
git clone git@github.com:your_username/curriculum.git
cd curriculum

# 3. Add the original repo as 'upstream'
git remote add upstream git@github.com:TheOdinProject/curriculum.git

# 4. Verify your remotes
git remote -v
# origin    git@github.com:your_username/curriculum.git
# upstream  git@github.com:TheOdinProject/curriculum.git

Step 1: Fork creates your own copy of the repo on GitHub

git clone - Downloads your fork; Git automatically names it origin

git remote add upstream - Links the original repo so you can pull updates from it

git remote -v - Verify you have both origin (your fork) and upstream (original)

You can push to origin but only pull from upstream!

💡 Remember: origin = your fork, upstream = original repo

🎮 Git Practice Break!

Practice collaborative Git workflows!

Your Task:

🌐 Return to learngitbranching.js.org
🎯 Work on collaboration scenarios
💪 Practice fork and pull request workflows
🙋 Ask questions as they come up!

The Contribution Workflow

Create a feature branch: git checkout -b fix-typo
Make your changes and commit them
Fetch updates: git fetch upstream
Update main: git checkout main && git merge upstream/main
Merge main into feature: git checkout fix-typo && git merge main
Push to your fork: git push origin fix-typo
Create Pull Request on GitHub

🎮 Git Practice Break!

Practice the contribution workflow!

Your Task:

🌐 Return to learngitbranching.js.org
🎯 Work through more advanced scenarios
💪 Practice the multi-step workflows we just covered
🙋 Getting stuck is part of learning—ask for help!

Why Merge Main INTO Your Feature Branch?

Seems backwards, right? Here's why it's correct:

Your feature branch is "dirty" - might have conflicts
You want to resolve conflicts BEFORE the PR
Merging feature → main should be clean and conflict-free
So first merge main → feature to handle conflicts
Then your PR will merge cleanly!

💡 Rule: Always merge "senior" branches into "junior" branches to test for conflicts first!

🎮 Final Git Practice!

One last round of practice before we wrap up!

Your Task:

🌐 Return to learngitbranching.js.org
🎯 Complete any remaining challenges
💪 Master the complete Git workflow
🎉 You're becoming a Git expert!

Knowledge Check

Click each card to reveal the answer!

❓ Question 1

How can you amend your last commit?

❓ Question 2

What are some different ways to rewrite history?

Knowledge Check (continued)

❓ Question 3

What does it mean for branches to be pointers?

❓ Question 4

What name is typically given for a Git remote that points to a forked repo's original source?

❓ Question 5

What should you do immediately before merging main into your feature branch?

Today's Takeaways

You Can Now:

✅ Change Git history with amend, rebase, and reset
✅ Squash and split commits for clean history
✅ Understand branches as pointers
✅ Work with remotes and force-push safely
✅ Contribute to open source using fork workflow
✅ Write conventional commits

📅 Next Class: Testing JavaScript with Jest

⚠️ Remember: Never rewrite shared history without good reason!