Git and GitHub, from your first commit to your first open-source pull request

Why the tool exists, how to install it without inheriting somebody else's config, and the three places a file can be at the same time.

1. 1The Problem Git Exists to SolveEveryone invents version control before they learn it, and the version they invent is a folder full of files ending in final-v2-ACTUAL. Look at what that folder cannot answer, and at the three ideas Git replaces it with.→
2. 2Getting Git, and Telling It Who You AreInstalling Git takes one command; configuring it takes four, and skipping them is why somebody's first hundred commits are authored by unknown@localhost. Set identity, default branch, editor, and line endings before the first commit rather than after.→
3. 3The Working Tree, the Index, and the RepositoryThe staging area is the one part of Git nobody explains, and it is the reason git add exists as a separate step from git commit. Move one file through all three places and watch which commands touch which.→

Stage, commit, read the history back, undo the thing you regret, and keep the files that should never have been in there out.

1. 4Writing Commits That Explain the Changegit commit -am is fast and it is why so many histories are useless six months later. Stage deliberately, split one messy file into two honest commits, and write the message the way the people reading git log need it.→
2. 5Reading What Everyone Already Didgit log unshaped is a firehose, and four flags turn it into the tool you actually wanted. Then diff, show, and blame answer the three questions you will keep asking about code you did not write.→
3. 6Every Way to Undo, and Which One You WantFour commands undo four different things and the internet recommends them interchangeably. Name what you regret first — a file, a staging decision, a commit, a pushed commit — and the right command falls out of the answer.→
4. 7What Must Never Reach the RepositoryA .gitignore is a list of patterns matched against paths, and it has no effect whatsoever on a file Git is already tracking — which is the trap that leaks credentials. Toggle patterns against a real tree and watch which paths survive.→

A branch is smaller than you think and merging is stranger. Conflicts, rebases, and the one rule about rewriting history.

1. 8A Branch Is a Sticky Note on One CommitA branch is a file containing a forty-character hash, which is why creating one is instant and why deleting one deletes almost nothing. Build a history one commit at a time and watch the labels move.→
2. 9Bringing Two Histories Back TogetherMerging has a direction, and half of all merge confusion is standing on the wrong branch when you run it. See what a fast-forward really is, and why a three-way merge needs a third commit nobody mentions.→
3. 10When Git Refuses to ChooseA conflict is not an error and not a failure — it is Git declining to guess which of two edits to the same lines you meant. Resolve one by hand, marker by marker, and see why the answer is sometimes neither side.→
4. 11Replaying Commits Somewhere ElseRebase does not move your commits; it copies them and abandons the originals, which is exactly why it is both tidy and dangerous. Compare the two histories side by side, then meet the one rule that keeps it safe.→

Pushing to a second copy of your repository, proving you are allowed to, and everything a repository page holds besides the code.

1. 12Your Repository Now Lives in Two PlacesA remote is a nickname for a URL, origin is a convention rather than a keyword, and the ahead/behind counts you trust are computed from a snapshot that may be hours old. Fetch, pull, and push one branch and watch each side move.→
2. 13Proving You Are Allowed to PushGitHub stopped accepting account passwords over Git in 2021, and the error it gives instead sends people in the wrong direction. Pick between a token and an SSH key on purpose, and know where the machine cached the answer.→
3. 14What a Repository Page Actually HoldsMost of a GitHub repository is not code, and the parts that are not decide whether anybody can use the parts that are. Walk the README, the licence, releases, and the settings nobody sees until they matter.→
4. 15Writing an Issue Somebody Can Act On"It doesn't work" is the most common issue on GitHub and the least useful. Learn the four things a maintainer needs, the filing system of labels and milestones, and the keyword that closes an issue from a commit message.→

The unit of work on GitHub, the review that gates it, and the three different things the green merge button can do.

1. 16The Pull Request, From Branch to ButtonA pull request is a merge you have not run yet, wrapped in a conversation. Follow one from the branch that starts it through the description, the draft state, and the checks that run against a commit you never made.→
2. 17Comments, Suggestions, and Requesting ReviewA review is a batch, not a stream of notifications, and the three buttons at the end of one are a promise about what happens next. Leave a line comment, turn it into a commit the author can accept, and learn what resolving a thread claims.→
3. 18Merge, Squash, or RebaseThe green button hides three different operations that leave three different histories on your main branch, and most teams pick by accident. See what each one writes, then meet the protection rules that decide who may press it.→

Contributing to a project you do not own, letting a robot check the boring parts, and agreeing with your team on how any of it happens.

1. 19Your First Contribution to Someone Else's ProjectThe mechanics are a fork, a branch, and a pull request; everything hard about a first contribution is the part before that. Read the project's own rules, pick something small and real, and keep your fork from drifting.→
2. 20Making the Robot Do the Boring PartA workflow is a YAML file in one exact directory, and once it exists your tests run on somebody else's computer every time anyone pushes. Watch a run break into jobs and steps, and see where its verdict shows up on a pull request.→
3. 21Picking How Your Team Actually WorksEvery Git argument a team has is really an argument about branch lifetime. Compare the three common answers, see which problem each was invented for, and decide what your repository should agree on.→