Post

Weeks 3–4: IDE Workflows and Professional Collaboration

Posted
By Rahul Chandna
21 min read
Weeks 3–4: IDE Workflows and Professional Collaboration

Weeks 3–4: IDE Workflows and Professional Collaboration

Duration: 80 hours (2 weeks × 5 days × 8 hours)
Level: Intermediate (Practical Focus)
Prerequisites: Weeks 1–2 completion
Mode: Full-time immersive training with IDE tools and team collaboration

Weeks 3–4 Overview

Master Git through VSCode (the tool you’ll actually use), pull request workflows, code review, and real team collaboration. Focus on practical skills for day-to-day development work.

##Day 6: Git with VSCode (8 hours)

###Morning Session (9:00 AM - 12:30 PM)

####9:00 - 9:30: Weeks 3–4 Kickoff and VSCode Setup (30 mins)

  • Weeks 1–2 review and feedback
  • Weeks 3–4 expectations: Mastering Git in IDEs
  • Why learn VSCode Git?
  • Most popular code editor (70%+ developer usage)
  • Built-in Git integration (no extensions needed)
  • You’ll use this EVERY DAY at work
  • VSCode installation verification
  • Open Week 1 project in VSCode

####9:30 - 11:00: VSCode Git Basics (1.5 hrs)

VSCode Git Interface:

  • Source Control view (Ctrl+Shift+G / Cmd+Shift+G)
  • File status indicators in Explorer (M, U, A, D, C)
  • Git gutter indicators (colored bars showing changes)
  • Changes view: staged vs unstaged
  • Commit input box and buttons
  • Timeline view (file history)

Basic Operations in VSCode:

  • Stage files: Click + icon or “Stage Changes”
  • Unstage files: Click - icon
  • View diffs: Click on file in Changes view
  • Inline diff view vs side-by-side
  • Commit: Write message and click or Ctrl+Enter
  • Undo last commit: More Actions (…) Undo Last Commit

Lab 6.1: VSCode Basic Workflow (1 hour)

  1. Open your Week 1 project in VSCode
  2. Make changes to 3 different files
  3. View diffs inline and side-by-side
  4. Stage files one by one using UI
  5. Partial staging: Stage specific lines (right-click in diff)
  6. Write commit message and commit
  7. View commit in Timeline view
  8. Make another change, undo the commit, fix, recommit
  9. Repeat until comfortable with Source Control panel

####11:00 - 11:15: Break

####11:15 - 12:30: Branching in VSCode (1.25 hrs)

VSCode Branch Operations:

  • Branch indicator in status bar (bottom-left)
  • Click branch name Quick Pick menu
  • Create branch: Type new name in Quick Pick
  • Switch branches: Select from list
  • Branch management in Source Control view
  • Publish branch to remote
  • Sync Changes button (pull + push)

Branch Visualization:

  • Git Graph extension (recommended but optional)
  • Built-in Git History in Timeline
  • Compare with Branch feature

Lab 6.2: VSCode Branching (45 mins)

  1. Create feature branch via status bar
  2. Make commits on feature branch
  3. Switch to main via status bar
  4. Create another branch
  5. Switch between branches multiple times
  6. View branch changes in Source Control
  7. Merge branch via Command Palette (Ctrl+Shift+P)
  8. Delete merged branch
  9. Practice until branch switching feels natural

####12:30 - 1:30 PM: Lunch Break

###Afternoon Session (1:30 PM - 5:00 PM)

####1:30 - 2:45: Merge Conflicts in VSCode (1.25 hrs)

VSCode Conflict Resolution:

  • Inline conflict markers with action buttons
  • “Accept Current Change” vs “Accept Incoming Change”
  • “Accept Both Changes”
  • “Compare Changes” button
  • 3-way merge editor (VSCode 1.69+)
  • Conflict navigation (Previous/Next Conflict)
  • Mark as Resolved

3-Way Merge Editor(Modern VSCode):

  • Left: Incoming changes (their branch)
  • Right: Current changes (your branch)
  • Bottom: Result (edit freely)
  • Checkboxes to accept/reject changes
  • Much better than inline markers!

