🔀
KWK x Codex: AI BuildLab 2026 | Participant HQ/🔀Lesson 3: Git, GitHub & Your Team Workflow

Lesson 3: Git, GitHub & Your Team Workflow

In software development, we rarely work alone. We work on teams. We need a way to collaborate on the same codebase without overwriting each other's work. The tools that make this possible are Git and GitHub. Let's learn how to use them!

💾 What is Git?

Git is a version control system. Think of it like the "track changes" feature in Google Docs, but for code. It is a program that runs on your computer and keeps a full history of every change you make to your project. This allows you to:
  • See who changed what, and when.
  • Go back to a previous version of your code if you make a mistake.
  • Work on a new feature without affecting the main codebase.

🌐 What is GitHub?

GitHub is a website and cloud-based service that helps developers store and manage their code using Git. It is a place to host your Git repositories online. GitHub adds a social and collaboration layer on top of Git, allowing you to:
  • Share your code with others.
  • Work on projects with a team.
  • Review code and discuss changes before they are merged into the main project.

🔄 The core workflow: Find an issue, get up to date, branch, commit, push, PR

For the BuildLab, you will not work directly on the main project repository. Instead, you will work on your own copy, and then propose your changes back to the team's project. This is a common and safe way to work.

✅ Step 1: Find and assign your first issue

Before you write any code, you need to know what to work on. Your team organizes work in a GitHub Project board using ‘issues’ (can also be called ‘tickets’)
Despite the name, issues aren’t always problems. They can represent new features, tasks, or improvements to the project.
  1. Go to your team's GitHub repository and click the "Issue" tab.
  2. Find the ticket that is assigned to your “Person” for the week – Person A, B, or C. Ask your facilitator if you’re not sure!
  3. Click on the issue to open it, and in the right-hand sidebar, assign it to yourself. This tells your team you're working on it!
  4. Drag the ticket to the "In Progress" column.

✅ Step 2: Make sure your code is up to date

Before you start a new ticket, you want to make sure you have the latest version of the project. Your teammates might have merged changes since the last time you worked on it.
In your terminal, make sure you're on the main branch and pull the latest changes:
git checkout main
git pull
This grabs any new code your teammates have merged. Always do this before starting a new ticket.

✅ Step 3: Create a new branch

Before you start writing any code, you should create a new branch. A branch is like a separate timeline of your project. This allows you to work on a new feature without affecting the main main branch. It's a best practice to include the issue number in your branch name.
In your terminal, run:
git checkout -b your-initials/issue-1-feature-name
# Example: git checkout -b js/issue-1-display-posts
This creates a new branch and switches you to it. Now you're ready to code! 🎉

✅ Step 4: Commit and push your changes

As you work, you should save your changes to Git. This is a two-step process: commit and push.
  1. Commit: A commit is a snapshot of your code at a specific point in time. Make small, frequent commits.
    2. # Add all your changed files to the staging area
git add .

# Commit them with a descriptive message
git commit -m "feat: add a title to the homepage"
  2. Push: Pushing sends your committed changes from your local computer up to your forked repository on GitHub.
    3. git push -u origin your-branch-name

✅ Step 5: Open a Pull Request (PR)

A Pull Request (PR) is how you propose your changes to the team's main repository. It's a request to "pull" your changes from your branch into the main branch of the team's project.
  1. Go to your team's repository on GitHub.
  2. You should see a yellow banner that says "your-branch-name had recent pushes." Click the "Compare & pull request" button.
  3. Give your PR a clear title and a description of the changes you made.
  4. In the description, link the issue your PR is for by typing "Closes #" and the issue number (e.g., "Closes #1"). This will automatically close the issue when your PR is merged.
  5. Click "Create pull request."
Your team can now review your code, leave comments, and once it's approved, it can be merged into the main project!
How to self-validate: Go to your team's main GitHub repo and click the "Pull requests" tab. Do you see your PR listed there? If so, you've successfully proposed your changes! Click into it and make sure the "Files changed" tab shows exactly what you edited.
This workflow might seem like a lot of steps at first, but it will quickly become second nature. It’s the standard way that software teams all over the world collaborate, and it’s a crucial skill for any developer. You’ve got this!

📘 Reference: Troubleshooting Git Problems

You probably won’t need this section during Week 1. But when you’re deep into Weeks 2–4 and if something goes sideways with Git, come back here for reference. ⤵️

Pro Tip: Pull from main regularly

Here’s a scenario: you’re working on your ticket on your branch. Meanwhile, a teammate finishes their ticket and merges it into main. Now your branch is behind: you’re building on top of old code, and the longer you wait, the more likely you’ll hit a conflict when you try to merge.
The fix is simple. Periodically (and especially before opening a PR), pull the latest main into your branch:
git pull origin main
This grabs your teammate’s merged changes and folds them into your branch. If there are no conflicts, Git handles it automatically and you keep working. If there are conflicts, see the next section.
When to do this:
  • Whenever a teammate’s PR gets merged into main (you’ll often see this in Slack or GitHub notifications)
  • Before you open your own PR
  • If you’ve been working on a ticket for more than a couple days
Make this a habit and you’ll avoid most merge pain before it starts.

Resolving merge conflicts (with AI help)

A merge conflict happens when two people change the same lines in the same file. Git doesn’t know which version to keep, so it asks you to decide. This is normal and not scary. It means your team is actively building things!
When a conflict happens, Git will mark the conflicting lines in the file like this:
<<<<<<< HEAD
// your version of the code
=======
// your teammate's version of the code
>>>>>>> main
Your job is to decide what the final version should look like: your code, their code, or a combination of both. Then delete the <<<<<<<, =======, and >>>>>>> markers.
This is a perfect moment to use AI. Open the file with the conflict and ask Codex:
“I have a merge conflict in this file. My changes are between <<<<<<< HEAD and =======. My teammate’s changes are between ======= and >>>>>>> main. Can you help me combine both changes correctly?”
Codex can read both versions and suggest a merged result that keeps everyone’s work. But a friendly reminder to always review what it gives you: Codex doesn’t know which feature matters more to your team. You do.
After resolving all the conflicts in the file:
git add .
git commit -m "merge: resolve conflict with main"
To avoid that, it’s a good habit to regularly bring your branch up to date with main.
There are two common ways to do this:

Option 1: Merge (simple and familiar)

git pull origin main
This pulls the latest changes from main and merges them into your branch.
  • It’s quick and easy
  • Git handles most of the work automatically
  • You may see extra “merge commits” in your history
This approach works well, especially when you’re just getting started.

Option 2: Rebase (cleaner history)

git fetch origin
git rebase origin/main
Rebasing takes your work and replays it on top of the latest version of main. The result is a more linear, easier-to-read commit history.
  • Keeps your history clean and organized
  • Makes pull requests easier to review
  • Requires a bit more attention if conflicts come up
If Git encounters a conflict during a rebase, it will pause and guide you through resolving it step by step.

When to update your branch

  • When a teammate merges a PR into main
  • Before opening your own PR
  • If you’ve been working on a branch for more than a couple of days

A helpful guideline

Rebasing is great for your own feature branches, but avoid rebasing branches that others are actively using. Since rebasing rewrites commit history, it can cause confusion if multiple people are working on the same branch.
Both approaches are valid, and different teams have different preferences. The most important thing is to keep your branch up to date regularly so you can catch and resolve conflicts early.