04 — Version Control and Repo Hosting — Git the Engine, GitHub the Collaboration

"Just push to GitHub" was the whole of my version-control model, and it never explained a single confusing Git error. Separating two things I'd fused is what did: Git is the engine, a local data structure that records snapshots of your code; GitHub, GitLab, and Bitbucket are the collaboration layer bolted on top. [1][5] Conflating them is the single biggest blocker to actually understanding either.

The frame that fixed it is ownership. Git runs on my laptop. It's a command-line program that writes to a hidden .git directory — a local database of every commit, branch, and tag I've made. I can use Git for a project no one else ever sees, with no network and no account. The hosting platform is a separate product: a website that stores a copy of my Git repository and adds a UI for humans to coordinate around it — pull requests, issues, code review, CI. The platform depends on Git; Git does not depend on the platform.

Git: snapshots, not diffs

The single idea that made Git click for me: a commit is a snapshot of your entire project at a moment, not a diff against the previous version. [2] Internally Git stores a full tree of files per commit; the diffs are computed on demand for efficiency. This is why branching is cheap in Git — a branch is just a movable pointer to a commit, and creating one doesn't copy any files.

A few mechanics I had to nail down:

• The three areas. Working directory (what I see), staging area / index (what I've marked for the next commit), and the repository (the committed history). git add moves from working to staging; git commit moves from staging to history.
• Branches are pointers. A branch name points at one commit. HEAD points at the branch I'm currently on. Switching branches moves HEAD and updates my working directory.
• History is a DAG. Commits form a directed acyclic graph. A merge commit has two parents. This is why Git history can be non-linear and why rebasing (rewriting commits onto another base) is possible but rewrites history.

The everyday commands are a small surface: status, add, commit, log, branch, checkout/switch, merge, push, pull, fetch. The power commands (rebase, cherry-pick, reflog, reset) come later, and they're all operations on the same snapshot DAG.

Distributed: every clone is a full repository

Git is distributed — every clone is a full-fledged repository with complete history [2]. I can commit, branch, and merge with no network connection. The git push and git fetch commands move commits between repositories (typically mine and a hosted one), but the local repository is autonomous.

This is the part the central-platform way of thinking hides. When I git push origin main, I'm sending my new commits to another repository that happens to live on GitHub's servers. When I git fetch, I'm pulling theirs down. The platform is a peer in this exchange — a very visible peer, but architecturally just another repository. If GitHub disappeared tomorrow, my local .git directory would still contain my entire project history.

The hosting platforms: collaboration on top of the engine

GitHub is the dominant hosting platform — Microsoft-owned, with repositories, pull requests, issues, GitHub Actions for CI, and a near-monopoly on open-source visibility [3]. If I'm reading or contributing to public open source, it's almost certainly on GitHub. The pull request (PR) is GitHub's killer feature: a proposed change from one branch, with diff view, line-by-line review, and merge controls. PRs are GitHub's UI, not Git's — Git has no concept of a pull request.

GitLab is the closest competitor and the one that differentiates by being all-in-one DevOps — source control, CI/CD, issue tracking, container registry, and security scanning in a single application [4]. GitLab is also notable for offering a self-hosted option (the open-source GitLab CE/EE), which matters for organizations that can't or won't put their code on someone else's servers. For shops that want one platform for the whole development lifecycle, GitLab's integration is a real advantage.

Bitbucket (Atlassian) is the third major option, tightly integrated with Jira and the Atlassian suite, and a common choice in enterprise shops already on Atlassian tooling.

The choice between them is rarely about Git — they all speak Git fluently. It's about the collaboration features, the CI integration, the issue tracker, the hosting model (cloud vs self-hosted), and where the team already is.

Pull requests: where the platform earns its keep

The pull request is the workflow feature that makes the hosting layer more than storage. The pattern:

1. I create a feature branch off main and commit my changes locally.
2. I git push the branch to the hosted repository.
3. I open a pull request on the platform — a page showing my branch's diff against main, with space for review comments.
4. Reviewers comment; I push more commits to the same branch (the PR updates automatically).
5. When approved, the platform merges the branch into main (or via a squash/rebase merge).

Steps 3–5 are platform features, not Git features. The same merge could be done locally with git merge, but the PR adds the human review and CI gating that make team development workable. CI pipelines (GitHub Actions, GitLab CI) typically run on every PR, blocking merge until tests pass.

How I use this

The separation of engine from platform shapes how I work day to day:

• Commit locally, often. Commits are free and local. I commit small, logical units as I go, before pushing anything. The DAG is mine to shape with rebase before anyone else sees it.
• Treat the platform as the coordination point. PRs are where review happens; I don't push directly to main on anything with more than one contributor.
• Pick the platform by the team and the workflow, not by Git. Open source → GitHub. Self-hosted full DevOps → GitLab. Atlassian shop → Bitbucket. The Git underneath is identical.
• Learn Git itself, not just the platform UI. When a PR has conflicts, the resolution happens in Git, locally. The reflog has saved me more than once from mistakes the platform UI can't undo.

The habit that matters most: when something breaks, I ask whether it's a Git problem (the engine, the local DAG) or a platform problem (the PR, the CI, the permissions). They fail in different ways and need different fixes.

References

[1] Atlassian, "What is version control?," 2024. [Online]. Available: https://www.atlassian.com/git/tutorials/what-is-version-control

[2] "Tutorial: Git for Absolutely Everyone," The New Stack. [Online]. Available: https://thenewstack.io/tutorial-git-for-absolutely-everyone/

[3] GitHub, "GitHub Documentation." [Online]. Available: https://docs.github.com

[4] GitLab, "GitLab Documentation." [Online]. Available: https://docs.gitlab.com/

[5] roadmap.sh, "Repo Hosting Services — Backend Roadmap." [Online]. Available: https://roadmap.sh/backend/repo-hosting-services