Module
Module 3 of 6Lesson 1 of 2~20 min

Everyday commands, and what can go wrong

Lesson 1 of the module "Work on a branch, day to day" in the course "Git for PMs: ship as a team without putting production at risk".

Take this lesson: your first course is freeSee the full syllabus

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

Where it fits

Work on a branch, day to day

Which commands do I use, in what order, and how do I name my work?

Lessons in this module

  1. Everyday commands, and what can go wrong (this lesson)
  2. Branching strategy and commit messages

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.

Related courses