在版本控制上

介绍

Version Control 管理文档、计算机程序、大型网站和其他信息集合的更改。受版本控制的文件集保存在 repository .

这个 版本控制系统 （VCS）是负责跟踪存储库的连续版本的应用程序。

基本工作流程是：

1. 用户克隆存储库并创建本地 working copy 文件。（本地副本本身可以是受版本控制的本地存储库）。

2. 用户使用文件的本地副本。（请注意，并非每个文件的每个更改都注册为 revision ）

3. 当用户想要（例如，当文档的新版本相当完整，或每天下午6:14…）时，一组新的或修改过的文件（或 changeset ）可以作为本地工作副本的修订提交。

4. 用户还可以选择何时 commit 将修订返回到原始存储库中。

5. 如果将本地修订合并到原始存储库中，则会在其中创建新的修订点。

   这个 merge 可由版本控制系统自动执行：

   1. 如果用户具有提交所需的权限 (push ）到原始存储库；

   2. 如果没有的话 conflict 检测到（例如，当用户在本地副本中工作时，其他人提交了对相同文件的修订）。

6. 如果用户没有提交到原始存储库所需的权限，则 pull 可以将请求发送给存储库的所有者。

   所有者检查提议的更改，并接受或拒绝更改集。

下面的故事板说明了这些步骤。

故事板1-基本工作流

这个故事板使用一个简化的层次结构描述了一个简化的工作流。（在现实世界中，任何两个不同的参与者和存储库之间都可以存在链接。该技术允许任意配置的网络。）

行动者网络

考虑一个典型的层次结构：

• “蓝”角色只工作，认识“绿”角色。

• 每个“绿色”角色与一组不同的“黄色”角色合作。

• 蓝色行动者的职责是整理绿色行动者的贡献（变化），并解决不同绿色行动者提出的不同变化之间的任何冲突。

• 就 yellow 角色而言，每个绿色角色的职责是相似的。

信任网络

这个层次结构是一种特殊的网络类型（…有向非循环网络或“树”）。

它可以被视为3个不同的“信任网络”。

“信任网络”的概念简化了工作：

• 蓝角色信任绿角色回顾他的黄色同事所做的工作。

  • 从蓝角色的角度来看，每个“绿黄”网络的具体配置是不相关的。

  • 所有网络是否真的是一棵树（或者如果一个给定的黄色参与者参与两个不同的子网络），这也是不相关的。

• 每个角色只需要信任（和互动）他的近邻：

  • 绿色参与者接受其蓝色邻居批准的任何上游更改。

  • 绿色参与者批准（或拒绝）他的黄色邻居所做的更改（或解决不同更改之间的冲突）。

• 根据定义，蓝色参与者可以直接将更改提交到自己的蓝色信息库中。绿色行动者也可以去他们自己的绿色宝库。

• 每一个参与者也可以“拉入”到他的存储库中，任何他邻居们所做的更改。

克隆存储库

初始工作流程描述如下：

1. Blue先生创造了 起初的 储存库。

2. 格林先生 无性系 Blue的仓库

3. 从而获得 工作 复制。

分布式存储库

然后将存储库分发给所有团队：

1. 通过克隆格林的存储库，每个黄色参与者都可以获得他们的工作副本。

2. 格林先生的仓库现在是 主人 所有黄色角色的存储库。

3. Blue先生的仓库现在是 上游 所有黄色角色的存储库。

同步存储库

存储库必须显式同步。例如，假设：

1. 格林先生更改了一些文件，然后进行了“本地提交”。Green的存储库现在有了一个新的修订版（在任何其他存储库中都不存在）。

2. 其中一个 yellow 角色每天同步本地的工作副本，以确保他有最新的文件。他的本地工作副本更新为格林先生对主存储库所做的最新修订。

3. 其他的 yellow 角色没有更新他们的本地工作副本，而且仍然有以前的版本。

4. 同时，Blue先生不知道下游仓库有任何变化。

提交并合并

变更也可以通过向上游传播。假设：

1. 一个黄色的参与者更改了一些文件并进行了“本地提交”。本地存储库有一个新的修订版（行话：“本地存储库是主存储库前面的一个提交”）。

2. yellow 角色通知格林先生，并要求他将变更集合并到格林先生的存储库中（行话：“向格林先生发送一个请求”）。

3. 格林先生审查这些更改，批准它们（或不批准…）并将更改集合并到他自己的存储库中。

4. 与此同时，Blue先生仍然不知道下游存储库中的任何变化（他没有收到任何请求）。

当分配给格林先生团队的工作准备就绪时：

1. 格林先生向布鲁先生发送了一个“拉车请求”。

2. Blue先生审查并接受更改，并更新他的存储库。

3. 其他人都可以将他们的存储库与最新版本同步。

故事板2-使用分支管理文档翻译过程

树干和树枝

考虑以下网络：

• 格雷先生是负责《用户手册》和《项目手册》英文版的技术作者。格雷先生还负责将在各种文档中使用的模板和样式表。

• _ρ_σ_νο_先生负责希腊语版本。

• _лт先生负责保加利亚语版本。

• 阿祖尔先生负责葡萄牙语版本。

翻译过程开始时：

1. 格雷先生创建了一个存储库，其中包含英文文档（例如每章一个文件），以及构建最终文档所需的图像文件（例如应用程序截图）、模板和样式表。

2. Mssrs_ρ_σ_νο_、_лт和azul都克隆了英语语言库，并创建了自己的工作副本。

3. 它们中的每一个还创建了一个本地分支：文件的副本，这样每个人都可以在重用图像文件和样式表的同时，将文本转换为自己的语言。

   在这个例子中，英文版本是 大旅行箱 . 每个本地化版本都是 分支 .

当新文档准备好翻译时：

1. 格雷先生完成了一个新的章节，并将其提交给了知识库。

   格雷先生也改变了一些图像。

   现在有了新版本。

2. Messrs_ρ_σ_νο_、_лт和Azul将其工作副本与主存储库同步（仅更新主干）。

3. 它们中的每一个都会更新本地分支。

如果_ρ_σ_νο_先生在英语版本中检测到一些拼写错误怎么办？

1. _ρ_σ_νο_先生更改主干中的英语文件，进行本地提交并通知Grey先生。

2. 格雷先生审查这些变更并接受请求。

   现在，主存储库的最后一次修订包括_ρ_σ_ν_先生（但不是希腊分支机构）所做的更改。

3. _лт和azul先生将他们的工作副本与主存储库同步。

   更新了主干的工作副本。每个团队成员必须更新其特定的本地分支。

分支可以作为不同的版本使用…

1. _rho_rho_νο_先生更改了默认样式表，包括一些改进了其在希腊字母表中使用的样式。

   更改只在希腊语分支中进行。

2. 由于使用的是西里尔字母，因此，Mr_лт也做了类似的改变。

   只对保加利亚语分支进行更改。

3. 阿祖尔先生不喜欢章节标题的颜色，并改变了葡萄牙语分支的样式表。

   阿祖尔先生决定将更改提交给格雷先生，这样主干也可以更改。

4. 格雷先生回顾了阿苏尔先生所做的改变，但不接受。

   主干样式表没有更改。

术语表

基线

文件的批准修订版，可从中进行后续更改。

分支

在版本控制下的一组文件可以在某个时间点进行分支（分叉）。从那时起，文件的两个副本可能以不同的方式发展，彼此独立。

改变

更改（或diff或delta）表示对受版本控制的文件的特定修改。

变更集

具有更改的文件集合。

结账

参见“克隆”。

克隆

克隆是从存储库创建本地工作副本。用户可以指定修订或获取最新版本。在集中式版本控制系统（带有一个中央存储库）中，术语“签出”也被使用。术语“checkout”可用作名词来描述工作副本。

犯罪

提交就是将工作副本中所做的更改写入或合并回存储库。术语“commit”和“checkin”也可用作名词来描述由于commit而创建的修订。

冲突

当不同的方对同一文件进行更改，并且系统无法协调更改时，会发生冲突。

用户必须通过组合更改或选择一个更改而不是另一个更改来解决冲突。

叉

参见“分支”。

头

对主干或分支的最新修订。

树干和每根树枝都有自己的头。头部有时用来指后备箱的头部。

合并

合并是将两组更改应用于受版本控制的文件或文件集的操作。

用户使用其他用户对存储库所做的更改来更新其工作副本。

用户试图用对工作副本所做的更改来更新存储库。

知识库

存储库是存储文件当前和历史数据的地方，通常存储在服务器上。

决定

用户干预以解决同一文件的不同更改之间的冲突的行为。

修订

修订版（版本）是存储库中任何已注册的“快照”。

同步

参见“更新”。

大旅行箱

主干是在版本控制下收集信息的“主要”开发线，只包含“基线”（已批准）文件。

更新

更新（或同步）将原始存储库（例如由其他用户）中所做的更改合并到本地工作副本中。

版本

见“修订”。

工作副本

工作副本是在特定时间（修订版）从存储库中创建的文件的本地副本。