🔀 Week 3: Git & GitHub Mastery

Day 4: GitHub Workflows - Pull Requests, Issues, Projects, Code Review

Duration: 5 Hours

📚 Learning Objectives

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

  • Create and manage Pull Requests effectively
  • Use GitHub Issues for tracking work
  • Understand and perform code reviews
  • Use GitHub Projects for project management
  • Apply GitHub collaboration best practices

📖 Core Concepts (2 Hours)

What is a Pull Request?

A Pull Request (PR) is a way to propose changes to a codebase. It allows team members to review, discuss, and approve changes before they're merged into the main branch.

  • Purpose: Code review, discussion, and quality control
  • Branch → Main: PRs merge feature branches into main
  • CI Integration: Automated tests run on PRs
  • Documentation: PRs create a history of changes

Pull Request Lifecycle

PR Lifecycle: 1. Create Feature Branch └── git checkout -b feature/new-feature 2. Make Changes & Commit └── git add . && git commit -m "message" 3. Push to Remote └── git push -u origin feature/new-feature 4. Open Pull Request └── GitHub UI: "Create Pull Request" 5. Code Review ├── Reviewers comment ├── Request changes └── Approve 6. Address Feedback └── Make more commits, push again 7. Merge ├── Squash and merge ├── Merge commit └── Rebase and merge 8. Delete Branch └── Clean up after merge

Creating a Pull Request

# Step 1: Create and push feature branch git checkout -b feature/add-logging # ... make changes ... git add . git commit -m "Add logging functionality" git push -u origin feature/add-logging # Step 2: Go to GitHub # You'll see: "feature/add-logging had recent pushes" # Click "Compare & pull request" # Step 3: Fill out PR form: # - Title: Clear, descriptive (e.g., "Add logging functionality") # - Description: What, why, how # - Reviewers: Assign team members # - Labels: bug, enhancement, documentation, etc. # - Projects: Link to project board # - Milestone: Link to release milestone # Using GitHub CLI (gh) gh pr create --title "Add logging" --body "Description here" gh pr create --fill # Auto-fill from commits

PR Description Template

## Description Brief description of changes made. ## Type of Change - [ ] Bug fix (non-breaking change fixing an issue) - [ ] New feature (non-breaking change adding functionality) - [ ] Breaking change (fix/feature causing existing functionality to change) - [ ] Documentation update ## How Has This Been Tested? - [ ] Unit tests - [ ] Integration tests - [ ] Manual testing ## Checklist - [ ] My code follows the project style guidelines - [ ] I have performed a self-review - [ ] I have commented my code where necessary - [ ] I have updated the documentation - [ ] My changes generate no new warnings - [ ] I have added tests for my changes - [ ] All tests pass locally ## Screenshots (if applicable) Add screenshots here ## Related Issues Fixes #123 Closes #456

Code Review Best Practices

# As a Reviewer: 1. Review Promptly - Review within 24 hours - Don't block teammates 2. Be Constructive ✓ "Consider using a constant here for readability" ✗ "This is wrong" 3. Ask Questions - "What's the reason for this approach?" - "Have we considered...?" 4. Praise Good Work - "Nice refactoring!" - "Great test coverage" 5. Focus on Important Things - Logic errors - Security issues - Performance problems - Not just style nitpicks # Review Comment Types: [Required] - Must fix before merge [Suggestion] - Nice to have [Question] - Need clarification [Nitpick] - Minor style issue # Approve, Request Changes, or Comment - Approve: Ready to merge - Request Changes: Needs work - Comment: Feedback without blocking

GitHub Issues

# Issues track bugs, features, tasks # Creating an Issue: # 1. Go to repo → Issues → New Issue # 2. Use a template if available # 3. Add: # - Clear title # - Detailed description # - Steps to reproduce (for bugs) # - Expected vs actual behavior # - Labels, assignees, project # Issue Template Example (.github/ISSUE_TEMPLATE/bug_report.md): --- name: Bug Report about: Report a bug labels: bug --- ## Bug Description A clear description of the bug. ## Steps to Reproduce 1. Go to '...' 2. Click on '...' 3. See error ## Expected Behavior What should happen. ## Screenshots If applicable. ## Environment - OS: [e.g., Ubuntu 22.04] - Version: [e.g., v1.2.3] # Linking Issues to PRs: # In PR description, use keywords: Fixes #123 # Closes issue when PR merges Closes #123 # Same as fixes Resolves #123 # Same as fixes Relates to #123 # Links without closing

GitHub Projects

