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.
- Partner A uses their fork of
mood-habit-trackerfrom 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. - Set the branch menu to
step-3. Each of you makes your own branch fromstep-3: typea-titleorb-titlein the branch menu, then click Create branch. - Each of you edits the first line of
README.mdon your own branch, in different ways. Click the pencil, change it, then Commit changes. - 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. - 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, notjazken/mood-habit-tracker. Change it if needed. - Merge Partner A's PR.
- 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 diff | Merging into main |
git switch -c new-branch (makes a branch) | Fixing a merge conflict |
git pull on your own branch | Deleting a branch |
Anything with --force, reset --hard or rebase. These can erase work |
Golden rules while learning:
- Never pick "always allow" for push or merge.
- The AI works on a branch, never straight on
main. - Changes reach
mainthrough 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 allgitcommands. 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 putcommand(git)andcommand(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
- Each person asks their AI to work on their own branch.
- Before you push, ask: "Show me the diff and explain it in plain words."
- Open a PR. Your partner reads it. That means a human reads the diff, not just the AI's summary.
- 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
| Word | What it means |
|---|---|
| Remote / origin | The shared copy online |
| Clone | Download a full copy of a repo |
| Push | Send your commits to the shared copy |
| Pull | Get your partner's commits |
| Pull request (PR) | A request to review and merge a branch |
| Merge conflict | Two changes to the same lines, so a person must choose |
| Collaborator | Someone allowed to push to a repo |
Go deeper
- GitHub Skills, Introduction to GitHub: https://github.com/skills/introduction-to-github
- GitHub Skills, Resolve merge conflicts: https://github.com/skills/resolve-merge-conflicts
- GitHub Skills, Review pull requests: https://github.com/skills/review-pull-requests
- Invite a collaborator: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/repository-access-and-collaboration/inviting-collaborators-to-a-personal-repository
- About pull requests: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
- Resolve a conflict on GitHub: https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-on-github
- Push commits: https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository
- PRs from a fork: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork
- Pro Git, branching and merging: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
- Claude Code permissions: https://code.claude.com/docs/en/permissions
- Antigravity permissions: https://antigravity.google/docs/permissions
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