Lab 6.3: VSCode Conflict Resolution (1 hour)

  1. Create two branches with conflicting changes
  2. Merge and trigger conflicts
  3. Use inline conflict resolution first:
    • Accept Current
    • Accept Incoming
    • Accept Both
    • Manual edit
  4. Abort merge, try again with 3-way editor
  5. Resolve complex multi-file conflicts
  6. Practice until confident
  7. Vote: VSCode vs Terminal for conflicts?

####2:45 - 3:00: Break

####3:00 - 4:30: VSCode Git Features Deep Dive (1.5 hrs)

Powerful VSCode Git Features:

  • Git Lens extension (optional but popular)
  • Inline blame annotations
  • File history
  • Commit search
  • Diff editor features
  • Word-level diffs
  • Ignore whitespace changes
  • Git commands via Command Palette
  • “Git: Pull”, “Git: Push”, “Git: Fetch”
  • “Git: Checkout to…”
  • “Git: View History”
  • Remote operations
  • Pull/Push from status bar
  • Sync Changes (pull + push)
  • Publish to remote
  • Stashing in VSCode (preview of next topic)
  • Stash changes via More Actions (…)
  • Apply stash from list

Keyboard Shortcuts(Learn these!):

  • Ctrl+Shift+G / Cmd+Shift+G: Open Source Control
  • Ctrl+Enter / Cmd+Enter: Commit staged changes
  • Alt+Enter: Accept current word in IntelliSense

Lab 6.4: VSCode Productivity Practice (45 mins)

  1. Use only keyboard shortcuts for workflow
  2. Install Git Graph extension (optional)
  3. Practice pull change commit push cycle 10 times
  4. Use Git Lens to view file history
  5. Find who changed a specific line (blame)
  6. Compare current file with previous commit
  7. Time yourself: How fast can you commit a change?

####4:30 - 5:00: Git Stash with VSCode (30 mins) Module: 07-advanced-workflows.md (Part 1)

When to Use Stash:

  • Working on feature, need to switch branches NOW
  • Interrupted by urgent bug fix
  • Want to try different approach without committing
  • Not ready to commit but need clean working directory

Stash in VSCode:

  • Source Control More Actions (…) Stash
  • Stash Stash (Include Untracked)
  • View stashes: More Actions Stash Show Stash
  • Apply stash: Select from stash list
  • Pop stash: Apply and remove from list

Terminal Commands(Still useful):

1
2
3
4
5
6
7

git stash                          #Save work
git stash save "descriptive name"  #With description
git stash list                     #View stashes
git stash pop                      #Apply and remove
git stash apply stash@{0}          #Apply specific
git stash drop stash@{0}           #Delete specific
git stash clear                    #Delete all

Lab 6.5: Stash Scenarios - VSCode & Terminal (30 mins)

  1. Start feature work in VSCode
  2. Get interrupted, stash via VSCode UI
  3. Switch branches, do hotfix
  4. Return to feature branch, apply stash via terminal
  5. Stash multiple times with descriptions
  6. List stashes, apply specific one
  7. Practice workflow: stash switch work switch back pop
  8. Do this 5 times until natural

##Day 7: Git Rebase and Advanced Workflows (8 hours)

###Morning Session (9:00 AM - 12:30 PM)

####9:00 - 9:30: Day 6 Recap and Rebase Introduction (30 mins)

  • VSCode workflow review
  • Understanding rebase concepts
  • When and why to use rebase

####9:30 - 11:00: Git Rebase Fundamentals (1.5 hrs) Module: 07-advanced-workflows.md (Part 2)

Understanding Rebase:

  • Rebase vs Merge: What’s the difference?
  • Merge: Creates merge commit, preserves history
  • Rebase: Rewrites history, creates linear timeline
  • When to use rebase:
  • Update feature branch with latest main
  • Clean up local commits before pushing
  • Keep history linear and readable
  • CRITICAL WARNING: Never rebase commits already pushed to shared branches!

Basic Rebase Workflow:

1
2
3
4
5
6
7
8
9
10
11

#Terminal approach
git checkout feature-branch
git rebase main                    #Move feature commits on top of main

#If conflicts occur
#... resolve conflicts in IDE ...
git add .
git rebase --continue              #Continue after resolving

#If things go wrong
git rebase --abort                 #Abort and return to original state

Rebase in VSCode:

  • VSCode: Command Palette Git: Rebase Branch

