GitHub Deep Dive Part 1: Repositories, Branches, Pull Requests & the Collaboration Model

GitHub Fundamentals Deep Dive - Repositories, Branches, Pull Requests and Issues

📘 GITHUB DEEP DIVE SERIES

▸ Part 1: Repositories, Branches & Pull Requests YOU ARE HERE
Part 2: GitHub Actions, Workflows & OIDC →
Part 3: Packages, Container Registry & Security →

Note: This is Part 1 of a three-part deep dive into GitHub. Part 2 covers GitHub Actions in depth, and Part 3 covers GitHub Packages and Security.

GitHub started in 2008 as a hosted Git service and has since become the central nervous system of modern software development, used by more than 100 million developers across millions of organizations. While many treat it as a code host with some extras, GitHub is really a tightly integrated platform combining version control, code review, project management, automation, package distribution, and security tooling. This article is a deep dive into the foundational layer: repositories, branches, pull requests, and the collaboration model that everything else builds on.

1. Git vs GitHub: Setting the Mental Model

Git is the distributed version control system invented by Linus Torvalds in 2005. GitHub is a hosting platform built on top of Git that adds a web UI, access control, collaboration features, automation, and a vast ecosystem of integrations. You can use Git without GitHub, but you cannot use GitHub without Git as the underlying engine.

THE STACK

Git (the protocol)
Local repositories, commits, branches, merges. Works offline. Identical across all hosting providers.

GitHub (the platform)
Cloud hosting, PRs, Issues, Actions, Packages, Pages, security, identity, billing, API.

2. Anatomy of a GitHub Repository

A repository ("repo") is the unit of project organization on GitHub. It contains the Git history plus a rich set of metadata: issues, pull requests, releases, wiki pages, projects, discussions, security advisories, and configuration like CODEOWNERS, branch protection rules, and workflows. Repositories can be public, private, or internal (visible only to members of an enterprise).

Repository Surface Area

my-repo/
  .github/                    -- GitHub-aware config
    workflows/              -- GitHub Actions YAML
    CODEOWNERS              -- review routing
    ISSUE_TEMPLATE/         -- issue forms
    PULL_REQUEST_TEMPLATE.md
    dependabot.yml          -- update automation
  src/                        -- your code
  tests/
  README.md                   -- project front page
  LICENSE                     -- open-source license
  SECURITY.md                 -- vulnerability disclosure
  CONTRIBUTING.md             -- contributor guide
  .gitignore

3. Branches and Branching Strategies

Branches are independent lines of development inside a repository. Modern teams generally pick one of three strategies depending on team size, release cadence, and risk tolerance.

Branching Strategy Comparison

