0-Overview

🧭 Topic: Advanced Git

Quick Overview :

This topic covers professional Git workflows including branching strategies, commit practices, merging techniques, and conflict resolution. It provides practical skills for managing code in team environments with hands-on practice in resolving various types of merge conflicts.

---

📌 Covered in This Topic

Branching Strategy

Main vs Develop Branches

• Main Branch: Stable and production-ready code; always deployable; reflects official release state
• Develop Branch: Integration branch for ongoing work; contains latest completed features; acts as staging area before release

Feature & Bug-Fix Branches

• Feature Branches: Created for new features; isolated development; merged after completion
  • Example: git checkout -b feature/user-profile
• Bug-Fix Branches: Used to fix defects; focused on specific issues; merged after testing
  • Example: git checkout -b bugfix/login-error

Branch Lifespan & Synchronization

• Short-Lived Branches: Exist for short periods; merged and deleted quickly
• Long-Lived Branches: Kept for extended periods (main, develop)
• Keep Synchronized: Regularly pull latest changes; update feature branches frequently; reduce merge conflicts before they happen

Branch Naming Conventions

Pattern	Purpose	Example
feature/	New functionality	feature/user-profile
bugfix/	Fixing a bug	bugfix/login-error
hotfix/	Urgent production fix	hotfix/security-patch
refactor/	Improvement, no behavior change	refactor/auth-service
docs/	Documentation updates	docs/api-documentation

Commit Practices

Writing Meaningful Commit Messages

• Clearly describe the change being made
• Use concise and specific wording
• Explain the purpose when needed
• Follow a consistent format

Good Examples: “Add user authentication”, “Fix login validation bug” Avoid: “Update code”, “Fix stuff”

Commit Best Practices

• Small & Focused: Keep commits small; include only related changes; easier to review, test, and rollback
• One Logical Change: Each commit has one purpose; avoid mixing unrelated changes; easier-to-read history
• Commit Frequently: Commit changes regularly; save progress incrementally; reduce risk of losing work

Conventional Commit Format

<type>: <short description>

Examples:

• feat: add profile page
• fix: resolve login bug
• docs: update install guide
• refactor: simplify payments

Common Commit Types:

Type	Purpose
feat	New feature
fix	Bug fix
docs	Documentation changes
refactor	Code improvement, no behavior change
test	Add or update tests
style	Formatting and style changes
chore	Maintenance tasks
perf	Performance improvements

Commit History

Viewing Commit History

• git log: Review previous commits; identify who made changes; inspect messages and timestamps
• git log --oneline: Quickly browse commit history; find commit hashes faster; useful for large repositories

Visualizing Branch History

• git log --graph: Visualizes branch & merge history; analyze branch structure; track feature-branch integration; debug complex histories
• Key Concepts: Every commit has a parent commit; branches are pointers to commits; merges connect different histories; history forms a directed graph

Merging Branches

Git Merge: Combining Histories

• Combines changes from one branch into another
• Preserves history of both branches
• Usually merges feature branches into develop

How Merging Works:

1. Find common ancestor
2. Compare histories
3. Combine the changes
4. Create unified history

Possible Outcomes:

• Fast-forward merge
• Merge commit
• Merge conflict

Fast-Forward vs Merge Commit

• Fast-Forward Merge: No divergence between branches; branch pointer simply moves forward; no extra merge commit; cleaner, simpler, linear history
• Merge Commit: Used when branches diverge; creates a new merge commit; preserves branch structure; makes feature integration visible

Reset & Revert

Git Reset vs Git Revert

• Git Reset: Moves HEAD to a previous commit; can remove commits from history; useful for fixing local mistakes
• Git Revert: Creates a new commit that undoes changes; does NOT delete history; safe for shared branches

Git Reset Modes

• --soft: Removes commit only; keeps changes staged; working directory unchanged
  • Use when: fixing a commit message
• --mixed (default): Removes commit from history; unstages changes; working directory unchanged
  • Use when: reorganizing commits
