What is GitHub, and how do a hundred developers work on one codebase?

What is GitHub, and how do a hundred developers work on one codebase?

GitHub is a website that hosts repositories, and a hundred developers can share one codebase because every change goes through the propose-and-review pipeline rather than straight into the shared copy. The pipeline itself, commits, branches, and pull requests, came earlier in this course. This lesson covers the place where that pipeline is visible to the public, and the vocabulary that comes with it: forks, stars, the green squares, and the parts a profile will never show.

The reason this deserves its own lesson is that GitHub doubles as a social record. A developer's profile there is the closest thing the industry has to a public portfolio, which is why later lessons on what developers care about keep returning to it. Before any of that judgment is possible, the objects on the page need literal definitions, because several of them mean less than they appear to.

What is GitHub?

GitHub is a company, owned by Microsoft, that hosts repositories on its servers and wraps them in collaboration tools. The hosting part is storage: a team's repository lives on GitHub, and each developer clones it to their own machine to work. The collaboration part is everything around the code: the pages where pull requests get discussed, where code review comments are written, and where bugs get tracked.

That bug tracking has a name worth knowing. An issue is a numbered discussion thread attached to a repository. Anyone can open one to report a bug, request a feature, or raise a question, and the thread stays attached to the project forever. When a developer says "I picked up issue 4211", they mean they took on the piece of work that thread describes.

Repositories on GitHub belong to an owner, and the owner is either a person or an organization. An organization is a shared account that holds a group's repositories in one place, with member lists and permissions. Companies use organizations for their code, and so do large open source projects. Seeing a developer listed as a member of a well-known organization means the group granted them standing access, which is a stronger tie than any single contribution.

How do many people change one codebase without collisions?

They avoid collisions because nobody edits the shared copy directly. Each developer works on their own branch, proposes the change through a pull request, and the change only merges after review. A hundred cooks share one kitchen by each cooking at their own station and bringing finished dishes to a pass where someone checks them. The kitchen never has a hundred hands in one pot.

GitHub adds the roles that make this work at open source scale, where the cooks are strangers. A maintainer runs the project. Maintainers decide which pull requests merge, which issues matter, and where the project goes next. The title carries real weight: a maintainer of a widely used project is trusted by every company whose product depends on that code. A contributor is anyone who has had at least one change accepted into the project. The range inside that word is enormous. Fixing a typo in the documentation makes someone a contributor, and so does building a major feature, and the label reads the same on a profile. The size of the claim lives in the actual changes, which are public and readable.

What is a fork?

A fork is a personal copy of someone else's repository, made with one click on GitHub. The copy lands under the copier's own account, and they can change it freely without touching the original. Forking is how a stranger contributes to a project they have no access to: fork it, change the fork, then open a pull request offering the change back to the original.

The name misleads in one direction. "Fork" sounds like an act of creation, a road splitting, and occasionally it is, when a community copies a project to take it somewhere new. The overwhelmingly common case is smaller: a developer clicked a button, intending to try something or contribute later, and often never did. A fork with no changes in it contains none of the copier's work. It is a bookmark wearing a repository's clothes.

What is a star, and what is a watch?

A star is a public bookmark. Clicking the star button on a repository adds it to a personal list and adds one to the project's public count. That is the entire mechanism, and it is why star counts need care. A high count means many people noticed and saved the project, which tracks audience, promotion, and timing as much as engineering quality. Superb code that solves a narrow problem for a small field can sit at twelve stars for years. Most working professional code has none at all.

A watch is a subscription. Watching a repository sends the watcher notifications about its activity: new issues, new pull requests, new releases. Stars say "I want to find this again". Watches say "tell me what happens here". Both are one click, both are public, and neither involves writing code.

Read from a profile, both lists describe attention rather than output. What a developer stars and watches sketches what they are curious about right now, which is honest and sometimes useful information, gathered at a cost of zero effort per click.

What are the green squares?

The green squares are the contribution graph, a one-year calendar grid on every profile where each square is one day. A gray square means no recorded activity that day. Green means some, and darker green means more. The graph counts commits, opened pull requests, opened issues, and code reviews.

Two facts keep the graph in proportion. First, it counts events, and an event is an event regardless of size. A day spent on one difficult change that lands as a single commit draws one pale square. A day of thirty tiny bookkeeping commits draws a dark one. The darker day held less of the hard work. Second, the graph only shows what GitHub can see, which connects to the theme of the next section: for most employed developers, the visible slice is small. A sparse graph above excellent public repositories describes someone whose recorded work is concentrated, and the quality read comes from the work itself.

What is a README?

A README is the front page of a repository: a document, written by the project's authors, that explains what the project does, why it exists, and how to use it. It renders automatically at the top of the repository page, so it is the first thing every visitor reads. The name comes from a decades-old convention of shipping software with a file called READ ME.

For a non-programmer, the README is the most legible object in any repository, because it is written in prose for an audience of strangers. A clear one states the problem, shows how to get started, and anticipates what a new user will trip on. That is technical communication, on the record, addressed to people the author never met. A developer who writes a README like that has demonstrated a skill that transfers directly to design documents, onboarding, and every other place engineers write for other humans.

Why is most work invisible?

Most work is invisible because most professional code lives in a private repository, visible only to people the owner explicitly grants access. Companies keep their code private by default: the product is the asset, and the repository is where the asset lives. A developer at a private-code company can spend years shipping commits, pull requests, and reviews, all through the same pipeline this course has covered, and none of it ever reaches their public profile.

The proportions matter. For a typical employed developer, employer-owned private work is the large majority of everything they build. The public profile shows the remainder: side projects, and any open source they choose to do. Some of the strongest engineers in the industry have nearly empty profiles, because their whole output belongs to an employer's organization. An empty profile is silence, and silence carries no information in either direction.

That framing sets up the two lessons ahead. When public work does exist, it was effectively done for free, and the reasons a well-paid engineer gives work away are the next lesson's subject. And when a profile is rich, reading it well, deciding which repositories are load-bearing and which are wallpaper, is a skill this course builds later, in reading the profile. This lesson's job was the literal layer: what each object is, what one click can produce, and how much of the iceberg sits below the waterline.