• 🧑‍💻 GitHub Workflow Guide
• 🔑 Key GitHub Workflows
  • 📘 Reference Repository
  • 👤 Owner / Collaborator
  • 🍴 Fork → 🌿 Branch → 📬 Pull Request
  • 🧪 Practice: Fork and Branch Workflow
• 🔀 Why Resolving Merge Conflicts Matters
• 🎯 Practice: Merge Conflict Resolution
  • Scenario 1: Simple Text Conflict in README.md
  • Scenario 2: Function Logic Conflict in app.js
  • Scenario 3: CSS Styling Conflict in styles.css
  • Scenario 4: Multiple Conflicts in config.js
  • Scenario 5: Package Dependencies Conflict
• 🔗 Real-World Practice Repository
  • 🤝 Team Project
    • 👑 Owner / Scrum Master
    • ✍️ Contributors
• 📊 Summary Table
• ✅ Best Practices

🧑‍💻 GitHub Workflow Guide

GitHub is more than just a place to store code — it’s where real collaboration happens. In our class, you’ll use GitHub to build your portfolio, launch projects, and collaborate on lessons. This guide walks you through the typical use cases.

---

🔑 Key GitHub Workflows

Following are some use cases that we expect students will follow during their coursework.

---

📘 Reference Repository

A read-only public repository used for:

• Cloning to your local machine
• Studying code and structure
• Testing or running locally without contributing back

💡 Example: The pages repository you clone to follow the instructor’s lessons. You do not make changes or submit contributions to this repository.

---

👤 Owner / Collaborator

A repository where you or your team have direct permissions to update files and manage the project.

You can:

• Edit files directly
• Push and merge branches
• Use GitHub Actions to publish your site or project

💡 Example: Your Portfolio repository, created from a student-template repo. You will:

• Become the Owner of your copy
• Update content to reflect your work and progress
• Use GitHub Pages to publish your portfolio website

---

🍴 Fork → 🌿 Branch → 📬 Pull Request

Use this workflow when you want to contribute to someone else’s public repository (like a shared class lesson or team project).

• Fork: Copy the repository to your own GitHub account
• Branch: Make a new branch to isolate your changes
• Pull Request (PR): Submit your branch to the original repository for review and merging

💡 Example: You fork the pages repository, create a branch like john-lesson1-contrib, make updates to a markdown lesson file, and submit a pull request to have your lesson included in the main site.

---

---

🧪 Practice: Fork and Branch Workflow

Now let’s practice the fork and branch workflow with an interactive GitHub simulator.

github.com

upstream-user / learning-merge-conflicts

⑂ Fork

📄 Public repository

A sample repository for learning merge conflicts

github.com

your-username / learning-merge-conflicts

⎇ main ▼

Switch branches/tags

✓ main

Create branch:

3 files

📄 README.md

📄 app.js

📄 styles.css

---

🔀 Why Resolving Merge Conflicts Matters

Understanding merge conflicts is critical for effective collaboration:

• Team Collaboration: Multiple developers often work on the same files simultaneously, leading to conflicting changes that must be reconciled
• Code Integrity: Improper conflict resolution can introduce bugs, break functionality, or lose important changes
• Version Control: Understanding conflicts helps you better understand how Git tracks and merges changes across branches
• Professional Development: Merge conflict resolution is a fundamental skill for any developer working in collaborative environments
• Workflow Efficiency: Quick and accurate conflict resolution keeps the development process moving smoothly without blocking team progress

---

🎯 Practice: Merge Conflict Resolution

Ready to practice? Work through these interactive merge conflict scenarios:

Scenario 1 of 5

Scenario 1: Simple Text Conflict in README.md

Two developers changed the project description simultaneously.

# Project Title <<<<<<< HEAD This project is a web application for managing tasks and todos. ======= This project is a task management system with collaboration features. >>>>>>> feature-branch ## Features - Task creation - User management

Instructions: Remove the conflict markers (<<<<<<<, =======, >>>>>>>) and keep the better description or combine both.

Hint: Both descriptions have useful information. Consider combining them:
"This project is a web application for managing tasks and todos with collaboration features."

Make sure to delete all three conflict markers: <<<<<<< HEAD, =======, and >>>>>>> feature-branch

✓ Conflict resolved correctly!