Lab 7.1: Simple Rebase Practice (1.5 hrs)

  1. Create feature branch
  2. Make 2 commits on feature
  3. Switch to main, make 1 commit
  4. Switch back to feature
  5. Rebase feature onto main (terminal)
  6. View clean linear history with git log --oneline --graph
  7. Try same workflow in VSCode
  8. Practice handling conflicts during rebase
  9. Remember: This is just an introduction - you’ll learn more as needed!

####11:00 - 11:15: Break

####11:15 - 12:30: Rebase Conflict Resolution (1.25 hrs)

Handling Conflicts During Rebase:

  • Understanding conflict markers during rebase
  • Using VSCode to resolve rebase conflicts
  • Continuing vs aborting rebase
  • Best practices for conflict resolution

Lab 7.2: Rebase with Conflicts (1 hour)

  1. Create feature branch with multiple commits
  2. Make conflicting changes on main
  3. Attempt to rebase feature onto main
  4. Resolve conflicts using VSCode
  5. Continue rebase to completion
  6. Practice abort and retry scenarios

####12:30 - 1:30 PM: Lunch Break

###Afternoon Session (1:30 PM - 5:00 PM)

####1:30 - 3:00: Interactive Rebase Basics (1.5 hrs)

Interactive Rebase Overview:

  • What is interactive rebase?
  • Common use cases:
  • Squashing commits
  • Reordering commits
  • Editing commit messages
  • Dropping commits
  • When to use interactive rebase

Interactive Rebase Commands:

1
2

git rebase -i HEAD~3         #Rebase last 3 commits
git rebase -i main           #Rebase all commits since main

Rebase Actions:

  • pick: Keep commit as-is
  • squash: Combine with previous commit
  • reword: Edit commit message
  • drop: Remove commit

Lab 7.3: Interactive Rebase Practice (1 hour)

  1. Create branch with 5 small commits
  2. Use interactive rebase to:
    • Squash related commits
    • Reword unclear commit messages
    • Reorder commits logically
  3. Clean up commit history before “pushing”
  4. Practice different rebase scenarios

####3:00 - 3:15: Break

####3:15 - 5:00: Advanced Git Workflows (1.75 hrs)

Cherry-Pick Basics:

  • What is cherry-pick?
  • When to use it
  • Basic cherry-pick workflow

Git Reflog:

  • Understanding reflog
  • Recovering lost commits
  • Undoing mistakes with reflog

Lab 7.4: Cherry-Pick and Reflog Practice (1.5 hours)

Part A — Cherry-Pick (45 mins):

  1. Create branch feature-api with 3 commits:
    • Commit 1: “Start API refactor” — create api.py
    • Commit 2: “Fix null pointer crash in user lookup” — add null check
    • Commit 3: “Add rate limiting (incomplete)” — WIP code
  2. Note the hash of Commit 2 (the bug fix only)
  3. Switch to main
  4. Cherry-pick just the bug fix: git cherry-pick <hash>
  5. Verify main has the fix but NOT the WIP code
  6. Intentionally create a cherry-pick conflict and resolve it

Part B — Reflog Recovery (45 mins):

  1. Create a branch with 2 meaningful commits
  2. Run git reset --hard HEAD~2 — commits appear gone
  3. Run git reflog — find the lost commit hash
  4. Recover with git reset --hard <hash> — commits restored
  5. Create a branch, commit to it, then force-delete the branch
  6. Use git reflog to find the commit and recreate the branch
  7. Discuss: what situations are NOT recoverable with reflog?

Day 7 Homework(Optional):

  • Read about interactive rebase advanced features
  • Research: When teams use rebase vs merge strategies
  • Practice rebase workflows with personal projects

##Day 8: Pull Requests and Code Review (8 hours)

###Morning Session (9:00 AM - 12:30 PM)

####9:00 - 9:30: Day 7 Recap and PR Introduction (30 mins)

  • Rebase and advanced workflows review
  • Quick rebase recap
  • Why Pull Requests matter
  • THE MOST IMPORTANT SKILL: You’ll do this EVERY SINGLE DAY
  • PR = Code Review = Quality + Learning

####9:30 - 11:00: Creating Effective Pull Requests (1.5 hrs)

Anatomy of a Good PR:

  • Clear, descriptive title
  • Detailed description (what, why, how)
  • Screenshots for UI changes
  • Linking to issues/tickets
  • Small, focused changes (not 1000+ lines)
  • Self-review before requesting review

