GitHub 101: The Essential Guide for Developers and Non-Technical Teammates

GitHub is where code lives - and increasingly, where content, documentation, and collaborative work lives too. If you are working with a technical team, contributing to any project that uses version control, or building your own tools with AI assistance, understanding GitHub basics is not optional. This guide covers the concepts you will actually encounter, explained in terms that make sense whether you write code or not.

What a Repository Is

A repository (or “repo”) is a project container. Think of it as a smart folder that not only stores your files but also remembers every change ever made to them - who made the change, when, and why. Everything about your project lives in the repository: code, documentation, configuration files, assets.

Most projects you work with will have one primary repository hosted on GitHub. When someone says “check the repo,” they mean that specific container with the full project history inside it.

Branches: Working Without Breaking Things

The cleanest mental model for branches: imagine your project as a tree.

Main branch (trunk): The official, production-ready version of the project. This is what users see when they visit your site or use your app.
Feature branch (a branch off the trunk): A personal copy you create to work on something specific. Changes you make on a branch do not affect the main branch until you explicitly merge them.

Why branches matter: if you work directly on main and make a mistake, the live project breaks immediately. If you work on a branch and make a mistake, nothing breaks - the main branch is untouched. Fix the mistake on your branch, then merge when ready.

A new branch costs nothing and takes seconds to create. The habit of “always work on a branch” is the single most important Git discipline.

Commits: Saving Work With Context

A commit is a saved checkpoint in your project’s history. Unlike saving a file (which overwrites the previous version), a commit adds a new entry to the timeline while keeping everything that came before it.

Every commit includes:

The exact changes made (which lines were added, removed, or modified)
A message describing what changed and why
The timestamp and author

Good commit messages matter. “Fixed stuff” is useless in three months when something breaks. “Fix dropdown overflow on mobile Safari by switching to CSS grid” tells the story.

For teams using AI agents like Claude Code, commits also serve as a record of what the agent did - making it easier to review, revert, or explain automated changes.

Pull Requests: The Review Gate

A Pull Request (PR) is a formal request to merge your branch’s changes into the main branch. It is also where collaboration happens.

The standard flow:

You complete your work on your feature branch.
You open a Pull Request on GitHub, describing what you changed and why.
A teammate (reviewer, tech lead, or owner) reviews the changes - checking for errors, unintended side effects, or anything that might break the project.
If everything looks good, they click Merge - your changes officially become part of the main codebase.

Pull Requests create a paper trail. Every decision, every review comment, every approval is documented. For AI-assisted projects, PRs are especially valuable because they give humans a review layer before automated changes reach production.

The Golden Rule: Never Push Directly to Main

If you take one thing from this guide, make it this: never push changes directly to the main branch.

The reason is simple. A single mistake pushed directly to main - even something as minor as a misplaced character - can break the live site or application immediately, for everyone. There is no buffer, no review, no safety net.

The correct workflow is always: Create branch -> Do the work -> Open PR -> Get reviewed -> Merge

This applies even if you are working alone. The branch-PR-merge workflow protects you from your own mistakes and creates a history that is easy to audit and roll back.

Setting Up an Effective Team Workflow

When developers and non-technical teammates (marketers, content writers, designers) need to work in the same repository, a clear structure prevents chaos:

Branch Naming Conventions

Consistent naming makes it clear who owns a branch and what it does:

feature/feature-name - developer building a new feature
mkt/blog-post-title - marketing team adding or updating content
fix/bug-description - anyone fixing a specific bug

Permission Structure by Role

Developers: Use VS Code, Cursor, or the terminal for direct file manipulation and code changes.

Non-technical contributors (Marketing, Content): Use GitHub Desktop (a graphical interface that removes the need for command-line knowledge) or edit Markdown files directly in the GitHub web interface. Both approaches let you make changes, commit, and open PRs without touching the terminal.

Enable Branch Protection Rules

In your repository’s Settings, enable Branch protection rules for main. This setting requires all changes to go through a Pull Request with at least one reviewer approval before merging. It is the automated enforcement of the “never push directly to main” rule - no one can accidentally bypass the review step.

GitHub and AI Workflows

One reason GitHub knowledge has become more relevant for non-developers in 2026 is how deeply AI tools integrate with it.

AI coding agents like Claude Code or Cursor work directly with Git repositories - reading files, creating branches, writing commits, and opening PRs as part of their automated workflows. When you use an AI agent to build or maintain a project, understanding what it is doing in Git terms is necessary for oversight. When the agent says it is creating a branch or making a commit, you need to know what that means to review and approve its work appropriately.

GitHub is also where Skills, prompts, and AI configuration files get shared and versioned. The SKILL.md files that define Claude Agent Skills are plain text files that live in repositories - making GitHub the collaboration layer for AI workflows as much as for code.

FAQ

Do I need to use the terminal to work with GitHub?

No. GitHub Desktop provides a full graphical interface for most Git operations - creating branches, making commits, opening pull requests. The GitHub web interface also lets you edit files, commit changes, and manage PRs entirely in the browser. Terminal knowledge helps you move faster and handle edge cases, but it is not required to participate meaningfully in a GitHub workflow.

What is the difference between Git and GitHub?

Git is the version control system - the underlying technology that tracks changes and manages branches. GitHub is a hosting platform built on top of Git, adding a web interface, collaboration tools (pull requests, code review, issues), and cloud storage. You use Git commands to manage your local repository; you use GitHub’s web interface or API to collaborate with others.

What happens if two people change the same file at the same time?

This creates a merge conflict - Git detects that both changes cannot be automatically combined and flags the conflicting lines. One person needs to manually review both versions and decide which to keep (or write a new version that incorporates both). It sounds scary but is routine in collaborative development. Good branch discipline (keeping branches short-lived and focused on one thing) minimizes how often conflicts occur.

How do I undo a mistake after committing?

Git has several tools for this depending on the situation. If the mistake has not been merged to main yet, you can revert the commit (which creates a new commit undoing the changes) or reset to a previous state on your branch. If the mistake has been merged, you create a revert PR that undoes the changes cleanly. The important thing is that Git’s history-based model means you almost never truly lose work - there is nearly always a way back.

Does the branch protection rule slow down solo projects?

Slightly, but it is worth it. Even working alone, branch protection forces you to review your own changes as a PR before merging. This brief review step catches a surprising number of small mistakes. For solo projects with AI agents making frequent commits, branch protection is especially valuable - it gives you a structured review point before automated changes reach production.