✗ Conflict markers still present. Remove all <<<, ===, and >>> markers.

Scenario 2: Function Logic Conflict in app.js

Two developers implemented the same function differently.

function calculateTotal(items) { <<<<<<< HEAD let total = 0; for (let i = 0; i < items.length; i++) { total += items[i].price; } return total; ======= return items.reduce((sum, item) => sum + item.price, 0); >>>>>>> feature-branch }

Instructions: Choose the better implementation or combine them.

Hint: The reduce method is more concise and modern JavaScript.
Keep: return items.reduce((sum, item) => sum + item.price, 0);

✓ Conflict resolved correctly!

✗ Conflict markers still present.

Scenario 3: CSS Styling Conflict in styles.css

Different styling approaches for the same element.

.button { <<<<<<< HEAD background-color: #007bff; color: white; padding: 10px 20px; border: none; ======= background: linear-gradient(to right, #0066cc, #0099ff); color: #ffffff; padding: 12px 24px; border: 1px solid #0066cc; border-radius: 4px; >>>>>>> feature-branch cursor: pointer; }

Hint: The feature-branch version has modern styling with gradient and border-radius.

✓ Conflict resolved correctly!

✗ Conflict markers still present.

Scenario 4: Multiple Conflicts in config.js

Multiple sections have conflicts.

const config = { <<<<<<< HEAD apiUrl: 'http://localhost:3000/api', ======= apiUrl: 'https://api.example.com', >>>>>>> feature-branch timeout: 5000, <<<<<<< HEAD retries: 3, logLevel: 'debug' ======= retries: 5, logLevel: 'info', cacheEnabled: true >>>>>>> feature-branch };

Hint: TWO conflicts! Use localhost for dev, keep retries: 3 and logLevel: 'debug', but add cacheEnabled: true

✓ All conflicts resolved!

✗ Conflict markers still present.

Scenario 5: Package Dependencies Conflict

Both branches added different dependencies.

{ "dependencies": { "express": "^4.18.0", <<<<<<< HEAD "mongoose": "^6.0.0", "dotenv": "^16.0.0" ======= "axios": "^1.0.0", "lodash": "^4.17.21" >>>>>>> feature-branch } }

Hint: Keep ALL dependencies in alphabetical order: axios, dotenv, express, lodash, mongoose

✓ Conflict resolved!

✗ Conflict markers still present.

---

🔗 Real-World Practice Repository

Ready to practice with a real GitHub repository?

Click here to access the Merge Conflict Practice Repository →

This repository contains intentional merge conflicts for you to resolve through pull requests, just like in real-world development.

---

🤝 Team Project

When collaborating in groups, you can either:

• All be collaborators in one shared repository, or
• Use a fork-and-pull request model where one student (the Scrum Master) owns the repository and others contribute via PRs.

👑 Owner / Scrum Master

• Creates the team repository (from a template like starter_flask)
• Has direct permissions to merge pull requests and manage settings
• Uses GitHub Actions to deploy the app or site to the instructor and community

✍️ Contributors

• Fork the project repository
• Work on the main or feature branches
• Submit pull requests to the owner’s repository

💡 Example: Your team makes starter_flask from template. One student (Emma) is the Scrum Master and manages the main project repo. Other students create branches like noah-authentication or jessica-homepage, and open PRs to merge their features into the main branch.

---

📊 Summary Table

Use Case	Source Repo	Your Role	Workflow Type	Contributions	Publishing
Portfolio	student	Owner	Direct (own repo)	Direct edits	GitHub Pages
Lesson	pages	Contributor	Fork → PR	Pull requests	Instructor merges
Project	starter_flask	Owner	Clone → Push	Personal project	GitHub Pages/API
Team Project	starter_flask	Scrum/Contributor	Fork or Collab PR	Team coordination	GitHub Actions
Reference Code	pages	Reader	Clone only	No changes	Local only

---

✅ Best Practices

• Commit messages should be meaningful:
  Add login page and route handling
• Never work directly on main unless you’re the sole owner
• Use branches for features, fixes, or lessons
• Pull before you push to avoid merge conflicts
• Use issues, Kanban boards, and PRs to organize group work
• Review PRs and add feedback before merging
• Small and Feature-Specific PRs: Keep pull requests focused on a single feature or fix. This makes reviewing easier and allows for quick rollbacks if something breaks.