Commit 56af05b90b
Verified · cmc
Layout: unified · split
content/blog/2026-05-20-git-is-not-github.org added +191
| @@ -0,0 +1,191 @@ | ||
| 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 | ||
| 9 | People often use "Git" and "GitHub" interchangeably. Sometimes it's for | |
| 10 | convenience, but often it's a genuine lack of clarity around these two concepts. | |
| 11 | I work with IT auditors daily and you'd be surprised how often I come back to | |
| 12 | explain this topic, which is why I've written an internal document and am | |
| 13 | rolling that into this blog post itself to share with a broader audience. | |
| 14 | ||
| 15 | The simplest possible explanation I can provide is that Git is the version | |
| 16 | control system itself, while GitHub is one of many platforms that offer Git | |
| 17 | hosting, as well as custom features that improve functionality on top of Git | |
| 18 | (e.g., pull requests). | |
| 19 | ||
| 20 | The distinction matters, especially in an audit context, because there are facts | |
| 21 | and features inherent to Git that should be clearly understood before thinking | |
| 22 | about the Git host. For an auditor, this affects decisions around risk | |
| 23 | assessment, procedures to obtain evidence, and documentation of control | |
| 24 | processes. | |
| 25 | ||
| 26 | For example, a developer can create a commit in Git after changing some code or | |
| 27 | files with a repository. This does *not* automatically show that the change was | |
| 28 | reviewed, approved, tested, or deployed through the appropriate process(es). | |
| 29 | ||
| 30 | * Feature Comparison | |
| 31 | ||
| 32 | Let's start by comparing features before we dive into the details. While this is | |
| 33 | not all-encompassing, it helps set the context for the discussion we're about to | |
| 34 | have. | |
| 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 | |
| 66 | Git hosts vary by platform. GitHub uses "pull requests," while GitLab commonly | |
| 67 | uses "merge requests." The concept is similar, but the available controls, | |
| 68 | terminology, logs, and evidence differ by host. | |
| 69 | #+end_quote | |
| 70 | ||
| 71 | * Git Tracks the History | |
| 72 | ||
| 73 | Now that we have looked at the feature comparison, let's dive into the details | |
| 74 | of 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 | |
| 77 | files over time through a feature called a *commit*: a collection of changes to | |
| 78 | files since the last commit. Developers use it to create these commits, create | |
| 79 | branches, merge changes back into the primary branch, rebase work, tag versions, | |
| 80 | and inspect project history. | |
| 81 | ||
| 82 | Git does not require GitHub, or any other hosting platform. It can run entirely | |
| 83 | on a developer's laptop. A repository can exist locally, on an internal server, | |
| 84 | on a shared network path, or on another Git host. | |
| 85 | ||
| 86 | For example, I can create a local Git repository, expose it through the Git | |
| 87 | protocol, and share this info with a friend or coworker. Then, they can clone my | |
| 88 | repository and we can collaborate by making changes independently and using | |
| 89 | commits, branches, etc. to push changes back and forth with each other. In this | |
| 90 | scenrio, there is *no* host and we are essentially a distributed network of our | |
| 91 | own. | |
| 92 | ||
| 93 | At 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 | ||
| 102 | That is valuable, but it is not the whole development process. This is where Git | |
| 103 | hosts introduce useful, addition features on top of Git. | |
| 104 | ||
| 105 | * Git Hosts Add the Workflow | |
| 106 | ||
| 107 | A Git host stores Git repositories and adds collaboration, workflow, and | |
| 108 | governance features around them. In an audit or compliance context, this is | |
| 109 | where most of the controls originate that mitigate risks with the system | |
| 110 | development lifecycle (SDLC). | |
| 111 | ||
| 112 | GitHub is the most familiar example, so I will use that in this post, but it is | |
| 113 | not the only one. Other Git hosts include GitLab, Bitbucket, Azure DevOps Repos, | |
| 114 | Sourcehut, Gitea, and Forgejo. | |
| 115 | ||
| 116 | These 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 | ||
| 133 | That is why the same Git repository can behave differently depending on where it | |
| 134 | is hosted. GitHub, GitLab, Bitbucket, Azure DevOps, and Sourcehut all support | |
| 135 | Git repositories, but their review workflows, permissions, logs, automation, and | |
| 136 | terminology differ. | |
| 137 | ||
| 138 | * Audit Implications | |
| 139 | ||
| 140 | Using GitHub as an example, let's walk through a common audit approach to the | |
| 141 | common change management (CM) or program development (PD) controls. | |
| 142 | ||
| 143 | First, 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 can 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 | ||
| 159 | Now, 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 protections 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 inheritence 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 inheritence 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 | ||
| 180 | If your inspecting a project where CI/CD pipelines matter, you can also dive | |
| 181 | into the team's configuration of their pipeline in terms of the logic, access to | |
| 182 | modify, and any relevant schedules or triggers. | |
| 183 | ||
| 184 | * Conclusion | |
| 185 | ||
| 186 | Hopefully at this point, it's clear that Git is not GitHub. While they are | |
| 187 | related and can be confusing for non-developers, it's important to understand | |
| 188 | the distinction. | |
| 189 | ||
| 190 | Without this understanding, everything can fall apart in your understanding, | |
| 191 | risk assessment, and scoping of an audit. | |