Use version control as a collaboration tool: commit with intent, branch on purpose, merge without fear, resolve conflicts deliberately, and ship work through a pull request that a reviewer can actually read.
Git is not difficult because it is complex. It is difficult because it is a database with a small command surface, and the commands that feel dangerous are the ones that rewrite history. Once the model underneath is clear — commits as snapshots, a staging area as the next commit you are assembling, HEAD as a movable label — most of the fear goes away. This course builds that model first and then works outward. It starts with the three trees that explain every confusing thing about Git: the working directory, the staging area, and the repository, and the fact that a commit is a snapshot of the staging area rather than of your files. It covers what a branch actually is (a movable label, not a copy), what a merge commit records, and when a fast-forward is preferable to a real merge. It spends a full module on conflicts, because that is where beginners lose confidence, and treats conflict resolution as deliberate work rather than error recovery. Then it moves to collaboration. Remotes, fetch versus pull, and why `git push --force` on a shared branch is destructive. It finishes with pull requests: what a good one contains, how to review one, and how the small habits — atomic commits, a written commit message, a branch named for the change — compound into a history anyone can read. The graded project is a real repository with a reviewable history and a pull request worth reading, reviewed against written criteria.