cmc/cleberg.net
My personal web garden & blog.
clone: git clone https://gitbay.org/cmc/cleberg.net.git
main: content/blog/2026-05-20-git-is-not-github.org · raw
1#+date: [2026-05-20 Wed 11:56:00]
2#+title: Git Is Not GitHub
3#+description: Git tracks code history. GitHub and other Git hosts add collaboration, access, review, and workflow controls around it.
4#+slug: git-is-not-github
5#+filetags: :development:
6
7* Git Is Not GitHub
8
9People often use "Git" and "GitHub" interchangeably. Sometimes it's for
10convenience, but often it's a genuine lack of clarity around these two concepts.
11I work with IT auditors daily and you'd be surprised how often I come back to
12explain this topic, which is why I've written an internal document and am
13rolling that into this blog post itself to share with a broader audience.
14
15The simplest possible explanation I can provide is that Git is the version
16control system itself, while GitHub is one of many platforms that offer Git
17hosting, as well as custom features that improve functionality on top of Git
18(e.g., pull requests).
19
20The distinction matters, especially in an audit context, because there are facts
21and features inherent to Git that should be clearly understood before thinking
22about the Git host. For an auditor, this affects decisions around risk
23assessment, procedures to obtain evidence, and documentation of control
24processes.
25
26For example, a developer can create a commit in Git after changing some code or
27files with a repository. This does *not* automatically show that the change was
28reviewed, approved, tested, or deployed through the appropriate process(es).
29
30* Feature Comparison
31
32Let's start by comparing features before we dive into the details. While this is
33not all-encompassing, it helps set the context for the discussion we're about to
34have.
35
36| Feature / activity | Git | Git host |
37|---------------------------------------+-----+----------|
38| Track file changes | ✓ | |
39| Create commits | ✓ | |
40| View commit history | ✓ | ✓ |
41| View file diffs | ✓ | ✓ |
42| Create branches | ✓ | |
43| Merge branches | ✓ | |
44| Rebase commits | ✓ | |
45| Tag releases or versions | ✓ | ✓ |
46| Clone a repository | ✓ | |
47| Push and pull changes | ✓ | ✓ |
48| Store a shared remote repository | | ✓ |
49| Browse repository in a web UI | | ✓ |
50| Pull requests / merge requests | | ✓ |
51| Code review comments | | ✓ |
52| Reviewer approvals | | ✓ |
53| Branch protection rules | | ✓ |
54| Required status checks before merge | | ✓ |
55| User and team access management | | ✓ |
56| Repository admin roles | | ✓ |
57| Audit logs | | ✓ |
58| CI/CD pipelines | | ✓ |
59| Deployment environments | | ✓ |
60| Secrets / environment variables | | ✓ |
61| Issue tracking | | ✓ |
62| Project boards | | ✓ |
63| Security scanning / dependency alerts | | ✓ |
64
65#+begin_quote
66Git hosts vary by platform. GitHub uses "pull requests," while GitLab commonly
67uses "merge requests." The concept is similar, but the available controls,
68terminology, logs, and evidence differ by host.
69#+end_quote
70
71* Git Tracks the History
72
73Now that we have looked at the feature comparison, let's dive into the details
74of both Git and Git hosts.
75
76[[https://git-scm.com][Git]] is a distributed version control system. It is intended to track changes to
77files over time through a feature called a *commit*: a collection of changes to
78files since the last commit. Developers use it to create these commits, create
79branches, merge changes back into the primary branch, rebase work, tag versions,
80and inspect project history.
81
82Git does not require GitHub, or any other hosting platform. It can run entirely
83on a developer's laptop. A repository can exist locally, on an internal server,
84on a shared network path, or on another Git host.
85
86For example, I can create a local Git repository, expose it through the Git
87protocol, and share this info with a friend or coworker. Then, they can clone my
88repository and we can collaborate by making changes independently and using
89commits, branches, etc. to push changes back and forth with each other. In this
90scenario, there is *no* host and we are essentially a distributed network of our
91own.
92
93At its core, Git answers technical history questions:
94
95- What changed?
96- Who authored the change?
97- When was the change made?
98- What files were affected?
99- What does this version contain?
100- How did this branch differ from that branch?
101
102That is valuable, but it is not the whole development process. This is where Git
103hosts introduce useful, additional features on top of Git.
104
105* Git Hosts Add the Workflow
106
107A Git host stores Git repositories and adds collaboration, workflow, and
108governance features around them. In an audit or compliance context, this is
109where most of the controls originate that mitigate risks with the system
110development lifecycle (SDLC).
111
112GitHub is the most familiar example, so I will use that in this post, but it is
113not the only one. Other Git hosts include GitLab, Bitbucket, Azure DevOps Repos,
114Sourcehut, Gitea, and Forgejo.
115
116These platforms commonly add features such as:
117
118| Feature | Purpose |
119|---------------------------------+---------------------------------------------------------------------------------------------------|
120| Pull requests or merge requests | Propose changes, review them, and merge them into a target branch. |
121| Code review comments | Allow reviewers to comment on specific lines, files, or overall changes. |
122| Reviewer approvals | Record that one or more reviewers approved a proposed change before merge. |
123| Branch protection rules | Restrict how important branches can be changed, such as preventing direct pushes or force pushes. |
124| Required status checks | Require tests, builds, scans, or other checks to pass before a change can be merged. |
125| User and team permissions | Control who can read, write, maintain, or administer repositories. |
126| Audit logs | Record important administrative, access, repository, and workflow events. |
127| Issue tracking | Track bugs, enhancements, tasks, and other development work items. |
128| Project boards | Organize work items by status, priority, sprint, release, or team workflow. |
129| CI/CD integrations | Build, test, package, or deploy code through automated pipelines. |
130| Secrets management | Store sensitive values used by workflows, such as tokens, keys, and credentials. |
131| Security scanning | Identify risks such as exposed secrets, vulnerable dependencies, and insecure code patterns. |
132
133That is why the same Git repository can behave differently depending on where it
134is hosted. GitHub, GitLab, Bitbucket, Azure DevOps, and Sourcehut all support
135Git repositories, but their review workflows, permissions, logs, automation, and
136terminology differ.
137
138* Audit Implications
139
140Using GitHub as an example, let's walk through a common audit approach to the
141common change management (CM) or program development (PD) controls.
142
143First, here are some common controls:
144- Changes are reviewed and approved prior to deployment.
145- The repository is configured to:
146 - prevent force pushes;
147 - require X approvals;
148 - prevent approvals from the author or a person who committed within the
149 pull request;
150 - require testing to pass prior to merging;
151 - include the relevant change ticket(s)/documentation.
152- Users with development access are segregated from users with access to approve
153 and deploy changes.
154 - /OR/: Management performs a review on an XYZ basis to ensure deployed
155 changes were authorized and appropriate.
156- Management performs a review on an XYZ basis to ensure branch protection
157 settings were not inappropriately modified.
158
159Now, where can we find this evidence? Let's step through each
160- Normally, reviews and approvals can be found directly within the pull/merge
161 request. For platforms such as GitHub, this platform enables code reviews,
162 comments, feedback, and checks directly within the PR flow. In certain cases,
163 this may be documented in a change ticket system and the ticket is referenced
164 within the PR to prove that the PR was tested, reviewed, and approved prior to
165 merging.
166- For configurations, GitHub supports both [[https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule][classic branch protection rules]] and
167 [[https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets][rulesets]], which can enforce all of the checks I mentioned above.
168- For access, it depends on the company's setup. They may be using GitHub
169 Enterprise, which offers them more control over access, and teams can inspect
170 the access inheritance through those Enterprise settings. Otherwise,
171 non-enterprise GitHub organizations can show evidence of access at both the
172 organization level and the repository level. Auditors can inspect the levels
173 of access and inheritance to ensure that no users have the ability to develop
174 changes, manage branch protections, approve changes, and deploy changes.
175- For branch protection settings, management can provide auditors with an export
176 of the audit logs relevant to the in-scope repositories. This will show you if
177 any events occurred that would have disabled or modified the branch
178 protections in place.
179
180If you're inspecting a project where CI/CD pipelines matter, you can also dive
181into the team's configuration of their pipeline in terms of the logic, access to
182modify, and any relevant schedules or triggers.
183
184* Conclusion
185
186Hopefully at this point, it's clear that Git is not GitHub. While they are
187related and can be confusing for non-developers, it's important to understand
188the distinction.
189
190Without this understanding, everything can fall apart in your understanding,
191risk assessment, and scoping of an audit.