PR Workflow:

  1. Create feature branch
  2. Make changes and commit
  3. Push branch to remote
  4. Create PR on GitHub/GitLab
  5. Request reviewers
  6. Address feedback
  7. Get approval
  8. Merge (squash vs merge vs rebase)

Lab 8.1: Your First Real PR (1 hour)

  1. Fork a practice repository
  2. Find issue labeled “good-first-issue”
  3. Create feature branch
  4. Fix the issue (small change)
  5. Push to your fork
  6. Create PR with detailed description:
    • What issue you’re fixing
    • How you fixed it
    • Testing you did
    • Screenshots if applicable
  7. Request review from instructor/peer

####11:00 - 11:15: Break

####11:15 - 12:30: Code Review Skills (1.25 hrs)

As PR Author:

  • How to prepare code for review
  • Self-review checklist
  • Responding to feedback professionally
  • When to push back (respectfully)
  • Marking conversations as resolved

As Code Reviewer:

  • What to look for (bugs, readability, standards)
  • How to give constructive feedback
  • Praising good work
  • Requesting changes vs approving
  • Being specific, not vague
  • Asking questions, not making demands

Review Comment Examples: Bad: “This is wrong” Good: “This might cause an issue when X happens. Consider using Y instead. What do you think?”

Bad: “Change this” Good: “We typically use const instead of let for values that don’t change. This helps prevent bugs.”

Lab 8.2: Peer Code Review Practice (45 mins)

  • Pair up with classmate
  • Review each other’s Day 6 or 7 projects
  • Leave 5 meaningful comments each:
  • At least 2 suggestions for improvement
  • At least 1 question
  • At least 1 positive comment
  • Respond to feedback professionally
  • Make requested changes
  • Get approval

####12:30 - 1:30 PM: Lunch Break

###Afternoon Session (1:30 PM - 5:00 PM)

####1:30 - 2:30: GitHub/GitLab PR Features (1 hour)

