版本控制与协作（Git）

当只有一个人在项目上工作时，通常把文件保存在本地就足够了。但一旦多个开发者开始修改同一个代码库，问题就会很快出现——更改可能发生冲突、互相覆盖，或者引入难以追踪的 bug。

版本控制系统通过把每一次代码更改都变成一个可跟踪的事件来解决这个问题。每次更改不再是无人管理的编辑，而是被记录下来，并加入项目的结构化时间线中。

这条时间线包含重要的元数据，例如是谁做了更改、更改发生在什么时候，以及为什么要做这个更改。这些上下文对于调试、协作以及长期维护代码质量都至关重要。

从概念上讲，版本控制位于原始代码更改和长期项目历史之间。它把零散的编辑转化为一个有组织的系统，使团队能够协同工作，而不会破坏彼此的进度。

提交表示整个代码库在某一时刻的快照。版本控制系统不会手动保存单个文件，而是把所有更改打包成一个称为提交的单元。

每个提交不仅包含代码差异，还包含元数据：是谁做了更改、何时做的，以及描述更改目的的信息。这个信息非常关键——它解释的是为什么会有这次更改，而不仅仅是改了什么。

随着提交不断累积，它们会形成项目的时间线：提交 1 → 提交 2 → 提交 3。这个历史可以帮助开发者追踪 bug、理解功能是如何演进的，并在需要时将系统回滚到之前的状态。

如果没有提交，就没有可靠的方法来理解或管理代码库的演变。

分支本质上是在同一个项目中的一条独立开发线。开发者不会直接在主分支上进行更改（通常称为 main 或 master），而是创建一个新分支来处理某个特定功能或修复。

这意味着你可以自由修改文件、添加功能或进行实验，而不会影响代码的稳定版本。主分支保持干净并可用于生产，而其他地方的工作可以继续进行。

从概念上讲，分支会创建如下结构：

主分支 │
└ 功能分支

每个分支都会随着自己的提交独立演进。等工作完成并经过测试后，就可以安全地合并回主分支。

如果没有分支，团队成员会不断干扰彼此的工作，使协作变得缓慢、风险更高，也更容易出错。

功能分支工作流是现代软件团队中最广泛使用的开发模式之一。开发者不会直接在主分支上工作，而是为每个功能、bug 修复或改进创建一个新分支。

这个过程遵循一个清晰的顺序：

主分支 │
功能分支 │
处理功能 │
合并回主分支

首先，从主分支创建一个分支。然后，所有开发都在该分支内进行，提交会记录整个过程中的进展。这样可以让主分支始终保持稳定，并随时可用于生产。

当功能完成并经过测试后，该分支会合并回主分支。这样可以确保只有经过审查和最终确认的变更才会成为核心代码库的一部分。

这种工作流降低了风险，改善了协作，并使跨多个贡献者管理复杂开发变得更容易。

合并是将一个分支——通常是功能分支——中的更改取出，并将它们整合到另一个分支中，通常是主分支。

从概念上看，它是这样的：

功能分支 │
合并 ↓
主分支

当发生合并时，功能分支中的所有提交都会应用到目标分支。这使新的功能或修复成为主代码库的一部分。

合并是协作开发中的关键步骤，因为它将分散完成的工作汇集到一起。它确保来自不同开发者的独立更改被统一到一个一致的项目中。

不过，合并并不总是自动完成的——如果多个分支修改了代码的相同部分，就可能发生冲突，必须在合并完成之前手动解决。

拉取请求（PR）是一种协作机制，用于在更改合并到主分支之前对其进行审查和批准。

典型流程如下：

功能分支 ↓
拉取请求 ↓
代码审查 ↓
合并

在功能分支上完成工作后，开发者会在 GitHub 或 GitLab 等平台上创建一个拉取请求。这表示这些更改已经准备好接受审查。

其他开发者随后可以检查代码、留下评论、提出改进建议，并讨论实现细节。这个审查过程有助于发现 bug、执行编码规范，并确保这些更改与整体系统设计保持一致。

只有在拉取请求获得批准后，这些更改才会被合并到主分支。这形成了一个受控且协作的集成过程，而不是盲目地合并代码。

在实践中，拉取请求是团队环境中维护代码质量最重要的工具之一。

变基是合并的一种替代方式，它会改变分支的基础。它不是把历史合并在一起，而是将功能分支上的提交重新应用到主分支上的一个更新提交之上。

概念上：

主分支: A → B → C
功能分支: A → D → E

将功能分支变基到 C 之后：

主分支: A → B → C
功能分支: C → D → E

这意味着功能分支现在看起来像是从主分支的最新状态创建的，即使它最初开始得更早。

主要优点是提交历史更干净、更线性，没有额外的合并提交。这使项目时间线更容易阅读和理解。

不过，变基会重写提交历史。如果分支已经与他人共享，这可能会带来问题，因为它会改变提交标识符。因此，变基通常用于本地分支或私有分支，然后再进行合并。

合并冲突是协作开发中的自然现象。当两个分支以不同方式修改同一段代码时，就会发生冲突。

从概念上讲：

分支 A 修改一行 分支 B 修改同一行 ↓
检测到冲突

由于版本控制系统无法判断哪个更改是正确的，合并过程会停止，必须手动解决冲突。

解决过程如下：

冲突 ↓
手动解决 ↓
合并结果

开发者会查看冲突代码的两个版本，并决定保留哪一个，或者将两处更改的部分内容组合成一个新的最终版本。

虽然冲突看起来像错误，但它们实际上是保护机制。它们可以防止意外覆盖，并迫使开发者明确决定代码应该如何演进。

Git 负责跟踪代码变更并维护历史记录，但它不提供内置的团队协作工具。

像 GitHub 和 GitLab 这样的平台通过托管仓库并提供让团队高效协作的界面来扩展 Git。

从概念上讲，开发者将代码推送到共享仓库，然后平台在其之上负责管理协作、评审和工作流。

这些平台使协调大型团队、执行开发流程，以及自动化软件生命周期中的部分环节（例如测试和部署）成为可能。