Strategy	Branches	Best For	Trade-offs
Trunk-based	main + short-lived	CI/CD-heavy teams	Requires strong tests, feature flags
GitHub Flow	main + feature	Web apps, continuous deploy	No explicit release branches
Git Flow	main, develop, release/, hotfix/	Versioned software, mobile apps	Complex, slower throughput
Release Flow	main + release/* per train	Large products with cohorts	Cherry-pick discipline required

4. Pull Requests: The Heart of Collaboration

A pull request (PR) is the GitHub wrapper around a Git diff: a proposed change from one branch into another, paired with discussion, code review, automated checks, and merge controls. The PR is the single most important workflow object on GitHub - it is where code review happens, where CI runs, where required reviewers and status checks are enforced, and where the audit trail lives.

PULL REQUEST LIFECYCLE

1. Branch from main

2. Commit + Push

3. Open PR

4. CI runs / Reviewers

5. Address feedback

6. Approved

7. Merge

GitHub provides three merge modes, each with very different implications for the resulting history:

Merge Modes Compared

Merge commit
Preserves the branch shape with a merge node. Good for tracing PRs to commits.

Squash & merge
Collapses the PR into one commit on main. Clean linear history. Most popular.

Rebase & merge
Replays each commit onto main. Linear, preserves individual commits.

5. Code Review: CODEOWNERS, Required Reviewers, and Suggestions

Code review on GitHub is implemented through the PR Review system. You can leave inline comments, suggest changes (which the author can apply with one click), request changes (a blocking state), or approve. Beyond ad-hoc review, teams use two main mechanisms to enforce quality:

CODEOWNERS - A file at .github/CODEOWNERS mapping path patterns to owners. When a PR touches a path, the matching owners are auto-requested as reviewers.
Branch protection rules - Require N approvals, require CODEOWNER approval, require status checks, require linear history, require signed commits, and forbid force-pushes.

# .github/CODEOWNERS
*                       @org/maintainers
/src/auth/              @org/security-team
/infrastructure/        @org/platform-team @alice
*.tsx                   @org/frontend
/.github/workflows/     @org/devops

6. Issues, Projects and Discussions

Issues are the GitHub lightweight tracker. They support labels, assignees, milestones, linked PRs, sub-issues, and now Issue Forms: structured YAML-defined templates that produce typed inputs. Issues feed into GitHub Projects, a flexible tracker (kanban / table / roadmap views) that can pull from multiple repos and add custom fields, iterations, and automation. Discussions provide a forum-style space for Q&A, polls, and announcements separate from actionable work.

Tracking Surface

Issues
Bugs, tasks, feature requests. Per-repo, with labels & milestones.

Projects
Cross-repo planning. Kanban, tables, roadmaps. Custom fields, iterations.

Discussions
Async Q&A, polls, announcements. Not tied to code changes.

7. Forking and the Inner / Outer Loop

A fork is a server-side copy of a repository under another account, with a tracked relationship to the upstream. Forks power open-source contribution: you fork, push to your fork, then open a cross-repo PR back to the original. Inside organizations, forks are also useful for sandboxing and for repos with restricted write access.

FORK-BASED CONTRIBUTION

Upstream
org/repo

--> fork

Your fork
you/repo

--> branch + commit

PR
back upstream

8. Releases and Tags

Tags are immutable Git pointers to specific commits, typically used for versions like v1.2.0. GitHub Releases build on top of tags by adding release notes (auto-generated from PRs and commits), binary attachments, and a public landing page. The Releases API is what package managers, installers, and update systems integrate with.

9. Codespaces and Dev Containers

GitHub Codespaces is a cloud development environment that boots a containerized VS Code workspace directly from a repository. Configuration lives in .devcontainer/devcontainer.json, ensuring every contributor gets the same toolchain (node version, Python interpreter, extensions, environment variables, and pre-installed dependencies) in seconds.

// .devcontainer/devcontainer.json
{
  "name": "Node.js + TypeScript",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/github-cli:1": {},
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  },
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  },
  "forwardPorts": [3000]
}

10. The GitHub API and CLI

Everything you can do in the GitHub UI is exposed through the REST API, the GraphQL API, and the gh command-line tool. The CLI is especially useful for scripting and CI tasks - listing PRs, downloading run logs, creating issues, dispatching workflows, and managing releases.

# Create a PR from current branch
gh pr create --base main --title "Fix login bug" --body "Closes #142"

# List open PRs that need your review
gh pr list --search "review-requested:@me is:open"

# Trigger a workflow_dispatch run
gh workflow run deploy.yml --ref main -f environment=staging

# Stream logs of the most recent run
gh run watch

11. Permissions: Personal, Organization and Enterprise

GitHub has three tiers of access. Personal accounts own their own repos. Organizations group repos, teams, and billing under a namespace, with role-based permissions (Owner, Member, Outside Collaborator) and Teams that map to PR review and CODEOWNERS routing. Enterprise accounts sit above organizations and add SSO/SAML, SCIM provisioning, audit log streaming, IP allow lists, and centralized policy.

Access Hierarchy

Personal
Individual repos, free private repos, public OSS.

Organization
Teams, role-based access, billing, audit log.

Enterprise
SSO, SCIM, policy, audit streaming, IP allow lists.

Conclusion

Underneath the visual polish, the GitHub collaboration model is remarkably consistent: a repository contains Git history and metadata, branches isolate work, pull requests propose changes with review and automation gates, and orgs/teams/CODEOWNERS define who can do what. Master these primitives and the more advanced layers (Actions, Packages, Security, and Copilot) all become much easier to reason about. Part 2 of this series covers GitHub Actions in depth: workflows, runners, matrix builds, caching strategies, reusable workflows, and secure deployments with OIDC.