Platform Features You’ll Use Daily:

  • Draft PRs (work in progress)
  • PR templates
  • Linking issues with keywords (Fixes #123)
  • Labels and milestones
  • Requesting specific reviewers
  • Required approvals before merge
  • Status checks (CI/CD passing)
  • Merge strategies:
  • Squash and merge(most common - clean history)
  • Merge commit (keeps all commits)
  • Rebase and merge (linear history)

Branch Protection Rules:

  • Require PR before merging to main
  • Require approvals (usually 1-2)
  • Require passing CI checks
  • No direct commits to main

Lab 8.3: Repository Setup (45 mins)

  1. Create a new repository
  2. Set up branch protection on main:
    • Require PR
    • Require 1 approval
    • Require status checks to pass (simulate)
  3. Create PR template
  4. Try to push directly to main (should fail!)
  5. Create PR properly and merge

####2:30 - 2:45: Break

####2:45 - 5:00: Day 8 Project — PR Workflow Marathon (2.25 hrs)

Your Task: Fix 5 issues on a practice repository via the full PR workflow.

Issues to Fix(labeled in repository):

  1. Bug: Broken navigation link — file a bug fix PR
  2. Feature: Add dark mode toggle — file a feature PR
  3. Docs: Update README with setup instructions — file a docs PR
  4. Refactor: Remove duplicate CSS rules — file a refactor PR
  5. Test: Add input validation to a form — file a PR with a test

Requirements for each PR:

  • Feature branch named appropriately (e.g. bugfix/nav-link, feature/dark-mode)
  • Descriptive PR title and body (what, why, how to test)
  • Self-reviewed before requesting review
  • At least one round of feedback given and addressed
  • Merged using squash-and-merge

Deliverables:

  • 5 merged PRs visible in the repository
  • LESSONS-LEARNED.md: what made a PR easy or hard to review

##Day 9: Team Collaboration and Real-World Scenarios (8 hours)

###Morning Session (9:00 AM - 12:30 PM)

####9:00 - 9:30: Day 8 Recap and Team Intro (30 mins)

  • Share PR workflow experiences from Day 8
  • Code review learnings and common mistakes
  • Preview of today: real team simulation and common problems

####9:30 - 11:00: Team Workflow Patterns (1.5 hrs)

Simple Workflows (Most Companies Use These):

1. GitHub Flow(Simple, most common):

  • One main branch
  • Create feature branch
  • Open PR
  • Review and merge
  • Deploy from main

2. Feature Branch Workflow:

  • Protected main branch
  • Feature branches off main
  • PR for all changes
  • Delete branch after merge

3. Trunk-Based Development:

  • Very short-lived branches
  • Merge to main frequently (multiple times/day)
  • Use feature flags for incomplete work

When to Use What:

  • Small teams / Startups GitHub Flow
  • Medium teams Feature Branch Workflow
  • Large teams with CI/CD Trunk-Based

Lab 9.1: Workflow Practice (45 mins)

  1. Set up repository for GitHub Flow
  2. Practice feature branch workflow
  3. Simulate team with 3 developers
  4. Each creates feature, PRs, reviews
  5. Experience the complete cycle

####11:00 - 11:15: Break

####11:15 - 12:30: Common Real-World Scenarios (1.25 hrs)

Scenario 1: “Update Your Branch”

  • Main has new commits after you created branch
  • Your PR shows conflicts
  • Solution: Update branch from UI or terminal
  • VSCode: Update Branch button
  • Terminal: git checkout main && git pull && git checkout feature && git merge main

Scenario 2: “Oops, Wrong Branch”

  • Made commits on main instead of feature branch
  • Solution: Create branch from current state, reset main

Scenario 3: “Need to Fix Something in My PR”

  • PR is open, reviewer found issues
  • Solution: Make changes, commit, push to same branch (PR updates automatically)

Scenario 4: “Merge Conflicts During PR”

  • Someone else merged first, now your PR conflicts
  • Solution: Update branch, resolve conflicts, push

Scenario 5: “Forgot to Pull Before Starting”

  • Your branch is behind
  • Solution: Pull (or fetch + merge/rebase) before creating PR

Lab 9.2: Scenario Practice (45 mins)

  • Work through all 5 scenarios
  • Use IDE tools (not just terminal)
  • Document your solution for each
  • Share with class what worked

####12:30 - 1:30 PM: Lunch Break

###Afternoon Session (1:30 PM - 5:00 PM)

####1:30 - 3:00: Team Project Simulation (1.5 hrs)

Project 9.1: Mini Startup Team

Team Formation: Groups of 3-4 students

Scenario: You’re a small startup team building a product

Roles(rotate every 30 mins):

  • Product Owner (creates issues, reviews PRs)
  • Developer 1
  • Developer 2
  • Developer 3

Project: Build a simple “Team Dashboard”

1
2
3
4
5
6

team-dashboard/
 index.html (landing page)
 dashboard.html (main dashboard)
 team.html (team members page)
 styles.css
 README.md

Round 1 (30 mins)- Initial Setup:

  • Product Owner creates repo, adds issues
  • Developers claim issues, create branches
  • Each submits 1 PR
  • Product Owner reviews and approves

Round 2 (30 mins)- Feature Development:

  • Rotate roles
  • New features assigned
  • Create PRs
  • Peer review (not Product Owner)
  • Intentionally create 1 conflict and resolve

Round 3 (30 mins)- Final Polish:

  • Rotate roles again
  • Bug fixes and improvements
  • All PRs must pass review
  • Practice giving constructive feedback

Requirements:

  • Minimum 9 PRs (3 per person)
  • All via proper workflow
  • At least 1 conflict resolved as team
  • Use project board to track work
  • Branch protection enabled
  • All code reviewed before merge

####3:00 - 3:15: Break

####3:15 - 4:30: When Things Go Wrong (1.25 hrs)

Common Problems and How to Ask for Help:

Problem 1: “I Can’t Push to Main”

  • Why: Branch protection
  • Solution: Create PR instead
  • Key: Read the error message!

Problem 2: “My IDE Shows Red, I Don’t Know What Happened”

  • Why: Merge conflict or compilation error
  • Solution: Check Source Control panel, look for conflict markers
  • Key: One step at a time

Problem 3: “I Lost My Changes”

  • Why: Hard reset or checkout without committing
  • Solution: Check reflog (terminal)
  • Key: Commit often!

Problem 4: “Someone Else Changed the Same File”

  • Why: Parallel work
  • Solution: Merge or rebase to incorporate their changes
  • Key: Communication and coordination

Problem 5: “I Don’t Know What Command to Use”

  • Why: Trying to remember everything
  • Solution: Use your cheat sheet, check docs, or use IDE
  • Key: Focus on concepts, not memorizing commands

How to Ask for Help:

  1. Explain what you were trying to do
  2. Show what you tried
  3. Share the error message
  4. Describe current state: git status, git log --oneline
  5. Be specific about what’s confusing

Lab 9.3: Troubleshooting Practice (1 hour)

  • Instructor creates 5 common problem scenarios
  • Students diagnose and fix
  • Share solutions with class
  • Document “cheat sheet” for common fixes

####4:30 - 5:00: Day 9 Wrap-up (30 mins)

Team Retro: Each group presents:

  • What worked well in team workflow
  • What was challenging
  • How they resolved conflicts
  • One tip for future teams

Individual Reflection: Write REAL-WORLD-READINESS.md:

  • What workflow your company likely uses
  • How you’ll handle common scenarios
  • Your confidence level with Git now
  • Questions still remaining

##Day 10: Capstone Project and Final Assessment (8 hours)

###Morning Session (9:00 AM - 12:30 PM)

####9:00 - 10:00: Weeks 3–4 Comprehensive Review (1 hour)

  • Advanced commands review
  • Workflow patterns recap
  • Best practices checklist
  • Common mistakes to avoid
  • Real-world tips
  • Career advice for using Git professionally

####10:00 - 10:15: Break

####10:15 - 12:30: Final Written Assessment (2.25 hrs)

Part A: Advanced Concepts(45 mins)

  • VSCode Git features
  • Stash vs commit scenarios
  • Basic rebase vs merge decision trees
  • Conflict resolution strategies (IDE tools)
  • Workflow selection (GitHub Flow, Feature Branch)

Part B: Command Mastery(30 mins)

  • Write commands for complex scenarios
  • Explain command flags and options
  • Chain commands effectively

Part C: Real-World Scenarios(45 mins)

  • Case studies from actual development work
  • Troubleshooting exercises
  • Decision-making scenarios (merge vs rebase, squash vs keep commits)
  • Team collaboration challenges
  • When to ask for help vs solve independently

####12:30 - 1:30 PM: Lunch Break

###Afternoon Session (1:30 PM - 5:00 PM)

####1:30 - 3:00: Final Capstone Project - Introduction and Setup (1.5 hrs)

Project 10.1: Full-Stack Note-Taking Application

Requirements:

  • Build a complete note-taking web application
  • Use professional Git workflow throughout
  • Demonstrate all Week 2 skills

Git Workflow Requirements:

  1. Use Gitflow or Trunk-Based Development (your choice)
  2. Minimum 30 meaningful commits
  3. 6+ feature branches merged via PRs
  4. At least 1 intentional conflict resolved
  5. Clean, rebased commit history
  6. Semantic versioning with tags
  7. Branch protection rules enabled

Technical Requirements:

  • Frontend: HTML, CSS, JavaScript (vanilla or framework)
  • Backend: Node.js, Python Flask, or similar
  • Database: JSON file storage or simple DB
  • Features:
  • Create, edit, delete notes
  • Search functionality
  • Categories/tags
  • Responsive design

Documentation Requirements:

  • README.md with setup instructions
  • CONTRIBUTING.md with workflow guide
  • CHANGELOG.md tracking versions
  • API documentation (if applicable)
  • Issue templates
  • PR template

Advanced Git Demonstrations(Optional bonus points):

  • Use stash during development
  • Basic rebase to keep history clean
  • Demonstrate IDE Git workflows in VSCode
  • (Bonus): Cherry-pick a hotfix from one branch to another
  • (Bonus): Use reflog to recover from simulated mistake
  • (Bonus): Interactive rebase to clean history before final submission

####3:00 - 3:15: Break

####3:15 - 4:30: Final Capstone Project - Development (1.25 hrs)

Project Work:

  • Set up repository with proper structure
  • Create initial project scaffolding
  • Implement features following Git workflow
  • Create PRs and self-review
  • Document progress

Evaluation Criteria:

  • Code quality (25%)
  • Git workflow proficiency (35%)
  • Documentation completeness (20%)
  • Feature completeness (20%) ####4:30 - 5:00: Course Completion (30 mins)

Activities:

  • Project demonstrations (volunteers)
  • Certificate distribution
  • Final feedback collection
  • Course evaluation
  • Next steps and continued learning paths
  • Networking and connections

Weeks 3–4 Learning Outcomes

By end of Weeks 3–4, you should be able to:

IDE Mastery- Use Git effectively in VSCode (Day 6)

  • Understand Git rebase and advanced workflows (Day 7)
  • Perform all Git operations without terminal
  • Resolve conflicts using IDE merge tools
  • Navigate between terminal and IDE workflows seamlessly
  • Choose appropriate tool for the task

Essential Advanced Operations- Use stash for work-in-progress management

  • Understand basic rebase for clean history
  • Know when to rebase vs merge
  • Apply stash/rebase in both terminal and IDE

Professional Workflows(THE MOST IMPORTANT!)

  • Create and manage pull requests
  • Conduct professional code reviews
  • Give and receive constructive feedback
  • Implement GitHub Flow or Feature Branch Workflow
  • Use branch protection and merge strategies
  • Follow team conventions

Team Collaboration- Work effectively in team repositories

  • Resolve conflicts collaboratively
  • Review and approve code professionally
  • Handle common real-world scenarios
  • Communicate effectively with teammates
  • Follow contribution guidelines

Troubleshooting- Diagnose and fix common Git problems

  • Undo mistakes safely
  • Handle merge conflicts confidently
  • Know when to ask for help
  • Use documentation effectively

Professional Practices- Write clear, conventional commit messages

  • Keep commits focused and logical
  • Test before committing
  • Self-review code before requesting review
  • Respond professionally to feedback

Post-Course Topics (Beyond Weeks 3–4)

These topics are not covered in Week 2but are worth exploring once you are comfortable with everything taught. Learn them when you encounter a real need.

Git Bisect- Binary search through commits to find which one introduced a bug

  • Learn when: Debugging a regression across a long commit history

Git Hooks- Scripts that run automatically on Git events (pre-commit, post-push, etc.)

  • Learn when: You want to enforce code quality checks or auto-format code before commits

Git Submodules & Subtrees- Managing one repository inside another

  • Learn when: Working with complex multi-repo or monorepo projects

Git LFS (Large File Storage)- Storing large binary files (images, videos, datasets) outside the Git history

  • Learn when: Your repository contains large files that slow down cloning

GitHub Actions / GitLab CI- Automating tests, linting, and deployments triggered by Git events

  • Learn when: Your team wants automated quality checks on every PR

Philosophy: The topics taught in Weeks 3–4 cover 95% of what you will use daily. The above are specialised tools you will reach for only in specific situations.

##Post-Course Continuing Education

Recommended Next Steps:

  1. Contribute to Open Source
    • Find beginner-friendly projects
    • Start with documentation improvements
    • Progress to code contributions
  2. Advanced Topics to Explore(When Ready)
    • Git submodules and subtrees
    • Git LFS for large files
    • Git workflows in monorepos
    • GitHub Actions / GitLab CI
    • Git hooks and automation
    • Interactive rebase mastery
    • Advanced conflict resolution strategies
  3. Daily Practice
    • Use Git for all personal projects
    • Contribute to team repositories
    • Experiment with different workflows
    • Teach Git to others
  4. Resources

##Final Assessment Criteria

Pass Requirements:

  • Complete all Week 2 labs
  • Written assessment score 75%+
  • Team project participation
  • Final capstone project submission
  • Demonstrate mastery in:
  • Advanced Git operations
  • Pull request workflow
  • Team collaboration
  • Problem troubleshooting
  • Professional practices

Grading Breakdown:

  • Daily Labs: 20%
  • Team Project (Day 9): 15%
  • Written Assessment: 20%
  • Final Capstone: 35%
  • Code Review & Participation: 10%

Excellence Criteria(for distinction):

  • Innovative use of Git features
  • Exceptional documentation
  • Leadership in team project
  • Helping peers
  • Going beyond requirements

##Success Metrics

You’re ready for professional development when you can:

  • Work confidently with Git in terminal
  • Create feature branches without fear
  • Resolve merge conflicts independently
  • Participate in PR workflows
  • Recover from mistakes
  • Collaborate effectively in teams
  • Follow industry best practices
  • Troubleshoot Git issues

Congratulations on completing the comprehensive 4-week Git training program!

Previous: WEEK-1-CURRICULUM.md - Weeks 1–2: Fundamentals and Branching

Graduate Training, Git
Graduate Training
This post is licensed under CC BY 4.0 by the author.