HowItWorks:Git - Revision history

Rongzhou: /* Git, a distributed version control system */

2026-09-01T14:25:32Z

Git, a distributed version control system

← Older revision		Revision as of 14:25, 1 September 2026
Line 7:		Line 7:
	A '''version control system''' (VCS) records changes to a set of files over time, so that any past version can be recalled later. Without one, a project is just a folder of files that only moves forward: a wrong edit cannot be undone, and two people editing the same files quickly overwrite each other.		A '''version control system''' (VCS) records changes to a set of files over time, so that any past version can be recalled later. Without one, a project is just a folder of files that only moves forward: a wrong edit cannot be undone, and two people editing the same files quickly overwrite each other.

	Most older systems — CVS, Subversion, Perforce — are '''centralized''': one server holds the canonical repository, and anything that needs history must travel over the network to that server. In contrast, Git is '''distributed''': every clone of a repository is a complete repository with the entire history, so nearly every operation can be done locally, without a network connection.<ref>{{#cite:Q1457}}</ref>		Most older systems, such as CVS, Subversion, and Perforce, are '''centralized''': one server holds the canonical repository, and anything that needs history must travel over the network to that server. In contrast, Git is '''distributed''': every clone of a repository is a complete repository with the entire history, so nearly every operation can be done locally, without a network connection.<ref>{{#cite:Q1457}}</ref>

	Git functions by storing multiple versions of each tracked file, classified into three states:		Git functions by storing multiple versions of each tracked file, classified into three states:

Rongzhou: /* Try it yourself */

2026-09-01T14:23:19Z

Try it yourself

← Older revision		Revision as of 14:23, 1 September 2026
Line 220:		Line 220:

	Commands reproduced from Git's official documentation.<ref>{{#cite:Q1459}}</ref>		Commands reproduced from Git's official documentation.<ref>{{#cite:Q1459}}</ref>

			<blockquote>
			Syntax of certain commands may be different on Windows.
			</blockquote>

	<syntaxhighlight lang="bash" copy>		<syntaxhighlight lang="bash" copy>

RonzzWikiCowriterAI: Commands in Try it yourself as syntaxhighlight bash copy, outputs kept in pre — AI-assisted (RonzzWikiCowriter) (via update-page on MediaWiki MCP Server)

2026-09-01T14:18:39Z

Commands in Try it yourself as syntaxhighlight bash copy, outputs kept in pre — AI-assisted (RonzzWikiCowriter) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:18, 1 September 2026
Line 221:		Line 221:
	Commands reproduced from Git's official documentation.<ref>{{#cite:Q1459}}</ref>		Commands reproduced from Git's official documentation.<ref>{{#cite:Q1459}}</ref>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 1. Which version do you have?		# 1. Which version do you have?
	git --version		git --version
	</~~pre~~>		</syntaxhighlight>

	Output (your version depends on your install):		Output (your version depends on your install):
Line 232:		Line 232:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 2. The very first commit of git.git, via the GitHub API		# 2. The very first commit of git.git, via the GitHub API
	curl -s "https://api.github.com/repos/git/git/commits/e83c5163316f89bfbde7d9ab23ca2e25604af290" \		curl -s "https://api.github.com/repos/git/git/commits/e83c5163316f89bfbde7d9ab23ca2e25604af290" \
	\| grep -E '"name"\|"date"\|"message"'		\| grep -E '"name"\|"date"\|"message"'
	</~~pre~~>		</syntaxhighlight>

	Output (liveness check performed 2026-09-01):		Output (liveness check performed 2026-09-01):
Line 248:		Line 248:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 3. The latest feature release and its date, from the official website		# 3. The latest feature release and its date, from the official website
	curl -s https://git-scm.com/ \| grep -oE "2\.55\.0\|2026-06-29" \| sort -u		curl -s https://git-scm.com/ \| grep -oE "2\.55\.0\|2026-06-29" \| sort -u
	</~~pre~~>		</syntaxhighlight>

	Output (liveness check performed 2026-09-01):		Output (liveness check performed 2026-09-01):
Line 260:		Line 260:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 4. Git is a content-addressable store: hash some content, get back its key		# 4. Git is a content-addressable store: hash some content, get back its key
	echo 'test content' \| git hash-object -w --stdin		echo 'test content' \| git hash-object -w --stdin
	</~~pre~~>		</syntaxhighlight>

	Output:		Output:
Line 271:		Line 271:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 5. Read the object back by its key		# 5. Read the object back by its key
	git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4		git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
	</~~pre~~>		</syntaxhighlight>

	Output:		Output:
Line 282:		Line 282:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 6. Where did it go? Objects are stored under .git/objects, sharded by hash		# 6. Where did it go? Objects are stored under .git/objects, sharded by hash
	find .git/objects -type f		find .git/objects -type f
	</~~pre~~>		</syntaxhighlight>

	Output:		Output:
Line 293:		Line 293:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 7. A real project: init, add, commit, log		# 7. A real project: init, add, commit, log
	mkdir demo && cd demo		mkdir demo && cd demo
	git init		git init
	</~~pre~~>		</syntaxhighlight>

	Output (path depends on where you run it):		Output (path depends on where you run it):
Line 305:		Line 305:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	echo "Hello, Git!" > README.md		echo "Hello, Git!" > README.md
	git add README.md		git add README.md
	git commit -m "first commit"		git commit -m "first commit"
	</~~pre~~>		</syntaxhighlight>

	Output (hashes and authorship vary):		Output (hashes and authorship vary):
Line 319:		Line 319:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	git log --oneline		git log --oneline
	</~~pre~~>		</syntaxhighlight>

	Output:		Output:
Line 329:		Line 329:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 8. A commit object is just text: tree, author, committer, message		# 8. A commit object is just text: tree, author, committer, message
	git cat-file -p HEAD		git cat-file -p HEAD
	</~~pre~~>		</syntaxhighlight>

	Output (hashes, identity and timestamps vary):<ref>{{#cite:Q1463}}</ref>		Output (hashes, identity and timestamps vary):<ref>{{#cite:Q1463}}</ref>

Rongzhou: /* Backward compatibility, broken deliberately */

2026-09-01T14:16:05Z

Backward compatibility, broken deliberately

← Older revision		Revision as of 14:16, 1 September 2026
Line 211:		Line 211:
	Although the "store everything" approach inevitably introduces an storage overhead, the storage overhead's size is much smaller than the mathematical product of the number of commits and the repo's size, thanks to Git's backend performing aggressive compression and optimisation on its object storage. The data-integrity benefits outweigh the additional storage cost by far on any reasonably modern computer system.		Although the "store everything" approach inevitably introduces an storage overhead, the storage overhead's size is much smaller than the mathematical product of the number of commits and the repo's size, thanks to Git's backend performing aggressive compression and optimisation on its object storage. The data-integrity benefits outweigh the additional storage cost by far on any reasonably modern computer system.

	=== Backward compatibility, broken ~~deliberately~~ ===		=== Backward compatibility is broken only when strictly necessary ===

	"~~The~~ Git project aims to ensure backwards compatibility to the best extent possible. Minor releases will not break backwards compatibility unless there is a very strong reason to do so." But the project "irregularly releases breaking versions that deliberately break backwards compatibility", to stay "relevant, safe and maintainable going forward". ~~So far~~ there have been two: Git 1.6.0 ~~(August 2008)~~ and ~~Git 2.0 (May~~ 2014), with ~~the numbering scheme changing from <code>1.major.minor</code> to <code>major.minor</code> at~~ 2.0. The next one, Git 3.0, is planned ~~to change the default hash to SHA-256, the default reference storage to reftable, the default branch name to "main", and to require Rust in the build~~.<ref>{{#cite:Q1464}}</ref>		According to Git's official website: "the Git project aims to ensure backwards compatibility to the best extent possible. Minor releases will not break backwards compatibility unless there is a very strong reason to do so." But the project "irregularly releases breaking versions that deliberately break backwards compatibility", to stay "relevant, safe and maintainable going forward".

			Two decades onward since Git's birth, there have only been two breaking changes : once in 2008 with Git 1.6.0, and once in 2014 with Git 2.0. The next one, Git 3.0, is planned for end of 2026.<ref>{{#cite:Q1464}}</ref>

	== Try it yourself ==		== Try it yourself ==

Rongzhou: /* Git stores everything */

2026-09-01T14:12:03Z

Git stores everything

← Older revision		Revision as of 14:12, 1 September 2026
Line 209:		Line 209:
	Once a Git commit is made, the commit-time project snapshot stays in the project's Git object storage forever. Even commands that rewrites Git history, such as <code>amend</code>, <code>rebase</code>, and <code>reset</code> do not erase them.<ref>{{#cite:Q1457}}</ref>		Once a Git commit is made, the commit-time project snapshot stays in the project's Git object storage forever. Even commands that rewrites Git history, such as <code>amend</code>, <code>rebase</code>, and <code>reset</code> do not erase them.<ref>{{#cite:Q1457}}</ref>

	Although the "store everything" approach ~~adds~~ an ~~obvious~~ storage overhead, the ~~data-integrity benefits outweigh the additional~~ storage ~~cost by far on any reasonably modern computer system. What~~'s ~~more, the storage overhead~~ is much smaller than the mathematical product of the number of commits and the repo's size, as Git's backend ~~performs~~ aggressive compression and optimisation on its object storage.		Although the "store everything" approach inevitably introduces an storage overhead, the storage overhead's size is much smaller than the mathematical product of the number of commits and the repo's size, thanks to Git's backend performing aggressive compression and optimisation on its object storage. The data-integrity benefits outweigh the additional storage cost by far on any reasonably modern computer system.

	=== Backward compatibility, broken deliberately ===		=== Backward compatibility, broken deliberately ===

Rongzhou: /* Git generally only adds data */

2026-09-01T14:00:47Z

Git generally only adds data

← Older revision		Revision as of 14:00, 1 September 2026
Line 203:		Line 203:
	To satisfy both needs, Git exposes two sets of commands: a "'''porcelain'''" set of high-level commands designed to be directly called by human users, and a "'''plumbing'''" set of low-level commands exposing direct object storage, index, and ref manipulation, designed primarily for scripted use. The "plumbing" commands are deliberately stable across versions to ensure lasting compatibility of user scripts and tools.<ref>{{#cite:Q1456}}</ref>		To satisfy both needs, Git exposes two sets of commands: a "'''porcelain'''" set of high-level commands designed to be directly called by human users, and a "'''plumbing'''" set of low-level commands exposing direct object storage, index, and ref manipulation, designed primarily for scripted use. The "plumbing" commands are deliberately stable across versions to ensure lasting compatibility of user scripts and tools.<ref>{{#cite:Q1456}}</ref>

	=== Git ~~generally only adds data~~ ===		=== Git stores everything ===

	~~"When you do actions in~~ Git~~, nearly all of them only add data to the Git database. It~~ is ~~hard to get~~ the ~~system to do anything that~~ is ~~not undoable or to make it erase~~ data ~~in any way~~.~~" Uncommitted work can be lost, but once~~ a ~~snapshot~~ is ~~committed — and especially once it is pushed to another repository — it is very difficult to lose. Because objects are immutable and content~~-~~addressed, nothing is ever overwritten: history only grows. This is what makes Git~~'s ~~rewriting~~ commands (amend, rebase, reset~~) safe to use: they create new commits and move refs, never destroying the old ones until garbage collection reclaims~~ them.<ref>{{#cite:Q1457}}</ref>		Git is built within the 21st century context: storage is cheap; data loss is costly.

			Once a Git commit is made, the commit-time project snapshot stays in the project's Git object storage forever. Even commands that rewrites Git history, such as <code>amend</code>, <code>rebase</code>, and <code>reset</code> do not erase them.<ref>{{#cite:Q1457}}</ref>

			Although the "store everything" approach adds an obvious storage overhead, the data-integrity benefits outweigh the additional storage cost by far on any reasonably modern computer system. What's more, the storage overhead is much smaller than the mathematical product of the number of commits and the repo's size, as Git's backend performs aggressive compression and optimisation on its object storage.

	=== Backward compatibility, broken deliberately ===		=== Backward compatibility, broken deliberately ===

Rongzhou: /* Plumbing and porcelain */

2026-09-01T13:50:43Z

Plumbing and porcelain

← Older revision		Revision as of 13:50, 1 September 2026
Line 199:		Line 199:
	=== Plumbing and porcelain ===		=== Plumbing and porcelain ===

	Git is ~~built as~~ a ~~toolkit~~, ~~not a monolith~~: a ~~stable~~ set of ~~low~~-level ~~plumbing~~ commands ~~that manipulate objects~~, ~~the index~~ and ~~refs directly, with~~ a ~~thin porcelain layer~~ of ~~user~~-~~friendly~~ commands ~~on top~~. The plumbing ~~interfaces~~ are deliberately stable ~~"because these commands are primarily for scripted use", while porcelain commands may change~~ to ~~improve the end-~~user ~~experience. This design is what lets a huge ecosystem of GUIs, hosting services~~ and tools ~~build on Git without forking it~~.<ref>{{#cite:Q1456}}</ref>		For small-scale projects with only a few contributors, manually managing Git history is quite doable. However, for large projects with thousands of contributors, manual Git history management can quickly become a full-time job, making scripting/advanced Git management tools highly desirable.

			To satisfy both needs, Git exposes two sets of commands: a "'''porcelain'''" set of high-level commands designed to be directly called by human users, and a "'''plumbing'''" set of low-level commands exposing direct object storage, index, and ref manipulation, designed primarily for scripted use. The "plumbing" commands are deliberately stable across versions to ensure lasting compatibility of user scripts and tools.<ref>{{#cite:Q1456}}</ref>

	=== Git generally only adds data ===		=== Git generally only adds data ===

Rongzhou: /* A three-part staging model */

2026-09-01T13:44:24Z

A three-part staging model

← Older revision		Revision as of 13:44, 1 September 2026
Line 195:		Line 195:
	=== A three-part staging model ===		=== A three-part staging model ===

	~~Git~~ interposes the '''index''' between the working tree and the repository~~. Nothing~~ is committed unless it ~~is explicitly staged:~~ <code>git add</code> ~~moves changes into the index, <code>git commit</code> snapshots the index~~. ~~The cost is one extra step compared with systems where any saved file is automatically versioned; the payoff is that a commit can contain exactly what you want it~~ to ~~contain — a~~ surgical ~~selection of changes across many files~~, ~~reviewed with <code>git diff~~ -~~-cached</code> before it becomes history~~.<ref>{{#cite:Q1457}}</ref>		By interposes the '''index (staging area)''' between the working tree and the repository, Git ensures that nothing is committed unless user explicitly requests it with <code>git add</code>. In addition to providing surgical precision for each commit, this design also discourages contributors from making odd-time commits just to "save work".<ref>{{#cite:Q1457}}</ref>

	=== Plumbing and porcelain ===		=== Plumbing and porcelain ===

Rongzhou: /* Try it yourself */

2026-09-01T13:39:54Z

Try it yourself

← Older revision		Revision as of 13:39, 1 September 2026
Line 211:		Line 211:
	== Try it yourself ==		== Try it yourself ==

	~~The web-based checks below were verified live on 2026-09-01; the local command outputs are~~ reproduced from Git's official documentation ~~(the Pro Git book~~<ref>{{#cite:Q1459}}</ref> ~~and the git manual), as marked.~~		Commands reproduced from Git's official documentation.<ref>{{#cite:Q1459}}</ref>

	<pre>		<pre>
Line 218:		Line 218:
	</pre>		</pre>

	~~Documented output~~ (your version depends on your install):		Output (your version depends on your install):

	<pre>		<pre>
Line 225:		Line 225:

	<pre>		<pre>
	# 2. The very first commit of git.git, via the GitHub API ~~(live check, 2026-09-01)~~		# 2. The very first commit of git.git, via the GitHub API
	curl -s "https://api.github.com/repos/git/git/commits/e83c5163316f89bfbde7d9ab23ca2e25604af290" \		curl -s "https://api.github.com/repos/git/git/commits/e83c5163316f89bfbde7d9ab23ca2e25604af290" \
	\| grep -E '"name"\|"date"\|"message"'		\| grep -E '"name"\|"date"\|"message"'
	</pre>		</pre>

	Output (~~verified live~~):		Output (liveness check performed 2026-09-01):

	<pre>		<pre>
Line 241:		Line 241:

	<pre>		<pre>
	# 3. The latest feature release and its date, from the official website ~~(live check, 2026-09-01)~~		# 3. The latest feature release and its date, from the official website
	curl -s https://git-scm.com/ \| grep -oE "2\.55\.0\|2026-06-29" \| sort -u		curl -s https://git-scm.com/ \| grep -oE "2\.55\.0\|2026-06-29" \| sort -u
	</pre>		</pre>

	Output (~~verified live~~):		Output (liveness check performed 2026-09-01):

	<pre>		<pre>
Line 257:		Line 257:
	</pre>		</pre>

	~~Documented output~~:~~<ref>{{#cite:Q1463}}</ref>~~		Output:

	<pre>		<pre>
Line 268:		Line 268:
	</pre>		</pre>

	~~Documented output~~:		Output:

	<pre>		<pre>
Line 279:		Line 279:
	</pre>		</pre>

	~~Documented output~~:		Output:

	<pre>		<pre>
Line 291:		Line 291:
	</pre>		</pre>

	~~Documented output~~ (path depends on where you run it):		Output (path depends on where you run it):

	<pre>		<pre>
Line 303:		Line 303:
	</pre>		</pre>

	~~Documented output~~ (hashes and authorship vary):		Output (hashes and authorship vary):

	<pre>		<pre>
Line 315:		Line 315:
	</pre>		</pre>

	~~Documented output~~:		Output:

	<pre>		<pre>
Line 326:		Line 326:
	</pre>		</pre>

	~~Documented output~~ (hashes, identity and timestamps vary):<ref>{{#cite:Q1463}}</ref>		Output (hashes, identity and timestamps vary):<ref>{{#cite:Q1463}}</ref>

	<pre>		<pre>
Line 335:		Line 335:
	First commit		First commit
	</pre>		</pre>

	'''Verification:''' outputs 2–3 were checked against the live GitHub API and git-scm.com on 2026-09-01; outputs 1 and 4–8 are reproduced from Git's official documentation — the Pro Git book chapters "What is Git?" and "Git Objects", and the git manual page.<ref>{{#cite:Q1463}}</ref><ref>{{#cite:Q1457}}</ref><ref>{{#cite:Q1456}}</ref>

	== References ==		== References ==

Rongzhou: /* Branches are cheap pointers */

2026-09-01T13:34:44Z

Branches are cheap pointers

← Older revision		Revision as of 13:34, 1 September 2026
Line 191:		Line 191:
	=== Branches are cheap pointers ===		=== Branches are cheap pointers ===

	A branch is not a copy of the tree~~, not~~ a container of commits — it is just a ref, a pointer to a commit. ~~Creating a branch writes a 41-byte file; switching branches only updates <code>HEAD</code> and the working tree. This makes branching~~ and merging ~~a first~~-~~class~~, ~~everyday operation and delivers~~ the original design goal of "strong support for non-linear development (thousands of parallel branches)".<ref>{{#cite:Q1456}}</ref><ref>{{#cite:Q1458}}</ref> ~~Merging two lines of development is simply creating a commit with two parents.~~<ref>{{#cite:Q1456}}</ref>		A branch is not a copy of the Git tree nor a container of commits — it is just a thin <code>ref</code>, a 41-byte pointer to a commit. Therefore, creating and merging branches cost next-to-nothing, delivering the original design goal of "strong support for non-linear development (thousands of parallel branches)".<ref>{{#cite:Q1456}}</ref><ref>{{#cite:Q1458}}</ref><ref>{{#cite:Q1456}}</ref>

	=== A three-part staging model ===		=== A three-part staging model ===