Skip to content
AI Newbie
Menu
Step 4 of 86 min read

Git part 2: work together

Newbie to Tech · Step 4 of 8 · about 5 minutes to read, 30 minutes with a partner Practice project: https://github.com/jazken/mood-habit-tracker · setup: branch step-3 (practice conflict). Yes, the branch is called step-3 but this is lesson 4. The names don't line up, and that's fine. Works with any AI coding tool. GitHub steps were checked against GitHub Docs and GitHub Skills on 20 Oct 2026 (SGT).

Do this now (with a partner)

You need: a partner, and a free GitHub account each. You do it all on GitHub's website. The step-3 branch of the practice project is set up for this. Its README has the same steps.

  1. Partner A uses their fork of mood-habit-tracker from Step 0. That fork is the one shared copy. Partner A invites Partner B: Settings → Collaborators. Partner B accepts the invite and works in Partner A's fork, not their own.
  2. Set the branch menu to step-3. Each of you makes your own branch from step-3: type a-title or b-title in the branch menu, then click Create branch.
  3. Each of you edits the first line of README.md on your own branch, in different ways. Click the pencil, change it, then Commit changes.
  4. Each of you edits the habits list in index.html: the three buttons Drink water, Take a walk, Read a page. Change only the words people see, in different ways. Commit.
  5. Each of you opens a pull request (PR) from your branch into main. ⚠️ Check the top of the PR page. The base repository must be Partner A's fork, not jazken/mood-habit-tracker. Change it if needed.
  6. Merge Partner A's PR.
  7. Partner B's PR now says it has a conflict. Click Resolve conflicts and fix it together, for the title and the habits list. Click Mark as resolved, then Commit merge, then merge.

Check you did it: main in Partner A's fork has one agreed first line and one agreed habits list. Both PRs say Merged.

No partner yet? Do GitHub Skills (free) first: "Introduction to GitHub", then "Resolve merge conflicts".

Good to know: each PR into main also carries the earlier stages (saving and a week chart), because step-3 is built on them. That's expected. Partner A's main gets those too. You'll build the chart yourself in Step 6.


Why this matters

When two people (or two AI tools) change the same project, you need a way to share work without wiping out each other's changes. Git and GitHub do that. Merge conflicts sound scary, but they're just Git asking a person to choose.

The picture (then the real thing)

In a shared document, everyone types into the same copy at the same time. Git works differently:

  • Everyone has their own full copy on their computer.
  • There's usually one shared copy online, for example on GitHub. It's called the remote, and it's often named origin.
  • Changes move between your copy and the shared one only when you tell Git to.

The 5 teamwork words

Clone

Download a full copy of a shared repo, with all its history: git clone <link>. You do this once.

Push

Send your commits up to the shared copy: git push. Until you push, nobody else sees your commits.

In this project, don't type a step name after push. git push origin step-2 fails, because step-2 is both a branch and a tag. Plain git push, or git push origin HEAD, works.

Pull

Bring your partner's commits down to your copy: git pull. It fetches the new commits and merges them into your branch.

A good rhythm: pull → work → commit → pull again → push.

Pull request (PR)

A pull request is a page on GitHub that says: "Please look at my branch and merge it into main." Your partner can:

  • read the diff,
  • leave comments,
  • approve it, or ask for changes.

Then someone clicks Merge. A PR is how teams check each other's work, and how you check the AI's work.

Merge conflict

A merge conflict happens when two branches change the same lines of the same file. Git can't guess which one is right, so it stops and asks a person.

You'll see markers like these in the file:

<<<<<<< b-title
# Our Daily Check-in
=======
# Mood and Habits by Team A
>>>>>>> main

The top part is one version and the bottom part is the other. To fix it: keep what you want, delete the marker lines (<<<<<<<, =======, >>>>>>>), and save. Then commit, or click Mark as resolved and Commit merge on GitHub.

Talk first, then fix. A conflict is a people question: whose change should win? Don't let the AI decide alone.

When to let the AI run Git

AI tools can run Git for you, and that's handy. But some commands only look, and some change things for everyone.

✅ Let it run (after you read the command)⚠️ Check first, every time
git status, git diff, git log (only look)git push (sends work to everyone)
git add, and git commit on your own branch, after you read the diffMerging into main
git switch -c new-branch (makes a branch)Fixing a merge conflict
git pull on your own branchDeleting a branch
Anything with --force, reset --hard or rebase. These can erase work

Golden rules while learning:

  1. Never pick "always allow" for push or merge.
  2. The AI works on a branch, never straight on main.
  3. Changes reach main through a PR that a human reads.

In your tool: Git safety

  • Kiro: commands ask Allow or Deny. For git push, choose Allow each time, not Always allow. Kiro's docs show an example rule that allows all git commands. Don't copy it while you're learning.
  • Claude Code: you can add an ask rule so it always checks with you before a push, written as Bash(git push *). Its docs also show a deny rule that blocks push completely. To review your branch before a PR, type /code-review.
  • Antigravity: put command(git push) in your Ask list, so it checks before every push. Rule order is Deny > Ask > Allow. Its docs show examples that put command(git) and command(git push) in Allow. Don't copy those while you're learning. This permission system is for macOS and Linux. Windows still uses an older system.
  • Codex: by default, network access is off and it asks before using the network. A push needs the network, so we expect Codex to ask first. I haven't tested this myself. In the desktop app, the Code Review view shows a PR's summary and changed files.

Using your AI tool with a partner

  1. Each person asks their AI to work on their own branch.
  2. Before you push, ask: "Show me the diff and explain it in plain words."
  3. Open a PR. Your partner reads it. That means a human reads the diff, not just the AI's summary.
  4. If there's a conflict, ask the AI: "Explain this conflict in plain words. Don't fix it yet." Then decide together.

Words from this step

WordWhat it means
Remote / originThe shared copy online
CloneDownload a full copy of a repo
PushSend your commits to the shared copy
PullGet your partner's commits
Pull request (PR)A request to review and merge a branch
Merge conflictTwo changes to the same lines, so a person must choose
CollaboratorSomeone allowed to push to a repo

Go deeper

Next: Step 5, Put your tracker online.

After you try it

Did this produce something you could use, and what did you have to correct?

Email a reply, or keep a note for yourself. The useful part is the correction — that is the skill, not the first draft.

Email hello@ainewbie.org

Get the AI Newbie Brief