Build with AI · Guide for product managers

Git and GitHub for product managers

Every change your engineers make travels through Git. Once you understand commits, branches and pull requests, standups, release notes and "it's merged but not deployed" suddenly make sense — and you gain the single most important safety net for building with AI.

Guide 6 of 10 in the technical PM path

9 min read · Updated 25 September 2026 · By the TechPMer team

Why a PM should care

• Status becomes visible. A pull request shows exactly what changed, who reviewed it and whether checks pass — more precise than any status update.
• Release questions get clearer. "Merged", "deployed" and "released to users" are three different states.
• You can contribute directly. Fixing copy, updating docs or adjusting config through a pull request is common for technical PMs.
• AI building depends on it. When an AI agent breaks something, Git is how you go back to the last working version in seconds.

Git vs GitHub

Git is a version-control tool: it records the history of every file in a project on your computer. GitHub is a website that hosts Git repositories and adds collaboration on top — pull requests, code review, issues, automated checks (GitHub Actions). GitLab and Bitbucket are similar services.

The core ideas

• Repository (repo): a project folder plus its complete history.
• Commit: a saved snapshot of changes with a message, for example "Add password reset email". Think of it as a save point in a game that you can always return to.
• Branch: a parallel line of work. The main branch (often main) holds the agreed version; a feature is built on its own branch so it does not disturb others.
• Push / pull: send your commits to GitHub, or bring other people's commits to your computer.
• Clone: download a full copy of a repository to your machine.

Pull requests and code review

A pull request (PR) — called a merge request on GitLab — is a proposal: "please merge the changes from my branch into main". A good PR includes:

• a clear description of what changed and why (often linking the ticket);
• screenshots or a preview link for UI changes;
• automated checks — tests, linting, a preview deployment;
• review comments and approval from at least one teammate.

As a PM you can read the description, open the preview, and comment on behaviour or copy. You do not need to approve the code itself.

A typical flow

1. Create a branch     git switch -c feature/password-reset
2. Make changes and commit    git commit -m "Add password reset email"
3. Push the branch     git push -u origin feature/password-reset
4. Open a pull request on GitHub → automated checks run → teammates review
5. Merge into main     → the main branch now contains the change
6. Deploy              → often automatic after merge (CI/CD)
7. Release             → sometimes behind a feature flag until you switch it on

Merge conflicts

A merge conflict happens when two branches changed the same lines differently, and Git cannot decide which version wins. It is normal, not a disaster — someone has to choose. Long-lived branches that drift far from main cause more conflicts, which is one reason teams prefer small, frequent PRs.

Merged, deployed, released

When someone says "it's merged but not deployed", the work is done but not yet live. When they say "it's deployed behind a flag", it is live but switched off — a product decision when to turn it on.

What engineers may tell you

• "It's still in review." Written, waiting for a teammate's approval or changes.
• "CI is red." Automated checks failed — tests, build or lint — so it cannot merge yet.
• "I need to rebase onto main." Update the branch with the latest main-branch changes before merging.
• "Let's revert that commit." Undo a specific change with a new commit that reverses it — a safe way to roll back.
• "Can you split this PR?" It is too big to review properly.

Questions a good technical PM asks

1. Is there a PR I can follow, and is there a preview link?
2. What is left: review, failing checks, or deployment?
3. Is this behind a feature flag? Who decides when to switch it on?
4. If this goes wrong in production, how do we roll back?
5. Is this PR small enough to review well?

Red flags

• Changes pushed straight to main with no review on a team project.
• Secrets (API keys, passwords, .env files) committed to the repository — even in a private repo, and even if deleted later, since they stay in history.
• Weeks-old branches nobody has merged.
• "Works on my machine" with no automated checks.

Git and AI coding agents

Git is the seatbelt for AI-assisted building:

• Commit before every AI task. If the agent's change goes wrong, you can discard it and return to the last good state.
• Review the diff, not just the result. git diff or the PR view shows exactly what the agent changed — including files you did not ask it to touch.
• One task, one branch or commit. Small steps make it obvious which change broke something.
• Keep .env in .gitignore. Ask the agent to check that no secrets are tracked.

A simple instruction that saves a lot of pain: "Before starting, confirm the working tree is clean. Make the change, show me the diff summary, and do not commit until I approve."

Try it yourself

Create a free GitHub account, make a new repository with a README, edit the README in the browser and commit the change on a new branch. Then open a pull request to main, review it yourself and merge it. That ten-minute loop is the same one every engineering team runs hundreds of times a week.

TechPMer's week 2 (“Git & GitHub — Working Like an Engineering Team”) walks through this with your own project, including SSH keys, cloning and letting an AI agent work safely inside a repository. It is included in the free account, and the full Git & GitHub guide is inside the app.