Skip to content
Module
Module 1 of 6Lesson 1 of 1~3 min

Course overview

This course is for Product Managers who want to contribute directly to their team's repository without putting production at risk. You learn to understand a repository, work on a branch, go through pull requests, rely on the team's safeguards and supervise a coding agent. You finish by shipping an improvement yourself from start to finish.

Lesson 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.

Topics covered

  • Git for Product Managers
  • pull requests
  • Git branches
  • CI/CD
  • contributing to code

Where it fits

Overview

What will I be able to do by the end of this course, and in what order?

Lessons in this module

  1. Course overview (this lesson)

What you will learn in the course

This lesson is part of the course Git for PMs: ship as a team without putting production at risk

  • 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.