Why GitHub Is the New Goldmine?

A Monday with a team that does not exist

The story below is made up to show the ideas in action. The people, the company and the app are invented. Every tool and feature it mentions is real and explained further down.

9:05, Monday. A four-person team at an invented company is already deep in standup. Dana is the engineering lead. Raj handles the back end. Mei handles the front end. Sam runs customer support.

Dana: 'Customers keep asking for saved filters. Is issue 212 ready?'

Raj: 'Ready. It has the spec, three sub-issues and a label. I'll hand the back-end half to my agent on its own branch.'

Mei: 'I'll run mine in a separate worktree so the two agents can't trip over each other's files.'

Sam: 'Quick one from support. A customer says the CSV export drops the last row. I filed it as a bug and attached their email.'

Dana: 'That's issue 213. Mark it urgent and assign it to Mei's agent. The fix gets its own branch off main, and nothing else gets mixed in.'

By lunch, two pull requests are open, both as drafts. Raj: 'CI is red on mine. A test caught my agent assuming the filter list is never empty.' Mei: 'Mine is green. Can you review?'

Dana requests changes on the first pull request and approves the second. 'I'm using squash and merge so main stays tidy. Branch protection won't let anyone merge until the required checks pass and one human approves, which is exactly what I want when the typing is done by agents.'

Sam: 'When the fix merges, does the customer get it today?' Dana: 'The merge to main starts the deploy workflow. It pauses for my approval in the production environment, then ships. Issue 213 closes by itself because the pull request says Fixes #213.'

Sam: 'So the issue is the customer's trail, the pull request is the proof, and the workflow is the delivery.' Dana: 'And the agents did the typing. We did the deciding.'

In short

AI agents can now write a lot of code, quickly. They do not decide what is safe to ship. Git and GitHub are where that decision happens, and where agents leave their work in a form you can read, test, review and undo. They are also the bridge that connects all your coding agents: whichever tool you use, its work arrives in the same repository.

You do not need the command line. You need about a dozen ideas and the right words for them: repository, commit, branch, pull request, review, merge, conflict, worktree, issue, workflow, check and protection rule. This article defines each one in plain language, shows what GitHub's Issues and Actions can do, compares how the main coding agents handle worktrees and sub-agents, gives GitHub's own growth numbers and a short history, and ends with a glossary you can come back to.

Why GitHub is the new goldmine

Your AI writes the code. GitHub decides whether it ships. That one line is the whole argument, and it has three veins of value.

Context. A repository is the shared memory of a project: the code, its history, the issues that explain why, and the instruction files that tell an agent how to behave. Agents start most tasks with only a prompt and a fresh context window, so what lives in the repository is what they can build on. Whoever keeps that record well gets more out of every agent.

Control. Branches, pull requests, reviews and automated checks are the gates between an agent's suggestion and your product. They are what let you use powerful tools without handing over the keys.

Skill. Claude Code, GitHub Copilot, Codex and Antigravity change every few months. Git and GitHub concepts carry across all of them. If you learn the ideas once, you can direct any agent and judge what comes back. If you skip them, you are trusting work you cannot inspect.

That is the sense of goldmine used here: not a promise of money, but a skill that compounds. Nothing in this article guarantees a job, a salary or a result. It is a map of what is worth learning first.

Git and GitHub: what is the difference?

Git is a version control tool. It records every change to a project, who made it and why, and lets many versions of the work exist side by side. It runs on your own computer and does not need the internet.

GitHub is a service built around Git. It holds a shared copy of your project online and adds the team features: Issues to track work, pull requests to propose and review changes, Actions to run automatic checks and deployments, and permissions to control who can do what. Other services offer similar features, but GitHub is the one most coding agents integrate with first.

The core ideas, in plain language

Repository

A repository, often shortened to repo, is a project folder plus its complete history. Every file and every earlier version lives in it. A copy on your computer is a local repository; the shared copy on GitHub is the remote.

Commit

A commit is a saved snapshot of the project with a short message saying what changed and why. Commits are the steps of the project's history. Because each one is small and labelled, you can go back to an earlier point, or see exactly when something broke.

Branch

A branch is a separate line of work that starts from the main version. Changes on a branch do not touch the main version until you decide to merge them. The main version is usually called the main branch, or the default branch. Branches are cheap, so the habit is one branch per task. This is what makes it safe to let an agent try something: the experiment lives on its own branch.

