GitHub

GitHub is the place most of the world's code lives. It hosts Git repositories, gives every project a home with issues, pull requests, and code review, and wraps the whole thing in collaboration tooling so a team (or a solo founder with a fleet of agents) can propose, review, and merge changes in the open or in private. On top of hosting it runs GitHub Actions for CI/CD, stores release artefacts and packages, and bundles AI tooling through Copilot.

Where it fits

GitHub is for anyone who ships code and wants a durable, reviewable history of every change. Open-source maintainers practically have to be here, because it is where contributors already are. Product teams use it as the spine of their delivery pipeline: branch, pull request, review, automated checks, merge, deploy. For a one-person agentic setup like mine, it doubles as the coordination layer, every change becomes a reviewable unit instead of an untracked edit, which matters when agents are doing the writing.

It is useful beyond engineering too: a clean home for docs, infrastructure configs, and anything that benefits from version history and review. It is not the right tool if you want a visual project board as your primary surface (the issues are capable but Linear or Notion feel better for pure planning), and it is overkill for someone who never branches and just wants a backup of one folder.

The honest take

The strength is gravity. GitHub is the default, so integrations, CI providers, hosting platforms, and AI coding tools all assume you are on it, and that compounding ecosystem is the real product. Pull requests and code review are excellent, Actions covers most CI/CD needs without a second tool, and the platform is reliable at a scale very few alternatives match. The community network effect is hard to overstate: being where contributors and employers already look is itself the value.

The trade-offs are real. Actions configuration can get fiddly and surprising as usage grows, and complex workflows turn into YAML you maintain forever. Issues are functional but not a substitute for a dedicated planning tool once a roadmap gets serious. The platform is owned by Microsoft, which is fine for most but worth a conscious thought if vendor concentration matters to you. It has a free tier with generous private-repo access, and paid plans for teams and advanced features.

INTERVIEW EWOUD: What is your personal verdict on GitHub, and what star rating out of five would you give it?

INTERVIEW EWOUD: Is GitHub in your own stack, and if so, what specifically do you use it for in the agentic setup?

INTERVIEW EWOUD: What is the one line you would tell a peer who is deciding whether to commit to it?

This guide gets you from "I have an account" to running GitHub as the spine of how your software actually ships: code stored safely, changes reviewed properly, releases that you can trace, and automation that does the boring work for you. It is written for founders, operators, and small technical teams who want GitHub set up the way a serious shop runs it, not just a place to dump files. You do not need to be a deep engineer to follow it, but you will come out treating GitHub as an operating system for building, not a backup drive.

Getting set up

The first real decision is the unit you organise around. GitHub gives you personal accounts and organisations, and for anything beyond a solo side project you want an organisation. An org gives you central ownership of repositories, team-based permissions, and billing that survives any one person leaving. Create the org early, even as a team of one, because moving repos and rewiring access later is friction you do not need.

Inside the org, think in repositories, and resist the urge to cram everything into one. A repository is the boundary for code, history, issues, and access, so let each product or service have its own. Decide your default branch name and stick to it across every repo (main is the sensible standard), because your automation and your team's muscle memory both depend on consistency.

Lock down access before you write a line. Use teams to grant permissions in groups rather than adding individuals one at a time, give people the least access that lets them work, and reserve admin for the few who genuinely need it. Turn on protection for your default branch so nothing merges into it without passing your rules: require reviews, require status checks to pass, and forbid direct pushes that skip the process. This single step is what separates a repo that stays clean from one that rots.

Finally, get authentication right at the start. Set up SSH keys or a token for your local machine, enable two-factor authentication on every account, and store any secrets your projects need in the repository or org secrets store, never in the code itself. A leaked key in your history is painful to remove, so prevent it rather than clean it up.

How to actually use it

The core loop is simple and you run it every single day, so internalise the order. You start from an up-to-date copy of the default branch, you create a new branch for the change you are about to make, you commit your work in small steps with clear messages, you push that branch up, and then you open a pull request.

