GitHub Pull Request & CI/CD Pipeline

Git stores every file as a blob, every directory as a tree, and every snapshot as a commit — all addressed by their SHA-1 hash. Two files with identical content share a single blob object regardless of filename or location. Trees are lists of (name, mode, SHA-1) entries pointing to blobs and sub-trees. A commit points to a tree (the full snapshot) plus parent commits (history). This content-addressable model provides automatic deduplication, trivial integrity verification (hash the object and compare), and efficient diff computation (unchanged subtrees share the same SHA-1).

Storing every version of every file as a full blob would be prohibitively expensive. Git's packfile format compresses objects using delta encoding — storing only the binary difference between similar objects. The packing algorithm finds the best delta base for each object (often a previous version of the same file). A single packfile for a large repository might contain millions of objects compressed to a fraction of their uncompressed size. GitHub's storage layer runs aggressive repacking in the background, and packfile indices enable O(log N) object lookup without decompressing the entire pack.

When a developer pushes commits, GitHub's event system generates a push event and fans it out as HTTP POST webhooks to every registered receiver — CI services, deployment tools, chat bots, and monitoring systems. A popular organization might have dozens of webhook endpoints per repository. GitHub's webhook delivery system uses a queue-based architecture with at-least-once delivery guarantees, automatic retries with exponential backoff for failed deliveries, and a webhook delivery log for debugging. Idempotency is the receiver's responsibility — CI systems must handle duplicate webhook events gracefully.

The Check Suites API allows multiple CI providers (GitHub Actions, CircleCI, Jenkins) to report test results for a single commit. Each provider creates Check Runs within a Check Suite, reporting status (queued, in_progress, completed), conclusion (success, failure, neutral), and rich output (annotations on specific lines of code). Branch protection rules can require specific check suites to pass before a PR is mergeable. This abstraction decouples GitHub from any specific CI provider — teams can use multiple CI systems simultaneously and see unified status on the pull request page.

Without a merge queue, two PRs can each pass CI independently but break when merged together (semantic conflicts that don't produce Git merge conflicts). GitHub's merge queue serializes merges: when a PR is enqueued, it's rebased on top of the current queue head and CI runs against the combined result. If CI passes, the PR is merged; if it fails, it's removed from the queue. This guarantees that every commit on main has passed CI in the exact context it will land in. The trade-off is increased merge latency — PRs wait for preceding queue entries to complete.