Pull request

A pull request, or PR, is a proposal to bring the changes on one branch into another, usually into the main branch. It shows exactly what changed, hosts the discussion and runs the automated checks. A draft pull request says the work is not ready to merge yet. Agents such as the Copilot coding agent open pull requests as the way to hand work back to you.

Review

A review is a person reading the changes in a pull request and responding: comment, approve, or request changes. On GitHub the reading happens in the Files changed tab. A request for changes can block the merge until it is resolved. Reviewing is where your judgment goes when an agent has done the typing.

Merge

A merge brings the changes from one branch into another. GitHub offers three ways to merge a pull request. Merge commit keeps every commit and adds a merge point. Squash and merge combines all the commits into one. Rebase and merge replays the commits on top of the target branch for a straight-line history. A merge queue can line up pull requests for a busy branch and merge each only after its checks pass.

Conflict

A merge conflict happens when two branches changed the same part of the same file in different ways, so Git cannot decide which version wins. On GitHub the merge button stays disabled until the conflict is resolved. Simple conflicts can be fixed on the website, complex ones on your own machine, and an agent can help with either. Conflicts are the main reason to keep branches small and short-lived.

Worktree

A worktree is an additional working folder attached to the same repository, with its own branch checked out. Normally one folder shows one branch at a time. With worktrees, several folders show several branches at once, all sharing one history. That is why they matter for agents: you can run several tasks in parallel, each in its own folder, and the agents cannot overwrite each other's files. Git also stops the same branch from being checked out in two places at once.

GitHub Issues: what they can do

An issue is a tracked piece of work: a bug, a task or an idea. Think of it as the written brief that both people and agents can read. Issues in the same repository can carry the following.

Labels, assignees and milestones. Labels categorize issues. Assignees say who is responsible, and with the Copilot coding agent that can be an agent. Milestones group issues under a date-based target and show progress.

Templates and forms. Issue templates and issue forms give people a structure to fill in, so a bug report arrives with the steps and expected behavior already asked for.

Sub-issues and issue types. A large issue can be split into sub-issues, up to 100 under one parent, and organizations can classify issues as types such as Task, Bug and Feature. GitHub announced both as generally available on 9 April 2025.

Projects. GitHub Projects lays issues and pull requests out as a board or table with custom fields and filtered views, so you can see the state of the work at a glance.

Links to pull requests. A pull request that says 'Fixes #123' in its description closes issue 123 when the pull request is merged into the default branch. Several closing words work, including close, fix and resolve. That keeps the story of the work together: the issue says why, the pull request shows what.

In an AI workflow, a well-written issue is the best prompt you can give. It outlives the chat, a teammate can read it, and an agent can start from it. I describe how I use issues next to Jira in My OPC: One Person Company Implementation.

GitHub Actions: CI/CD in plain words

CI/CD stands for continuous integration and continuous delivery, or deployment. Continuous integration means every change is automatically built and tested as soon as it is proposed. Continuous delivery means a change that passes can be released, with little manual work. GitHub Actions is GitHub's built-in way to do both.

A workflow is a file in the repository that describes the automation. An event, such as opening a pull request or merging to the main branch, starts it. A workflow contains jobs, each job is a group of steps, and a runner is the machine that carries a job out. GitHub-hosted runners are provided by GitHub, and self-hosted runners are machines you run yourself.

Results appear on the pull request as checks. A check can be required, so a pull request cannot merge until it passes. Secrets, such as passwords and keys, are stored outside the code and handed to a workflow only when it asks. Environments, such as production, can add rules, for example requiring a named person to approve before a deployment runs.

Two related services are worth knowing. Dependabot opens pull requests to keep your dependencies up to date. GitHub Pages hosts a simple website straight from a repository.

Why this matters with agents: the checks do not care who wrote the code. A test that fails on an agent's change fails the same way it would on yours. Automated checks are the cheapest second opinion you have.

Guardrails that make agents safe to use

Branch protection rules and rulesets let a repository enforce its own policies. They can require a number of approving reviews, require specific checks to pass, require that conversations are resolved, keep history linear or block direct pushes to the main branch. Rulesets are the newer, more flexible form: several can apply to one branch, and the most restrictive result wins.