The pull request is where GitHub earns its keep, so treat it as the centre of your workflow rather than a formality. A pull request is a proposal: it shows exactly what changed, lets others comment line by line, runs your automated checks, and records the decision to merge. Write a description that says what the change does and why, link the issue it closes, and let your reviewers and your checks do their job before anything lands on the default branch.

Use issues to track the work itself. An issue is a unit of intent: a bug, a task, a feature request, each with its own discussion, labels, and assignee. Connect issues to pull requests so that merging a change automatically closes the work it resolves, and you get a paper trail that explains not just what the code is but why it became that way.

Once that loop is comfortable, layer in releases. When a set of changes is ready for the world, tag it and cut a release with notes describing what changed. This gives you a named, retrievable point in history, which matters the moment you need to answer "what was live last Tuesday" or roll back to a known-good state.

Power moves

The first power move is GitHub Actions, the built-in automation that runs on events in your repo. Wire up a workflow that runs your tests and checks on every pull request, so a change cannot merge unless it passes. Once that habit is set, extend it to deploy automatically when you merge to your default branch, and you have continuous delivery without paying for a separate tool.

Protect your default branch with required status checks tied to those Actions, so the protection rule and the automation reinforce each other: nothing merges unless the checks are green, and the checks run automatically. This is the configuration that lets you move fast without breaking the main line.

Turn on the security features that GitHub gives you, because they catch problems you will not. Secret scanning watches for credentials accidentally committed, dependency alerts tell you when a library you rely on has a known vulnerability, and automated dependency updates open pull requests to bump those libraries for you. For a small team, this is a security function you do not have to staff.

Learn the search and the API. GitHub's search across code, issues, and pull requests is powerful once you know the qualifiers, and the API (plus the official CLI) lets you script the repetitive parts: opening issues from another system, querying which pull requests are stuck, automating release notes. The pros automate the admin so they spend their attention on the code.

Where it fits your stack

GitHub sits at the centre of a building stack and connects outward in every direction. It is the source of truth that your deployment platform watches, so a host like Vercel, Netlify, or a cloud provider builds and ships the moment you push, which means your repo and your live site stay in lockstep.

It connects to your planning and communication tools so the work is visible where your team already is. Issues and pull requests can sync to a project board, post updates into Slack, and feed status into a project-management tool, which keeps the people who do not live in code informed without anyone copying updates by hand.

For a growth and ops setup specifically, GitHub is where your marketing site, your tracking code, your landing pages, and your internal tooling all live and version, so a change to a pixel or a page goes through the same review-and-ship discipline as any product change. That discipline is the point: one place where every change is proposed, reviewed, recorded, and shipped, instead of edits scattered across half a dozen dashboards.

Pitfalls to avoid

The most common mistake is committing secrets, and the fix is prevention: keep keys and tokens in the secrets store and add a check that scans before they ever land. The second is letting the default branch become a free-for-all, which you avoid by turning on branch protection on day one rather than after the first painful mistake.

Watch out for giant pull requests that nobody can review properly, because a five-thousand-line change gets a rubber-stamp approval, not a real one. Keep changes small and focused so review stays meaningful. Equally, do not let pull requests rot open for weeks; stale branches drift from the main line and become harder to merge the longer they sit.

Finally, do not treat GitHub as a passive archive. The value is in the workflow (the reviews, the checks, the automation, the traceable history), and a team that pushes straight to main and skips all of it is paying for a tool while throwing away what makes it worth having.

INTERVIEW EWOUD: How do you structure your GitHub org and repos across your ventures, and what are your actual branch-protection and review rules?

INTERVIEW EWOUD: Which GitHub Actions workflows do you rely on most, and how do they connect to your deploy setup?

INTERVIEW EWOUD: What is the one hard-won GitHub habit or configuration you would tell another solo founder to set up before anything else?

Technical teams and founders automating build, test, deploy, and repository workflows where the code already lives in GitHub

GitHub is a code hosting platform whose Actions feature provides YAML-defined CI/CD and workflow automation triggered by repository events such as pushes, pull requests, and schedules. It is aimed at software teams and technical founders who want to automate builds, tests, deployments, and other developer workflows alongside their source code. Workflows run on GitHub-hosted or self-hosted runners and can call any public API.