• --hard: Removes commit completely; deletes staged & working changes; dangerous if used incorrectly
  • Data may be lost - use carefully

Choosing the Safe Path

Reset	Revert
Rewrites history	Preserves history
Deletes commits	Creates a new commit
Best for local use	Best for team-safe use
Risky on shared branches	Safe on shared branches

Key Rule: If already pushed → use revert; if not pushed → reset is OK.

Git Stash

What & Why

• Temporarily saves uncommitted changes
• Keeps working directory clean
• Avoids creating temporary commits
• Lets you restore changes later

Common Use Case:

1. Working on a feature
2. Urgent bug appears
3. Stash current changes
4. Switch branch & fix bug

Restoring Stashed Work

• git stash apply: Restores latest saved changes; stash entry is kept for reuse
• git stash pop: Restores changes and removes them; continue working where you left off

Conflict Resolution Types

Modify/Modify Conflicts

• Two developers modify the same lines of code in different branches
• Git can’t automatically decide which change to keep
• Must manually resolve by choosing one version or combining both

Modify/Delete Conflicts

• One developer deletes a file; another modifies it
• Git detects the conflict and asks whether to keep the file or delete it

Rename Conflicts

• One developer renames a method/class; another modifies the old version
• Git may interpret these as different operations, causing confusion

---

📑 Slides & Materials

• 🧑‍🏫 TA Workshop Slides (PDF)

---

🛠️ Workshop

💬 Workshop: Advanced Git & GitHub

• 📂 WS-11-Advanced-Git
• Objective: Practice resolving merge conflicts through simulated parallel development
• Prerequisites: Git, GitHub account, Java SDK 25, Maven
• Project Structure: Calculator.java (interface), BasicCalculator.java (implementation), MathHelper.java (utilities), ReportGenerator.java (produces output)

Task 1 – Refactoring Conflict

• Scenario: Developer A renames method; Developer B modifies old version
• Steps:
  1. Fork & clone repository, create develop branch
  2. Create two feature branches: feature/refactor-multiply and feature/change-multiply
  3. From feature/refactor-multiply, rename “multiply” to “product” everywhere
  4. Merge feature/refactor-multiply into develop
  5. From feature/change-multiply, change body of multiply method
  6. Merge feature/change-multiply into develop (CONFLICT)
  7. Resolve conflict: keep rename, apply new logic

Task 2 – Deletion Conflict

• Scenario: Developer A deletes Calculator interface; Developer B modifies it
• Steps:
  1. Create two branches: feature/remove-calculator and feature/add-method-to-interface
  2. From feature/remove-calculator, delete Calculator.java
  3. Merge feature/remove-calculator into develop
  4. From feature/add-method-to-interface, add calculateArea() method to Calculator
  5. Merge feature/add-method-to-interface into develop (CONFLICT)
  6. Resolve conflict: Restore interface with new method

Deliverable

• Push all branches with merge commits
• Show output of: git log --oneline --graph --all --decorate

Note: Workshop is optional with bonus points

---

🔗 Repository Links

Repository	Description
📂 WS-11-Advanced-Git	Workshop: Practice resolving merge conflicts (optional, bonus points)

---

🌐 Additional Resources

• Git Documentation
• Git Branching Strategies
• Conventional Commits
• Git Merge vs Rebase
• Atlassian Git Tutorial

---

⏩ Navigation

• ⬅️ Previous Topic: Database (2 Sessions)
• ➡️ Next Topic: Final Project

---

Tip :

Advanced Git skills are essential for professional development. Practice the “always pull before you push” habit to avoid conflicts. When conflicts arise, don’t panic – Git tells you exactly which files are conflicted. Use git status and git diff to understand what changed. Remember the golden rule: never rebase or reset a shared branch – use revert for commits that have already been pushed. The workshop provides excellent hands-on practice with the most common conflict types you’ll encounter in real teams!