Linux：版本控制器Git(第一章)|历史|理解Git|相关git操作|提交冲突解决

上篇文章：

Linux：第一个程序--进度条|区分回车与换行|行缓冲区|进度条代码两个版本|代码测试与优化

[1.Git的历史（内容来自Gemini 3.0pro）](#1.Git的历史（内容来自Gemini 3.0pro）)

[1. 混沌时期与 BitKeeper (1991 - 2005)](#1. 混沌时期与 BitKeeper (1991 - 2005))

[2. 导火索：决裂 (2005年4月)](#2. 导火索：决裂 (2005年4月))

[3. "十天"奇迹 (The Ten Days)](#3. “十天”奇迹 (The Ten Days))

[4. 名字的由来](#4. 名字的由来)

[5. 移交权杖：Junio C Hamano](#5. 移交权杖：Junio C Hamano)

[6. 统治世界：GitHub 的崛起 (2008 - 至今)](#6. 统治世界：GitHub 的崛起 (2008 - 至今))

[总结：Git 的成功秘诀](#总结：Git 的成功秘诀)

[2.理解Git（内容来自Gemini 3.0pro）](#2.理解Git（内容来自Gemini 3.0pro）)

[1. 核心概念：仓库与版本管理](#1. 核心概念：仓库与版本管理)

[2. 架构本质：客户端即服务端](#2. 架构本质：客户端即服务端)

[3. 本地数据与网络同步](#3. 本地数据与网络同步)

[4. Git 的"包装"：从硬核到易用](#4. Git 的“包装”：从硬核到易用)

[A. 客户端层面的包装 (GUI 工具)](#A. 客户端层面的包装 (GUI 工具))

[B. 服务器层面的包装 (托管平台)](#B. 服务器层面的包装 (托管平台))

[5. 结论：去中心化的、分布式的多版本控制器](#5. 结论：去中心化的、分布式的多版本控制器)

[3.2.1git clone](#3.2.1git clone)

3.2.2相关文件解读

3.3更新仓库

[git add](#git add)

[git commit -m](#git commit -m)

[git log](#git log)

3.4更新到远端

[git push](#git push)

4.关于提交冲突

基础的历史与理论来自ai，如本文第1章和第2章(我均有备注)。

1.Git的历史（内容来自Gemini 3.0pro）

Git 的历史是软件开发史上最著名的传奇之一。它不是为了商业利益而生，而是源于愤怒、实用主义以及 Linux 之父 Linus Torvalds 对当时现有工具的极度失望。

可以说，Git 是一次"仅仅花了 10 天"就改变了世界软件开发方式的革命。

以下是 Git 诞生及其发展的完整历史脉络：

1. 混沌时期与 BitKeeper (1991 - 2005)

在 Git 出现之前的很长一段时间里（1991-2002），Linux 内核的开发管理相当原始。世界各地的开发者提交代码主要靠**传递补丁（Patches）**和压缩包（Tarballs）。Linus Torvalds 需要手动合并这些文件，效率极低且容易出错。

2002年：拥抱 BitKeeper

为了解决协作难题，Linux 社区做出了一个极具争议的决定：开始使用名为 BitKeeper 的分布式版本控制系统（DVCS）。
- 优点：BitKeeper 性能优异，支持分布式开发。
- 缺点：它是一款专有软件（闭源）。
- 妥协：BitKeeper 的母公司 BitMover 允许 Linux 社区免费使用其软件，但不能反向工程。这个决定激怒了自由软件基金会（FSF）的 Richard Stallman，因为他认为开源项目不应依赖闭源工具。

2. 导火索：决裂 (2005年4月)

2005年，这种脆弱的和平被打破了。

Samba 的开发者 Andrew Tridgell（一位著名的逆向工程专家）试图对 BitKeeper 的协议进行逆向工程，以便开发一个能与 BitKeeper 交互的开源工具。

BitKeeper 的 CEO Larry McVoy 对此大为光火，认为这违反了免费使用协议。结果是：

BitMover 撤销了 Linux 社区免费使用 BitKeeper 的授权。
Linux 内核开发瞬间陷入了没有工具可用的困境。

3. "十天"奇迹 (The Ten Days)

Linus Torvalds 需要一个替代品，而且是立刻需要。他评估了当时所有的开源版本控制系统（如 CVS, Subversion），发现它们不仅设计理念陈旧（集中式），而且速度太慢，根本无法支撑 Linux 内核这种巨型项目。

于是，Linus 决定自己写一个。

2005年4月3日：Linus 开始编写 Git。
2005年4月6日：Linus 宣布了项目。
2005年4月7日 ：Git 实现了自举（Self-hosting），也就是说，Git 的代码开始用 Git 自身来管理。
2005年4月18日：实现了第一个多分支合并。

设计哲学：

Linus 在设计 Git 时，采取了一个著名的策略："看 CVS 是怎么做的，然后反其道而行之。"

分布式：没有单点故障，每个人都有完整的历史记录。

速度：必须极快。

数据完整性：使用 SHA-1 哈希确保代码不被篡改（类似区块链的早期思想）。

4. 名字的由来

Linus Torvalds 以其独特的幽默感和暴脾气著称。关于 "Git" 这个名字，他在 README 文件中给出了几种解释，最著名的是一种英式俚语的自嘲：

"I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

（"我是一个自大的混蛋，所以我所有的项目都以我自己命名。先是 'Linux'，现在是 'git'。"）

在英国俚语中，"Git" 意为"混蛋"、"饭桶"或"令人不快的人"。

当然，他也给出了其他解释：

Global Information Tracker（全球信息追踪器）：当你心情好时。
Goddamn Idiotic Truckload of sh*t（该死的愚蠢的一堆破烂）：当它崩溃时。

5. 移交权杖：Junio C Hamano

很多人误以为 Linus 一直在维护 Git。事实并非如此。

Linus 编写 Git 只是为了让 Linux 内核开发继续下去。一旦 Git 稳定下来（仅仅几个月后），他就把主要精力放回了 Linux 内核。

2005年7月26日 ，Linus 将 Git 的维护权移交给了 Junio C Hamano。
Junio 是 Google 的一位日本软件工程师，他是 Git 的第二大贡献者，也是真正的幕后英雄。直到今天，他依然是 Git 项目的首席维护者。Git 变得如此易用（相对而言）和强大，Junio 功不可没。

6. 统治世界：GitHub 的崛起 (2008 - 至今)

虽然 Git 在技术上很强，但在早期，它的命令行极其难用，被称为"只有天才才能使用的工具"。

2008年 ：GitHub 上线。它为 Git 提供了一个友好的 Web 界面和社交化编程环境（Social Coding）。
转折点：GitHub 让普通开发者也能轻松使用 Git。"Fork"（复刻）和 "Pull Request"（拉取请求）成为了开源协作的标准流程。
终局：随着 Ruby on Rails 等流行框架全面拥抱 Git，旧时代的霸主 Subversion (SVN) 迅速衰落。如今，从微软（曾经反对开源，现在拥有 GitHub）到初创公司，Git 几乎垄断了全球的版本控制市场。

总结：Git 的成功秘诀

Git 能够成功，不仅仅是因为 Linus 的天才代码，更是因为它是为了解决实际痛点而生的。

特性	旧时代 (CVS/SVN)	Git 时代
架构	集中式 (服务器挂了就完了)	分布式 (每个人都有完整备份)
思维方式	记录文件的差异 (Delta)	记录文件系统的快照 (Snapshot)
分支管理	极其昂贵且慢	极其廉价且快 (瞬间完成)
安全性	弱	SHA-1 哈希保证绝对一致性

2.理解Git（内容来自Gemini 3.0pro）

这是一个关于 Git 核心工作机制的系统性讲解。我们将从最基础的本地概念，扩展到网络架构，最后解析其生态系统。

1. 核心概念：仓库与版本管理

Git 的核心在于它如何看待数据。

仓库 (Repository)

你可以把它想象成一个**"时间胶囊数据库"。

在你的电脑上，它通常表现为一个隐藏的 .git 文件夹。这个文件夹里存放的不仅仅是你的代码，而是整个项目的历史**。
- 工作区：你平常写代码、看得到的文件目录。
- 版本库 ：.git 目录，存放所有历史记录和元数据。
版本管理：快照 (Snapshot) 而非差异

这是 Git 与旧式工具（如 SVN）最大的不同。
- 旧式：记录文件 A 变动了第 3 行。
- Git ：每次提交（Commit），Git 就像给整个文件系统拍了一张全景照片。如果文件没有改动，它就只保留一个指向旧文件的链接（为了节省空间）。
如何实现"备份"？

在 Git 中，"备份"不是复制粘贴文件副本，而是提交 (Commit)。

一旦你提交了代码，这个版本的"快照"就被永久哈希化（SHA-1）并存入数据库。即使你后来删除了文件，只要回到之前的"快照"节点，文件依然完好无损。

2. 架构本质：客户端即服务端

这是 Git 最反直觉也最强大的地方：Git 软件是客户端与服务端的合体。

传统的 C/S 架构 (如 SVN)：服务器存有完整历史，你的电脑上只有当前这一版文件。没有网，你就无法查看历史或提交修改。
Git 的架构：

当你安装了 Git，你就同时拥有了客户端（用于修改、提交）和服务端（用于存储、管理历史）。
- 当你执行 git clone 时，你不仅仅是下载了代码，你是把整个数据库完整地克隆到了本地。
- 断网工作：你可以在飞行的飞机上查看项目 5 年前的历史，或者进行代码提交，因为所有的"服务器数据"都在你本地硬盘上。

3. 本地数据与网络同步

由于每个人都有完整的数据库，数据同步本质上是两个仓库之间的合并。

本地数据流：

工作区 (写代码) -> 暂存区 (Staging Area, 准备提交) -> 本地仓库 (Commit, 生成快照)。
网络数据流：
- Push (推)：将我的本地仓库的新快照，发送给远程仓库。
- Pull (拉)：将远程仓库的新快照，下载并合并到我的本地仓库。
Remote (远程仓库)：在 Git 的逻辑里，GitHub 上的服务器只是"另一台电脑"而已，地位和你本地的电脑是平等的，只是它 24 小时开机供大家交换数据。

4. Git 的"包装"：从硬核到易用

Git 本身是一个命令行工具（CLI），功能强大但对人类不友好。因此，业界出现了两层包装：

A. 客户端层面的包装 (GUI 工具)

为了不让用户去背 git commit -m 或 git rebase 这种命令，出现了图形化界面。

TortoiseGit ("小乌龟")：Windows 用户的最爱。它将 Git 命令集成到了右键菜单中，文件图标会有红绿覆盖层显示状态。
SourceTree / GitKraken：专业的 Git 可视化管理工具，能漂亮地展示分支图谱。
本质：它们只是给 Git 内核穿了一层"衣服"，底层执行的依然是 Git 命令。

B. 服务器层面的包装 (托管平台)

为了方便团队协作，我们需要一个公网上的"中心"来交换代码。

GitHub / Gitee (码云) / GitLab：

它们本质上是提供了 Web 界面的 Git 服务器。

但它们不仅限于 Git，还增加了 Git 本身没有的功能：
- 权限管理：谁能读，谁能写。
- 社交化功能：Star, Fork。
- 流程管理：Pull Request (合并请求)，Issues (问题追踪)，CI/CD (自动部署)。

5. 结论：去中心化的、分布式的多版本控制器

总结来说，Git 的定义可以拆解为：

去中心化 (Decentralized)：没有绝对的"中央服务器"，任何一个节点的崩溃都不会导致数据丢失（除非所有人的电脑和服务器全炸了）。
分布式 (Distributed)：每个开发者手中都有完整的项目历史和版本库副本。
多版本控制器：它极其擅长处理非线性的开发（分支 Branching），允许成百上千个平行的"宇宙"（功能分支）同时存在，并最终合并在一起。

3.git操作

以gitee为例：https://gitee.com/

3.1新建仓库

进入后的选项如下：模板选择单分支即可，具体的可看我之后的文章。

在这里解释一下上图"添加开源许可证"的概念。简单来说，把代码设为"公开"只是让别人能看见代码；而选择了"许可证"，才是法律上允许别人使用、修改或商用你的代码，具体总结如下：

你希望别人怎么用你的代码？	推荐许可证	商业公司敢用吗？	能闭源吗？
越多人用越好，不管他是不是拿去卖钱	MIT (最推荐)	😍 非常喜欢	可以
这是个大项目，涉及专利，希望规范化	Apache 2.0	😊 喜欢	可以
我讨厌别人拿我的心血去赚钱还不贡献代码	GPL v3	😨 很多公司会禁止员工使用	不行 (必须开源)
我只是想写个小工具，不想看复杂的法律条文	MIT	😊	可以

之后，点击创建，得到下图内容：

其中，.gitignore文件是 Git 版本控制系统中的一个纯文本配置文件 ，其核心功能是：指定哪些文件或目录应该被 Git 忽略，即不纳入版本控制。 它的存在是为了解决一个关键问题：**并非工作目录中的所有文件都应该被提交到代码仓库中。**REANME.md就类似于产品说明书，用于介绍本仓库。