For agent work this is the point. Set the rules once, and every pull request, whether it comes from you, a teammate or an agent, has to pass the same gates. Admins are exempt from branch protection rules by default unless the option to prevent bypassing is turned on, so check that setting if you are the only person on the project.

How the main coding agents handle worktrees, sub-agents and context

Checked against each vendor's own documentation on 2 November 2026. These tools change quickly. Where the documentation was silent, this section says so rather than guessing. Check the linked pages before you rely on a detail.

Claude Code. Worktrees are built in: a flag starts a session in its own worktree, and a sub-agent can be told to run in a temporary worktree. Sub-agents are separate assistants with their own context window, started by Claude or by you. A sub-agent does not receive your conversation history. It gets its task message, your CLAUDE.md instructions and a snapshot of the repository's status, and only its final report comes back to the parent. A fork variant does inherit the conversation. Claude Code reads AGENTS.md only when there is no CLAUDE.md. Sessions on Anthropic's cloud push their work to a branch that you can turn into a pull request. See the Claude Code sub-agents, worktrees and memory documentation.

GitHub Copilot. The Copilot cloud agent works in a cloud environment on one branch per task and opens one pull request per task, and its documentation does not describe worktrees for it. The Copilot app, by contrast, can give each agent session its own worktree and branch. Custom agents can also act as sub-agents with their own context window, and in VS Code a sub-agent does not inherit the conversation, so the task prompt has to carry the goal and context. In the Copilot command-line tool, one command hands a task to the cloud agent, which makes a draft pull request. Copilot reads repository instruction files, including AGENTS.md. A cloud agent started from an issue reads the issue's title, description and comments at the time it starts. See the Copilot custom instructions support and cloud agent pages.

Codex. The Codex app creates managed worktrees so several chats can work in one project without interfering. A new worktree starts detached from a branch tip until you create a branch from it. Sub-agents are usually started when you ask for them, inherit the parent's sandbox and approval settings, and return summaries to the parent, which waits for all results. Codex reads AGENTS.md files from the project root down to the working folder, with closer files taking precedence, up to a default size limit. Cloud tasks each get their own workspace. See the Codex sub-agents, AGENTS.md and worktrees pages. OpenAI moved these pages from its developer site, so older links may redirect.

Google Antigravity. The main agent can start sub-agents that run at the same time. A sub-agent does not inherit the parent's conversation; it gets a role, an initial prompt and the parent's permission settings, and sends a result message back when it finishes. Each sub-agent can share the parent's workspace, or run on an isolated branch in its own worktree. Antigravity reads both AGENTS.md and GEMINI.md. Its documentation I found does not cover pull request creation, GitHub issue integration or handing a session between environments. See the Antigravity sub-agents and rules pages.

Other vibe coding platforms. Many browser-based platforms offer a GitHub connection. How each handles branches and pull requests differs, so read that platform's own documentation before you connect a repository you care about.

The common thread. None of these tools passes your whole conversation to a helper by default. What carries over reliably is what is written down: instruction files such as AGENTS.md or CLAUDE.md, the issue, the commit history and the pull request description. That is why the repository, not the chat, is the shared memory, and why writing things down in it is the highest-value habit an AI-native engineer can build.

GitHub is the bridge between your agents

Most people end up using more than one coding agent: one in the editor, one in the terminal, one in the cloud. They do not share a memory, and they do not talk to each other directly. GitHub is what they have in common.

Each of them can work against the same repository. Copilot can take an issue that is assigned to it. Claude Code can respond to an @claude mention on an issue or pull request through its GitHub Action. Codex can review a pull request when you mention it there. Each of those is documented by its vendor for its own tool. Using them together is a pattern, not an official workflow.

Several also read the same instruction file. Copilot, Codex and Antigravity read AGENTS.md, and Claude Code reads it when there is no CLAUDE.md, so one short file can brief all of them. Copilot's documentation also lists support for CLAUDE.md and GEMINI.md.

Here is how a hand-off could look, as an illustration and not a tested recipe. The issue states the work. One agent opens a draft pull request. The checks run. A second agent, or a person, reviews it. A third agent fixes what the review found. A person merges. Nothing in that chain depends on which tool did which step, because the issue, the branch, the pull request and the checks are the shared language.

One caution: the Antigravity documentation I found does not describe a GitHub integration, so treat it as working in the same repository through branches you push yourself.

Two ways GitHub work turns into opportunity

