Git for PMs: ship as a team without putting production at risk
Contribute safely to an existing repo with CI/CD: short branches, reviewed pull requests, checks and previews, conflicts, safety nets, clean undo and an AI agent kept in check.
Contribute to the code of a product that already has an engineering team, continuous integration and a production environment, without ever putting production at risk. You learn to read a repository and its pipeline, work on a short-lived branch, open a pull request the team actually wants to review, pass the checks and the preview, resolve a conflict, undo a change cleanly and keep an AI coding agent inside that workflow. You finish by shipping a small improvement end to end in a practice repository.
What you will be able to do
- Read an existing repository and its pipeline (README, CONTRIBUTING, CODEOWNERS, CI workflows, environments) to know who reviews what, what gets checked and what goes to production, and when.
- Work on a short-lived branch with everyday Git commands (or their GitHub equivalents), small commits named by convention, and stay in sync with main.
- Open a small, well-described pull request, get the right review, pass the required checks, validate the preview and choose the merge method.
- Resolve a simple merge conflict calmly, on the command line or in GitHub, and know when to ask for help.
- Assess a repository's safety nets (branch protection, required checks, mandatory review, feature flags, staging, progressive rollout) and propose the missing ones.
- Choose the right way to undo a change (restore, revert, reset, deployment rollback) depending on whether it is local, pushed, merged or already in production.
- Keep an AI coding agent under control in a team repository (dedicated branch, written rules, protected secrets, proof of verification, human review before merge).
- Tie merged changes to a release (tag, semantic versioning, changelog) and write release notes that help users.
Prerequisites
- Able to open a terminal and type a command (cd, ls), or willing to follow the GitHub web equivalents
- Know what a commit and a GitHub repository are, at least by name
- Accounts and tools: Git installed (git --version) and a GitHub account; a coding agent such as Claude Code helps in module 5 but is not required
- Recommended before this course: Build and ship a web app with an AI coding agent (solo Git, first deployment). This course is its sequel: working with others in an existing repository and pipeline.
- This course is not developer training: it targets safe contributions to limited changes (copy, UI, simple configuration), reviewed by the team.
Syllabus
What will I be able to do by the end of this course, and in what order?
- Course overview2 steps
Objective · By the end of this overview, you will know what you will be able to do in a team repository (ship a change through a pull request with no risk to production) and which five modules get you there.
What happens between my commit and production, and who decides?
Objective · By the end of this lesson, you will be able to explain where a change is (files, index, local commit, remote repository, main) and tell, from git status and git log, what is missing for it to reach production.
Objective · By the end of this lesson, you will be able to read the key files of an existing repository (README, CONTRIBUTING, CODEOWNERS, CI workflows, hosting configuration) to say who will review your change, what will be checked, where to test it and which event will send it to production.
Which commands do I use, in what order, and how do I name my work?
Objective · By the end of this lesson, you will be able to chain the Git commands of a contribution day (clone, switch -c, status, diff, add -p, commit, push -u, fetch, pull, log) or their GitHub equivalents, knowing what each one changes and how to spot a mistake before it reaches the shared repository.
Objective · By the end of this lesson, you will be able to compare trunk-based development and Git flow for a given context, name a branch with a readable convention and write commit messages in the Conventional Commits format.
How do I get a fast review, pass the checks and merge without surprises?
Objective · By the end of this lesson, you will be able to open a small, complete pull request: clear title, description (why, what, how to test, risks), link to the ticket, draft or ready status, and the right reviewers thanks to CODEOWNERS.
Objective · By the end of this lesson, you will be able to respond to a review, interpret required checks, use the preview as an acceptance test and choose a merge method (merge commit, squash, rebase), knowing its effect on history.
Objective · By the end of this lesson, you will be able to read conflict markers, resolve a simple conflict on the command line or in GitHub's editor while keeping both sides' intent, check the result, and recognise the conflicts to hand over to a developer.
What stops a mistake from reaching users, and what do I do if it gets through anyway?
Objective · By the end of this lesson, you will be able to audit a repository's safety nets (branch protection or rulesets, required checks, mandatory review, preview and staging, feature flags, progressive rollout) and propose, with a metric, the ones it lacks most.
Objective · By the end of this lesson, you will be able to choose the right way to undo a change depending on where it is (file, local commit, shared branch, main, production): git restore, git reset, git revert, a pull request's Revert button or a deployment rollback, without ever forcing shared history.
How do I bring an AI agent into this workflow, mark a release and ship my first improvement?
Objective · By the end of this lesson, you will be able to make a coding agent such as Claude Code work inside the team's workflow: on a dedicated branch, with rules written in CLAUDE.md, proof of verification, protected secrets and a human review of every diff before merging.
Objective · By the end of this lesson, you will be able to work out the next version number under semantic versioning from the merged changes, know how a tag is created and published, and write release notes that help users.
Objective · By the end of this workshop, you will have shipped a small improvement through a pull request in a practice repository with CI and previews, meeting a definition of "ready to merge" and keeping evidence of every step.