56af05b90b · cmc/cleberg.net

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.

@@ -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.

Commit 56af05b90b

Commit `56af05b90b`