Being noticed. Zed, a code editor company, published how it hires from its own repository (Hired Through GitHub, 16 September 2025). It says it notices people who consistently ship quality pull requests, talk with the team before opening them and pair with them live. Then it reaches out. One example is Junkui Zhang, a student who wanted font ligatures in the editor. He built OpenType and font-fallback support, kept contributing for about ten months, became the top outside contributor by pull-request count, applied for an internship and joined in December 2024. Another is Anthony Eid, who started contributing as a hobby to learn Rust and joined in February 2025.

Two people also told their own stories. Josh Wulf wrote that a bug fix and a library he built around a Camunda tool led to a developer-advocate role (his account, 2019). Ogbonna Sunday wrote that three pull requests to a small project, made as part of a 30-day goal, led its CEO to message him about a contract (his account, 2023). These are single cases, not a rule.

In the AI era, the llama.cpp team joined Hugging Face. Hugging Face engineers had spent two years contributing core features, multimodal support and pull-request reviews to the project first (announcement). That is a team joining, not one person recruited. I did not find a verified first-person story of someone hired by a major AI lab from open-source pull requests, so I do not claim one. I also did not find a solid survey showing how many hiring managers check GitHub, and I leave out the percentages that circulate on recruiting blogs.

What the sources agree on is a pattern, not a guarantee. Sustained, good contributions over months count for more than one pull request. GitHub's Open Source Guides say typo and documentation fixes are valid first contributions, and that you should read a project's contributing file and link the issue you are fixing. If you used an AI tool, you are responsible for checking its output. On your own profile, GitHub lets you pin up to six repositories and add a profile README.

Building a business on open source. GitHub's guide to getting paid lists the ways projects earn: commercial support, hosted services, premium features, sponsorship and grants, and investment. Real companies show different mixes. Hugging Face keeps its Hub free and charges for advanced features and compute. Supabase publishes a free tier and a paid plan from 25 dollars a month as of November 2026. GitLab's annual filing lists subscription, license and professional services revenue.

The model has a known risk: the license. In August 2023 HashiCorp moved future releases from the Mozilla Public License to the Business Source License, saying some vendors profit without contributing back. Elastic changed its license in 2021 and in August 2024 added an open-source option again.

The takeaway: the public repository is the shop window, the issue tracker is the support desk and Actions is the release machine. But a business built on open source is one you can lose control of as well as win. Nothing in this section guarantees a job or a company.

The numbers: GitHub's own report

All figures here come from GitHub's Octoverse 2026 report, published on 28 October 2026 and covering the preceding 12 months. GitHub recalculated earlier years for this report, so do not mix them with last year's figures.

Developers pushed code to GitHub 17.9 billion times, more than in 2024 and 2025 combined. Commits across public and private repositories reached 34.3 billion, more than three times the level of two years earlier. Merged pull requests reached 1.3 billion, about 3.5 million a day. GitHub serves more than 225 million developers. GitHub Actions ran a job 1,440 times every second.

On agents specifically, GitHub reports that as of September developers started more than 40% of pull requests with an agent, up from 17% in March. It also reports that among repositories created that year, the average one with an agent configuration file logged eight times as many commits as the average new repository without one.

GitHub's explanation is that activity climbed through the year and surged around June, when better models, the tools built around them and agents that run in the cloud and keep working across days arrived together. Two cautions. First, GitHub credits AI coding agents, not vibe coding by name, so this article does too. Second, the eight-times figure is a correlation: teams that set up agents may differ in other ways, so it does not show that agents alone cause the extra commits.

A short history of Git and GitHub

April 2005. Linus Torvalds starts Git after the Linux kernel project loses free access to BitKeeper, the proprietary tool it had been using. Git's goals were speed, a simple design and strong support for many parallel branches. See the Git book's history.

21 December 2005. Junio Hamano announces Git 1.0.

2008. GitHub launches, founded by Tom Preston-Werner, Chris Wanstrath and PJ Hyett, and builds the pull request into how people share changes.

4 June 2018. Microsoft announces it will buy GitHub for 7.5 billion dollars in stock. The deal closes on 26 October 2018. See Microsoft's announcement.

11 November 2019. GitHub Actions becomes generally available, bringing automation into the same place as the code.

June 2021 and June 2022. GitHub Copilot launches as a technical preview on 29 June 2021 and becomes generally available on 21 June 2022.

