ENTR-451

Git and GitHub

Ben Block -

This is one of two posts from the first week. This one is the tools: what Git and GitHub are, and how a change actually gets into a codebase. The other is Open source and licensing, the longer version, which is about deciding whose code you are willing to build on. Start here; that one uses the vocabulary this one sets up.

Git and GitHub are not the same thing

Nearly everyone trips over these two names, and it is worth thirty seconds of precision, because more decisions hang off the distinction than you would guess.

Git is software. It is version control for source code: it stores your files, keeps their entire history, and lets several people work on the same project without overwriting each other. Linus Torvalds wrote it in 2005 to manage development of the Linux kernel. It is free and open source, it runs on your own machine (or, this quarter, in your Codespace), and no company owns it.

GitHub is a company. Founded in 2008, bought by Microsoft in 2018 for around seven and a half billion dollars. Its business is hosting Git repositories and selling the things built around them: a web interface, permissions, issue tracking, code review tools, automation.

The relationship between the two names is exactly that, and nothing more. GitHub hosts Git.

If it helps: Git is email, GitHub is Gmail. Email is a protocol that nobody owns and that many companies provide. Gmail is one company's product for using it, with its own interface and its own features layered on top. You can leave Gmail and still have email.

Git is the thing. GitHub is a place to keep the thing.

Other places to keep the thing

GitHub is the largest by a wide margin, which is why this course uses it and why it is the one worth knowing. It is not the only one, and a few of these will turn up in your working life:

  • GitLab, the closest competitor, and the one most often chosen by companies that want to run the whole thing on their own servers.
  • Bitbucket, from Atlassian, common in organizations already using Jira.
  • Azure DevOps, also Microsoft, common in large enterprises.
  • Self-hosted, using software like Gitea or Forgejo, or a plain Git server with no web interface at all. Git needs no company to function.

Why the distinction is worth money

Here is the part that matters when you are the one choosing.

Your project's entire history lives inside the repository itself, in a hidden folder that comes along whenever anyone copies it. Moving a project from one host to another is close to trivial: clone it, point it at the new host, push. Nobody holds your code hostage.

What does not move is everything the host added. Your issues, your pull requests and the discussions on them, your review history, your automation, your integrations. Those are GitHub's, in GitHub's shapes, and leaving means leaving them behind or paying somebody to convert them.

That asymmetry is the actual product. It is also the shape of most software-as-a-service lock-in you will ever evaluate: the thing you thought you were buying is portable, and the thing that accumulated around it is not. Worth recognizing the pattern here, where the stakes are low, so you recognize it later when they are not.

What Git actually does

Think about version history in a document editor: you can see what changed, who changed it, and roll back to how it looked last Tuesday. Git is that, for code, with the history treated as the important part rather than a convenience.

Because Git watches every file in a project continuously, it knows the entire history of the work: what was added, modified and deleted, by whom, and when. That is what makes the rest possible.

  • Attribution. Who contributed what, and when.
  • Time travel. View or return to the project as it stood at any earlier point.
  • Branching. Several versions of the same project, running in parallel from a common starting point, which is how more than one person works on something at once without chaos.

Every professional software team uses version control, and in practice almost all of them use Git. Once it arrived, the alternatives largely emptied out.

Repositories

A Git project lives in a repository, usually one repository per project. Hosting repositories is GitHub's main business.

A GitHub user or organization holds repositories. Microsoft's organization on GitHub holds a great many, one of which is the source for Visual Studio Code, the editor running in your Codespace. Your own account starts empty. That changes in the first class.

There are two ways to make one:

  • New repository, starting from nothing or from code already on your computer.
  • Use this template, which copies an existing repository's files into a brand new repository of your own. This is the one we use most in this course, because it hands you a working starting point instead of an empty folder.

To try the second one: go to github.com/dsgn425-fall2026/hello-world, click Use this template, name the new repository hello-world, leave it private, and create it. It lands in your own account in a few seconds, and it is yours.

Have a look around. A repository is a folder of files and folders, and not much more than that. You can add files and edit the ones already there, right in the browser.

Your first commit

Open README.md and click the pencil icon. Change anything you like, then scroll to the bottom, to Commit changes.

