源代码管理工具

 

1.1、什么叫源代码管理工具

源代码管理工具也叫版本控制系统，是保存文件多个版本的一种机制。每一次有人提交了修改，这个修改历史都会被版本控制系统记录下来。如下图所示，每一次对内容的修改，都会形成一个当前项目完整内容的快照。

1.2 源代码管理工具的发展历史

  最早的版本控制系统是 SCCS（Source Code Control System），诞生于 1972 年，它实现了对单个文件保留多个版本，这就意味着你可以看到每一个文件的修改历史了。后来又有了 RCS （Revision Control System），它具有更好的文件比较算法，通过登录同一台中央大型机，可以实现每个人签出自己的拷贝。但这个阶段只能本机使用，而且一次只能修改一个文件，无法满足好多人协作的问题。

  

  1986 年问世的 CVS（Concurrent Versions System）是第一个采用集中式的服务器来进行版本库的管理工作，所有文件和版本历史都放在服务端，每个用户通过客户端获取最新的代码，可以多个人编辑一个文件，并且能提交到服务器合并在一起。再后来的 SVN（Subversion）则对 CVS 进行了很多优化，比如支持文件改名移动、全局版本号等，这些优化很大部分程度上解决了 CVS 存在的一些缺陷，所以在 2000 年后逐步取代了 CVS 成为主流的源代码管理工具。

 

  分布式版本管理工具的典型代表就是 Git，分布式版本控制系统的整个代码库的副本都可以存储在用户的本地系统上，这样文件和版本控制操作变得非常容易，离线也可以操作，如果主存储库关闭或者删除，可以很容易从本地存储库恢复。现在 Git 已经逐步替代了 SVN、CVS 等源代码管理工具，成为最主流的源代码管理工具。Git 的主要问题是学习成本要稍微高一点，要花点时间理解它的工作原理和记住主要的命令

 

 2、源代码管理工具——GitHub

GitHub现在已经是全球最流行的代码托管平台，功能强大，和第三方服务集成非常好。而且私有的代码库如果不超过 3 个人都是免费的。

 

GitHub的 Web UI 非常强，尤其是代码浏览和审查，在网站上就可以提交 Pull Request 和进行代码审查。不过 GitHub 不提供 CI 服务，需要和第三方 CI 服务集成。

GitHub可以托管各种git库，并提供一个web界面，但与其它像 SourceForge或 Google Code这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace。

 

2.1  GitHub 开发流程

GitHub 开发流程的关键在于两点：

1. 有一个稳定的分支，例如 master；

2. 每次创建新功能或者修复 Bug，必须创建一个分支。

3. 最后通过代码审查和自动化测试，才能合并回稳定分支。 

通过这样的开发流程，就相当于把自动化测试和代码审查作为一种强制性要求了，所有的修改必须要通过代码审查和自动化测试通过才能合并，从而保证有一个可以随时部署发布的稳定分支。下面是 Github flow的开发过程。

第一步：创建一个分支

分支是 Git 中的核心概念，整个 GitHub 流程都是基于分支展开的，master 分支是要一直保持稳定的，不能直接在 master 上开发。

 

无论你是要开发一个新功能还是修复一个 Bug，第一件事永远是从 master 创建一个分支出来。

 

 

 第二步：提交更新

 

当创建好分支后，就可以基于分支开始工作了，这时候就可以按照前面建议的原则，频繁的提交更新。注意每次提交的时候，要加上说明性的信息，让其他人明确知道你这次提交的内容是什么，如果开发过程中，发现错误了，还可以随时回滚之前的更改。

 

 在Github中，可以通过git log命令来查看历史提交记录：

 

 通过：

 

 

第三步：创建一个 Pull Reques

在开发完成后，创建一个 Pull Request（合并请求，简称 PR，Gitlab 中叫 Merge Request），创建 PR 时，通常要附上描述性的信息，关联上相应的 Ticket 连接，让其他人知道你这个 PR 要完成什么任务。创建好 PR 后，其他人就可以直观的看到你所有的修改。

 

具体操作

 

 选择你所编辑的分支,与主分支进行比较

 

 

在对比页面检查分支间的差异,确保它们是你想提交的内容

 

 

 

 

当你对想要提交的修改满意时,单击绿色的 Create Pull Request 按钮

 

 

为你创建的 Pull Request 命名,并简要说明你做出的修改

 

 

当组内的成员需要知道一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的

在Github中，执行git blame命令，即可显示每一行都是什么时候签入的，为了什么目的签入的，签入人是谁

 

 

 第四步：讨论和代码审查

 

当你的 PR 提交后，团队的其他人就可以对 PR 中的代码修改进行评论。比如说代码风格不符合规范、缺少单元测试、或者很好没有问题。PR 的主要目的就是为了方便大家做代码审查。

 

根据代码审查的结果，你可能要做一些修改，那么只要继续提交更新到这个分支就可以了，提交更新后，PR 就会自动更新，其他人可以基于你的更新进一步的讨论和审查，直到通过代码审查。

 

 

第五步：部署测试

 

在合并前，还需要把分支的修改进行测试。理论上来说，需要将修改的内容部署到测试环境测试，但这样效率太低了，所以通常的做法是借助持续集成工具，在每次提交代码后，就运行自动化测试代码，自动化测试代码全部通过后，就可以认为质量是可靠的。

 

这也意味着你需要让项目中的自动化测试代码保持一定的测试覆盖率，否则质量还是难以保障的。

 

 第六步：合并

 

当你的代码通过了代码审查和自动化测试，就可以将代码合并到 master 分支了。合并后，之前的分支就可以删除，但你之前所有的提交记录在 master 都可以看到，所以完全不用担心丢失历史版本记录。

 

 2.2  GitHub 开发流程的几个常见问题

• 怎么发布版本？

要发布版本的话，从 master 上创建一个 Tag，例如 v1.0，然后将 Tag v1.0 上的内容部署到生产环境。

 

• 怎么给线上版本打补丁？

如果线上发布的版本（例如 v1.0）发现 Bug，需要修复，那么基于之前的 Tag 创建一个分支（例如 hotfix-v1.0-xxx）出去，在分支上修复，然后提交 PR，代码审查和自动化测试通过后，从分支上创建一个新的 Tag （例如 v1.0.1），将新的 Tag 发布部署到生产环境，最后再把修改合并回 master。

 

• 经常打补丁，比 Tag 更好的办法？

每次发布后，可以创建一个发布版本的分支，例如 release-v1.0，每次打补丁，都直接从发布分支 release-v1.0 而不是 master 创建新的分支（例如 hotfix-release-v1.0-xxx），修复后提交 PR，代码审查和自动化测试通过后，合并回分支 release-v1.0，然后基于 release-v1.0 分支发布补丁。最后将合并的 PR，借助 git 的 cherry-pick 命令再同步合并回 master。