19 May 2025. GitHub announces the Copilot coding agent, which you can assign an issue to; it works in the background and opens a pull request.

28 October 2026. GitHub publishes Octoverse 2026, with the figures above.

What to learn first

1. Learn the nouns: repository, commit, branch, pull request, review and merge. If you can explain each in one sentence, you can read what an agent tells you.

2. Make one change the whole way. Write an issue, put the work on a branch, open a pull request, let the checks run, review it and merge it.

3. Write the checks in. Even one simple automated test that runs on every pull request changes how much you can trust an agent.

4. Turn on protection. Require a review and a passing check before anything merges to the main branch.

5. Write an instruction file. A short AGENTS.md or CLAUDE.md that says how your project works gives every agent the same starting point.

6. Try two agents in two worktrees on two small tasks. Watch where each one needs your judgment.

Glossary

Action. A reusable step in a GitHub Actions workflow, such as checking out the code or running tests.

Agent. An AI program that plans and carries out tasks using tools, for example editing files and running tests. A coding agent does this for software.

AGENTS.md. A plain text file in a repository that tells coding agents how the project works. Several tools read it. Claude Code uses CLAUDE.md and reads AGENTS.md only when there is no CLAUDE.md.

Branch. A separate line of work that starts from another version, so changes stay apart until they are merged.

Branch protection rule. A repository setting that sets conditions for a branch, such as required reviews and passing checks before merging.

CI/CD. Continuous integration and continuous delivery: automatically building and testing every change, and releasing changes that pass with little manual work.

Clone. To make a copy of a repository on your own computer.

Commit. A saved snapshot of the project with a message describing the change.

Conflict. A situation where two branches changed the same lines differently and a person or agent must choose how to combine them.

Context window. The amount of text an AI model can consider at once. A sub-agent usually starts with its own, fresh one.

Default branch. The branch a repository treats as its main version, often called main.

Draft pull request. A pull request marked as not ready to merge.

Environment. A named deployment target in GitHub, such as production, that can have its own rules and secrets.

Fork. A separate copy of someone else's repository that is yours to change, and stays connected to the original.

Git. The version control tool that records every change to a project and supports many parallel versions.

GitHub. A service built around Git that adds Issues, pull requests, Actions and team permissions.

Issue. A tracked piece of work on GitHub: a bug, a task or an idea.

Label. A tag on an issue or pull request used to categorize it.

Merge. Bringing the changes from one branch into another.

Merge queue. A GitHub feature that lines up pull requests for a busy branch and merges each after its checks pass.

Milestone. A date-based target that groups issues and shows progress.

Pull request. A proposal to bring the changes on one branch into another, with a place for review and automated checks.

Remote. A copy of a repository kept somewhere else, usually on GitHub.

Repository. A project folder together with its full history.

Review. A person reading a pull request and responding with comments, approval or a request for changes.

Ruleset. A newer, more flexible way to set repository rules for branches and tags. Several can apply at once and the most restrictive result wins.

Runner. The machine that carries out a job in a GitHub Actions workflow, either hosted by GitHub or run by you.

Secret. A password or key stored outside the code and given to a workflow only when needed.

Squash and merge. A way of merging that combines all the commits of a pull request into one.

Status check. An automated result, such as a test run, shown on a pull request. A check can be required before merging.

Sub-agent. A helper agent started by a main agent, with its own context window, that returns a result when it finishes.

Sub-issue. A smaller issue nested under a larger one.

Workflow. A file in a repository that describes an automation in GitHub Actions: what starts it and what it does.

Worktree. An additional working folder attached to the same repository with its own branch checked out, so several tasks can run in parallel.

Notes

Product behavior was checked against vendor documentation on 2 November 2026. Sources: GitHub Docs on issues and sub-issues, linking a pull request to an issue, pull request merges, protected branches, rulesets and understanding GitHub Actions; the GitHub changelog on sub-issues and issue types; and the Copilot coding agent announcement.

History sources: the Git book, the Git 1.0 announcement on LWN, Microsoft's 2018 announcement, the GitHub Actions general availability notice and GitHub's Copilot announcements. The founding year of GitHub rests on secondary sources, so I give the year only.

The story at the top is fiction. This article is one practitioner's plain-language reference, not legal, financial or career advice. Product and company names belong to their owners, and I am not affiliated with them.