The first box is the commit message. It is pre-filled with something generic like Update README.md, and you should replace it. The message is a note to your future self and to everybody else about what you did and why, and it is the single most durable piece of communication in a codebase. Write what changed, in plain words.

Click Commit changes. That takes the work you did, one coherent unit of it, and records it permanently in the repository's history.

A commit is a snapshot with a note attached. That is the whole idea, and everything else in Git is built out of it.

Committing straight onto the project the way we just did is fine when the project is yours and nobody else is touching it. It stops being fine immediately after that, and the rest of this post is what teams do instead.

Branches

A repository has a main line of development, called main. Treat it as the official version: the one that works, the one that ships, the one everybody else pulls from.

A branch is a separate line of work that starts from a copy of main at a moment in time. You make one, you do your work on it, and main is untouched the entire time. When the work is done and somebody has looked at it, the branch gets folded back in.

The reason this matters is not tidiness. It is that real work is unfinished for most of its life. Halfway through a change, the code is usually broken, and if you were working directly on main then everybody else is now working on top of your broken half-change. A branch is where something is allowed to be incomplete without hurting anyone.

The second reason is that several people can do this at once. Five people on five branches are not in each other's way, and the question of how their work fits together gets asked once, deliberately, when each branch comes back, instead of continuously and by accident.

Two practical notes. Name the branch for what you are doing, not for yourself: add-search tells a colleague something, bens-branch does not. And do not hoard a branch. The longer it sits away from main, the more main moves underneath it and the harder the eventual reconciliation gets. Branches are cheap and meant to be short-lived, which is the opposite of
the instinct most people arrive with.

Pull requests

Here is a distinction worth holding onto, because it follows the Git and GitHub split from the top of this post: branches and commits are Git. Pull requests are not.

A pull request is a GitHub feature, built on top of Git. It is a request, addressed to the people who own the project, saying: I did this work on my branch, please pull it into main. GitLab calls the same thing a merge request, which is arguably the better name.

It is three things at once, and the third is the one people miss.

  1. A proposal. Nothing has happened yet. main is unchanged until somebody merges.
  2. A place to talk. The pull request shows the diff: every line added, removed or changed. Anyone can comment on the whole thing, or on one specific line. Conversation happens against the actual change rather than in a meeting about the change.
  3. A record. It survives. In two years, when somebody asks why a thing works the way it does, the pull request is where the answer is: what changed, who asked for it, what the objections were, and who decided. Most of the institutional memory of a codebase lives in old pull requests.

On any serious team, main is protected, which means nobody can push to it directly, not even the person who owns the company. The pull request is not the polite option. It is the only door.

Code review

Somebody other than the author has to look at the change and say yes. That is code review, and it is the part of this that will follow you furthest, because you may well end up on the approving side of it without ever writing the code yourself.

A reviewer opens the Files changed tab and answers three questions:

  1. Does the change do what the pull request says it does?
  2. Does the commit message tell you what changed without opening the diff?
  3. Would you merge this?

Then they leave at least one comment on a line, and submit the review as either Approve or Request changes. If they requested changes, the author fixes it on the same branch and commits again, the pull request updates itself, and the reviewer looks again. That loop is the job.

Notice what is not on that list. Nothing about whether the code is clever, and nothing that requires you to be able to have written it yourself. Review is mostly about intent: does this do what it claims, would somebody understand it later, and am I willing to put my name on letting it in. Those are judgment questions, and they are the same questions you would ask about anything else your team proposes to ship.

The checklist grows as the course goes on. The three questions do not change.

One rule that is worth understanding rather than memorizing: GitHub will not let you approve your own pull request. Nobody reviews their own work. That is not a technicality, it is the whole point of the mechanism.

The loop, in one place

Every change to every serious codebase goes through some version of this.

  1. Branch. Off main, named for what you are about to do.
  2. Change. On the branch, where being half-finished is safe.
  3. Commit. One coherent unit of work, with a message that says what it was.
  4. Publish. The branch goes up to GitHub.
  5. Pull request. The proposal to change main.
  6. Review. Somebody else reads it and says yes, or says not yet.
  7. Merge. It lands on main.
  8. Delete the branch. It served its purpose.

You will run that loop by hand a few times in this course until it is boring. That is the intended outcome. The mechanics are meant to become automatic so that your attention can go to the only part that actually needs a person: step 6.

Where this goes next