# GitHub Projects = Kanban-style project management # Project Board Columns (typical): ┌─────────────┬──────────────┬─────────────┬──────────┐ │ Backlog │ To Do │ In Progress │ Done │ ├─────────────┼──────────────┼─────────────┼──────────┤ │ Issue #5 │ Issue #3 │ Issue #1 │ Issue #4 │ │ Issue #6 │ Issue #7 │ PR #12 │ PR #8 │ │ │ │ │ PR #9 │ └─────────────┴──────────────┴─────────────┴──────────┘ # Automation Options: - Auto-add new issues - Move to "In Progress" when PR opened - Move to "Done" when PR merged - Auto-archive done items # Creating a Project: # 1. Repo → Projects → New Project # 2. Choose template (Basic Kanban, etc.) # 3. Add columns # 4. Add issues/PRs to project # Views: - Table view - Board view - Timeline view - Custom filters # Using GitHub CLI: gh project list gh project item-add 1 --owner @me --url https://github.com/user/repo/issues/1

Branch Protection Rules

# Branch protection ensures quality # Settings → Branches → Add rule # Common Protection Rules: ✓ Require pull request reviews before merging - Required approving reviews: 1-6 - Dismiss stale reviews when new commits pushed - Require review from Code Owners ✓ Require status checks to pass - CI tests must pass - Linting must pass - Security scans must pass ✓ Require conversation resolution - All review comments must be resolved ✓ Require signed commits - GPG verified commits only ✓ Include administrators - Rules apply to everyone ✓ Restrict who can push - Only specific people/teams # CODEOWNERS file (.github/CODEOWNERS): # Automatically request reviews from owners # Default owner for everything * @default-owner # Owners for specific paths /src/api/ @api-team /docs/ @docs-team *.js @frontend-team

Merge Strategies

# Three ways to merge a PR: # 1. Create a Merge Commit # - Preserves all commits # - Creates a merge commit # - Full history visible git merge feature-branch main: A---B---C-------M (merge commit) \ / feature: D---E---F # 2. Squash and Merge # - Combines all commits into one # - Cleaner main branch history # - Loses individual commit history git merge --squash feature-branch main: A---B---C---S (single squashed commit) feature: D---E---F (these become one commit S) # 3. Rebase and Merge # - Replays commits on top of main # - Linear history # - No merge commits git rebase main && git merge --ff-only main: A---B---C---D'---E'---F' (rebased commits) # Which to Use? # - Merge commit: Full history needed # - Squash: Clean history, atomic features # - Rebase: Very clean linear history (careful with shared branches)

GitHub CLI (gh) for Workflow

# Install GitHub CLI # Ubuntu/Debian sudo apt install gh # macOS brew install gh # Authenticate gh auth login # Pull Request Commands gh pr create # Create PR gh pr list # List open PRs gh pr view 123 # View PR #123 gh pr checkout 123 # Checkout PR branch gh pr merge 123 # Merge PR gh pr close 123 # Close PR gh pr review 123 --approve # Approve PR gh pr review 123 --request-changes -b "Please fix..." # Issue Commands gh issue create # Create issue gh issue list # List issues gh issue view 123 # View issue gh issue close 123 # Close issue gh issue edit 123 --add-label "bug" # Repository Commands gh repo clone owner/repo # Clone repo gh repo create # Create new repo gh repo view # View current repo # Workflow Commands gh run list # List workflow runs gh run view # View run details gh run watch # Watch run in real-time

Collaboration Workflows

# Trunk-Based Development (DevOps Preferred) 1. Small, frequent PRs 2. Short-lived branches (hours to days) 3. Feature flags for incomplete work 4. Continuous integration 5. Automated testing on PRs # GitHub Flow 1. Create branch from main 2. Add commits 3. Open Pull Request 4. Discuss and review 5. Deploy and test (from PR) 6. Merge to main # GitFlow (More Complex) main ───────────────────────── \ / release └─────────/ \ / develop ──────────────── \ \ / feature └─────└───/ # Fork and PR (Open Source) 1. Fork repository 2. Clone your fork 3. Create feature branch 4. Push to your fork 5. Open PR to original repo 6. Maintainers review 7. Maintainers merge

🔬 Hands-on Lab (2.5 Hours)

Lab 1: Create Your First Pull Request

  • Create a feature branch
  • Make changes and push
  • Open a Pull Request on GitHub
# Lab 1: Create a PR cd ~/git-practice # Create feature branch git checkout main git pull origin main git checkout -b feature/improve-docs # Make improvements cat >> README.md << 'EOF' ## Quick Start ```bash git clone https://github.com/YOUR-USERNAME/devops-practice.git cd devops-practice ./src/hello.sh ``` ## Project Structure - `src/` - Shell scripts - `docs/` - Documentation - `config.txt` - Configuration EOF git add README.md git commit -m "Improve README with quick start guide" # Push branch git push -u origin feature/improve-docs # Now go to GitHub: # 1. Navigate to your repo # 2. Click "Compare & pull request" # 3. Title: "Improve README with quick start guide" # 4. Description: Add details about your changes # 5. Click "Create pull request"

