Repos, commits, and pull requests

Before an AI code pipeline can review anything, the change has to exist as a pull request. This lesson is the loop in plain words. Repository. Commit. Pull request. Merge. That is enough to start.

We stay on the happy path. No squash. No rebase. No retargeting. Those are later habits. First you need to know what you are looking at on GitHub.

A repository is the shared project

A repository (repo) is the folder GitHub remembers for you. It has a name. It has files. It has a history. The team clones it. Your laptop copy and the copy on GitHub are meant to stay in conversation.

If there is no repo, there is no shared history. You cannot open a pull request on a zip file in Slack.

A commit is one saved step

A commit is a snapshot plus a message. You changed src/limit.ts. You wrote “Explain the 429 path.” Git stored that. The next commit sits on top of it.

Commits are how you answer “what changed, and why.” They are not the review. They are the material the review will read.

A pull request is the ask

You do not edit main in secret and hope. You make a branch, commit there, then open a pull request. The PR shows the diff against main. People comment on it. CI can run on it. A model can take a first pass on it.

Until someone merges, the change is a proposal. That is the whole point of a PR: a named place to look before the code is the product.

Merge is the finish

Merge means the proposal is accepted. The commits join main. The PR closes. Later you ship from main.

Who clicks Merge is the owner. Tools can comment. Tests can go red. A human still decides the change is allowed on the line everyone deploys.

How this becomes a pipeline

Write. Commit. Open a PR. Review. Merge. That is already a pipeline. An AI code pipeline puts a model in one of those seats — usually the first pass on the PR — and keeps the human on merge.

If the words above are new, stop here and walk the loop once on a real repo: one file, one commit, one PR, one merge. Then take the next lesson.