版本控制系统概述

版本控制系统是保存文件多个版本的一种机制。当修改某个文件后，你仍旧可以访问该文件之前的任意一个修订版本。它也是我们共同合作交付软件时所使用的一种机制。

本文主要以Git为例，结合当前行业主流的几种分支策略，为开发者讲解版本控制系统的主要使用场景和使用方法。对于Git的操作方法，以及版本控制系统中分支、合并等概念的定义，在这里不做赘述。

代码提交与分支创建

首先，让我们简单了解一下Git的一些基本概念，方便我们更好的理解代码提交与分支合并之间的逻辑关系。

• Git有三种状态，你的文件可能处于其中之一：
  • 已提交（committed）：数据已经安全的保存在本地数据库。
  • 已修改（modified）：修改了文件，但还没保存到数据库中。
  • 已暂存（staged）：对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
• Git仓库、工作目录以及暂存区域
  • Git仓库目录： Git用来保存项目的元数据和对象数据库的地方。这是Git中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。
  • 工作目录：项目的某个版本独立提取出来的内容。 从Git仓库的压缩数据库中提取出来文件，放在磁盘上以供使用或修改。
  • 暂存区域：是一个文件，保存了下次将提交的文件列表信息，有时候也被称作“索引”。
• 基本的Git工作流程如下：
  1. 在工作目录中修改文件。
  2. 暂存文件，将文件的快照放入暂存区域。
  3. 提交更新，找到暂存区域的文件，将快照永久性存储到Git仓库目录。

从上面的基本概念中我们可以了解到，Git的常用基本操作其实很简单，然而同一个工具，不同的用法产生的效果却是迥然不同的，这就要求我们在使用版本控制系统的时候尽量遵守规范，更能使工具发挥出它应有的价值。下面让我们来看看在代码提交和分支合并的时候应该遵守哪些规范：

• 分支具有描述性

  一个好的分支名称应该具有描述性，以便其他人通过分支名称就可以知道它到底是干什么用的。

• 提交要做对

  “好的文章不是写出来的，而是改出来的。”代码提交也是如此。

  • 一个提交做好一件事情：
    • 保持每个提交的正确性，不要一系列提交都在不停的修改同一个问题，如果是这样，请将它们合一。
    • 每个提交要独立，不要混杂其他的功能。
  • 提交要做小：
  • 如果一个提交，修改了过多的内容，那么对检视者就是个灾难。
  • 尽可能的拆分，让你的逻辑有延续性，并且可读。
• 清楚的提交信息

  通过写清楚的提交信息，你可以让其他人更容易跟上我们的思路并提供反馈。

  提交说明要回答如下问题：

  • What——要解决什么问题？
  • When——什么情况下会发生？
  • How——怎么样解决这个问题？
  • Why——为什么这样解决是合理的，比其他解决方法更好？
• 合并请求的提交要清晰

  一个好的合并请求不只是代码的事情，还牵涉到代码审查者对代码的审查，所以开发者不仅要写出好的代码，还需要考虑如何让其他人更清晰的理解自己的想法和思路，这是一个用代码做交流的过程。

  • 进行较小的合并请求。
  • 每个合并请求只做一件事情。
  • 代码行的字数，最好少于80个字。
  • 避免重新格式化代码。
  • 确保提交的代码能够编译通过并能通过所有测试。
  • 详细记录下自己提交的原因。
  • 避免重复修改和混入其他的merge。

了解了如何做好一次规范的提交与合并，接下来让我们看看通过DevCloud中的版本控制系统都能完成哪些具体的实践。

由于DevCloud提供的是基于Git的版本控制系统，因此所有Git的相关操作都可以在DevCloud上实现。

• 配置秘钥
• 管理代码仓库
• 查看提交记录
• 提交代码并关联工作项

  通过DevCloud我们可以将每次提交的代码记录与相应的工作项进行关联。

  在提交代码时，备注信息中输入fix #工作项编号即可在工作项的代码提交记录页面，查看到相关联的代码提交记录。

分支策略

我们都知道分支的意义，也知道它的用法，然而不同的分支管理方法对项目所起到的帮助也是不同的，下面就让我们来看看几种常见的分支策略，以及如何通过DevCloud来管理分支。

• Github flow
  • 特点：
    • 令master分支时常保持可以部署的状态。
    • 在新建的本地仓库分支中进行提交。
    • 以合并请求进行交流。
    • 让其他开发者进行审查，合并前的代码要经过测试。
  • 操作步骤：
    1. 创建分支
       • 在你创建了一个项目的分支的时候，你也就创建了一个可以尝试你的新想法的环境。
       • 你的分支名称应该具有描述性， 以便其他人通过分支名称就可以知道它到底是干什么用的。

       

    2. 添加提交
       • 每个提交操作都有一个相关的提交信息，用于描述你做出的修改。
       • 通过写清楚的提交信息，你可以让其他人更容易跟上我们的思路并提供反馈。

       

    3. 提出合并请求
       • 合并请求开启了一个关于你的提交内容的讨论。
       • 当你有很少或没有代码但想分享一些截图或一些想法的时候；当你卡住了需要帮助或建议的时候；或者当你准备好了让人来审查你工作的时候，合并请求启动代码审查和有关更改建议的会话。

       

    4. 讨论和评估你的代码
       • 审查你的更改内容的人或团队可以提供一些问题或者意见。
       • 你也可以在大家讨论和给出关于你提交内容的反馈时， 继续Push修改你的分支，来解决问题。

       

    5. 部署验证
       • 合入master代码前的最终部署测试，用真实环境检验版本的正确性。

       

    6. 合并
       • 合并之后，合并请求会保存一份关于你修改代码的历史记录。
       • 通过将某些关键字加入到你的合并请求文本中，你可以将问题与代码关联起来。

       

• Gitlab flow
  • 生产分支
    • 一个反映已部署代码的生产分支。
    • 将master的代码合入production。
    • 可消减Git flow中releasing、tagging、merging的开销。

    

  • 环境分支
    • 提交仅向下游流动，确保在所有环境中测试所有内容。
    • 如果要做hotfix，在一个功能分支上开发，然后合入master，master通过自动化测试后，将feature分支逐步向下游合并。

    

  • 发布分支
    • 一个分支就是一个版本。
    • 尽可能在master测试修改完，再开发布分支，减少多分支的bug修复。
    • 声明了发布分支后，该分支只接受严重bug的修复。
    • bug的修复先合入master，再往发布分支合入，上游优先策略。
    • 每在发布分支接受bug修复，都要使用新标签标示出来。

    

以上就是当前行业中集中比较流行的分支策略，DevCloud提供了基于Git的版本控制系统，接下来让我们看看如何应用DevCloud帮助团队管理分支。

通过DevCloud我们可以完成分支的创建与管理，对分支进行保护、创建合并请求、对代码的合并进行检视及评分、批准合并请求等一系列操作。

• 新建分支

  可以通过DevCloud提供的代码仓库直接创建分支，也可以通过本地仓库创建分支进行同步。

• 分支保护

  可以设置对某一重要分支进行保护，防止误操作对交付造成影响。

• 合并请求

  开发者提交的合并请求可在DevCloud中进行管理，通过对合并内容的检验，决定是否合并。

• 代码检视与打分

在DevCloud的版本控制系统中，还提供丰富多样的功能设置，例如IP白名单、子模组、webhook等常用的功能设置。运用版本控制系统，我们同样还可以进一步完善我们开发项目的软件配置、环境配置管理，关于如何进行软件配置管理与环境配置管理就不在此详细说明了。想掌握更多更详细的DevCloud代码仓库使用方法，详见代码托管用户指南。