Lab 2: Work with GitHub Issues

  • Create an issue
  • Link a PR to the issue
  • Close issue via PR merge
# Lab 2: Issues workflow # On GitHub: # Step 1: Create an Issue # 1. Go to repo → Issues → New Issue # 2. Title: "Add health check script" # 3. Description: # "Create a script that checks: # - System uptime # - Disk space # - Memory usage" # 4. Label: enhancement # 5. Submit issue (note the issue number, e.g., #1) # Step 2: Create branch and fix cd ~/git-practice git checkout main git pull origin main git checkout -b feature/health-check # Create the script cat > src/health-check.sh << 'EOF' #!/bin/bash echo "=== System Health Check ===" echo "" echo "Uptime: $(uptime -p)" echo "" echo "Disk Usage:" df -h / | tail -1 | awk '{print " Used: "$3" / "$2" ("$5")"}' echo "" echo "Memory Usage:" free -h | grep Mem | awk '{print " Used: "$3" / "$2}' echo "" echo "Load Average: $(cat /proc/loadavg | cut -d' ' -f1-3)" echo "==========================" EOF chmod +x src/health-check.sh git add src/health-check.sh git commit -m "Add health check script Fixes #1" git push -u origin feature/health-check # Step 3: Create PR that closes the issue # On GitHub: Create PR with description "Fixes #1" # The issue will auto-close when PR is merged!

Lab 3: Code Review Practice

  • Review your own PR (or partner's)
  • Leave comments and suggestions
  • Practice the review workflow
# Lab 3: Code review # On your open PR: # 1. Go to "Files changed" tab # 2. Review each file: # - Click + next to a line to comment # - Add inline comments # - Use suggestion feature: # ```suggestion # echo "Improved line here" # ``` # 3. Leave review: # - Click "Review changes" # - Write summary # - Choose: Comment / Approve / Request changes # - Submit # 4. If changes requested: cd ~/git-practice git checkout feature/health-check # Make requested changes # Edit health-check.sh based on feedback sed -i 's/System Health Check/System Health Report/g' src/health-check.sh git add src/health-check.sh git commit -m "Address review feedback: Update title" git push origin feature/health-check # 5. Request re-review on GitHub # Reviewer approves # Merge the PR!

Lab 4: Set Up GitHub Project

  • Create a project board
  • Add issues and PRs
  • Practice workflow automation
# Lab 4: GitHub Projects # On GitHub: # 1. Create Project # Go to repo → Projects → New Project # Template: "Board" (Kanban) # Name: "DevOps Practice Tasks" # 2. Set up columns: # - Backlog # - Ready # - In Progress # - In Review # - Done # 3. Create multiple issues: # Issue: "Add deployment script" (enhancement) # Issue: "Fix typo in README" (bug) # Issue: "Add CI/CD pipeline" (enhancement) # Issue: "Document all scripts" (documentation) # 4. Add issues to project # Open each issue → Projects → Add to project # 5. Set up automation: # Project settings → Workflows: # - Auto-add items when opened # - Move to In Progress when assigned # - Move to Done when closed # 6. Practice moving cards: # Drag issues between columns # Assign yourself to an issue # Watch automation work! # Using GitHub CLI: gh project list gh issue create --title "New task" --project "DevOps Practice Tasks"

Lab 5: Branch Protection Setup

  • Configure branch protection rules
  • Test the protection
  • Understand the workflow impact
# Lab 5: Branch protection # On GitHub: # 1. Go to Settings → Branches # 2. Add rule for "main" # 3. Enable: # ✓ Require a pull request before merging # - Require approvals: 1 (or 0 for solo practice) # ✓ Require status checks to pass (if you have CI) # ✓ Require conversation resolution # 4. Save changes # 5. Test the protection: cd ~/git-practice git checkout main echo "test" >> README.md git add README.md git commit -m "Direct commit test" git push origin main # Should be rejected! Protection working. # 6. Proper workflow: git checkout -b fix/test-protection echo "test" >> README.md git add README.md git commit -m "Test with proper workflow" git push -u origin fix/test-protection # Create PR on GitHub, get review, merge!

📝 Practice Exercises (30 Minutes)

  1. Create 3 issues for improvements you want to make to your repo
  2. Create a PR that fixes one of your issues (use "Fixes #X")
  3. Review your own PR and leave at least 3 comments
  4. Set up a project board and add all your issues
  5. Install and practice using GitHub CLI (gh)

✅ Day 4 Checklist

  • Can create Pull Requests with good descriptions
  • Understand code review best practices
  • Can create and manage GitHub Issues
  • Know how to link PRs to Issues
  • Can set up and use GitHub Projects
  • Understand branch protection rules
  • Know different merge strategies
  • Familiar with GitHub CLI basics