为什么需要版本管理

相信很多开发者已经是直接使用git了，没有经历过svn的年代。但这不影响我们了解这个常识。

备注：本文的观点仅仅是个人的观点，不具有权威性，仅仅是工作感受，以及参考一些文章后的自我思考。

解决问题

版本的存在一定是解决问题的，解决哪几类的问题呢？

服务器环境

服务器环境是我们使用版本后最优先解决的问题，所以在版本里我们优先设置了针对环境的不同主分支，这些分支是每个环境所确定使用的分支，如果公司有在使用自动化部署，很可能会把环境与分支做严格的对应。比如下面的对应关系：

有了这个分支对应关系还不算完整，还需要对应的发布流程，以及发布流程中会如何使用这些分支，来保证以下几个原则：

• 不丢失更上一级的代码
• 在合并下一级代码时，预先让下一级代码合并上级代码，解决代码冲突问题
• 不污染其他环境的对应分支
• 等等

因此，我们制定了相应的每个分支更具体的定义，以及相应的分支流向。

点击查看： www.yuque.com/robinson/gi…

线上历史发布版本

线上历史发布版本主要针对两个可能情况：1 周期迭代版本 2 重大功能更新。这里不得不提，开源项目与非开源项目的区别。

那么我们针对自己的情况发布了不同的历史版本，究竟有什么具体用途呢？仅仅是留个历史版本摆着看么？当然不是。我能想到的是以下几点：

1.针对鲜明的功能版本做代码区分：在很多时候我们需要清楚知道一个功能的代码影响范围，通过功能版本我们可以清楚的看到；另外一个目的，就是，如果我们想针对某个功能版本，针对这个功能，做升级或者方案替换，那么目的会非常明显，也可以最大程度的参考之前的代码设计思维。

2.方便用户使用以及问题排查：主要是针对用户场景，针对不同版本我们会开放出不同功能，优化不同的问题，当用户反馈的时候，我们可以通过版本号，先模糊排查问题，如果是低版本的问题，用户进行升级即可。另外一个就是，有些版本的功能属于内测版本，或者最新版本，对于有些开发者比较倾向使用稳定版本或者历史版本，区分出版本利于开发者或者用户决定是否升级，或者指定使用哪个版本。

3.开发过程中的代码重置，这个有时候会发生，比如，我们开发某个功能，开发完成后，代码提到了测试分支，测试分支也改了一些代码，但是此时项目经理说，这个版本完全废弃或者延期上线，你怎么办？首先，需要明确的是，我们需要把测试分支重置到上一个没有合并开发分支的版本，你可以通过寻找test分支的历史提交记录，或者适用beta分支重置，如果beta分支是确定不会污染测试分支的没有bug的，但如果你有历史发布版本的话，其实问题就很简单了，你只要重置为上一个历史发布版本即可，最少这是一种可行方案，当然这种的前提是，你完整的丢弃test分支所做的开发合并。

4.线上发布中的版本重置，当我们发现发布某个版本时，导致了线上版本的崩溃，而且短期内不能解决问题，那么作为运维人员，只要将上个发布版本的代码重新发布一遍作为预备方案就可以了。（这里只考虑代码导致的问题，其他数据库的数据回退等这里不做考虑）

5.不同模块的沟通以及依赖机制，一般情况下，很多时候我们的代码还会依赖于其他人项目的版本，而如果对方没有相应的准确的版本号描述，其他同学便不知道该使用你的哪个版本，很多时候并不是最新的版本或者线上版本，而是另一个版本。

本地仓库与远程仓库

说道本地仓库有什么用，当然要提到本地仓库的一些特点，以及之前没有本地仓库之前的存储机制是如何的。

在没有本地仓库之前，大家想存储代码一般是必须通过直接提交到远程的，而且必须有网络，但这样有个明显的问题就是我们可能会把有问题的代码也提交上去。而别人正是通过拉取远程代码同步的，如果你把没有开发完成的代码提交上去，会导致使用同项目的开发同学遇到自己所不了解的代码问题。

而本地仓库的两个明显优点：1 可以离线存储 2 可以实现在本地存储代码而不提交到远程。也正由于第二个特点，我们对提交本地仓库代码的clean的要求有所放低。当你认为自己代码没问题时，在一次性与远程同步即可。 在你没有提交到远程时，别人同步拉取的代码都是正确的。

所以当团队内的成员代码之间有依赖关系的时候，需要对团队成员的提交做一定的限制说明，提交到远程的代码，尽量是clean，righ的，或者最少在推送修改时，通知到相关的使用人。

多人协作

多人写作最明显的是开发环境下，大家从开发分支拉出不同的分支。这里面有两种主要可能情况：

1 基于开发分支，不同人拉不同功能的feature分支，然后具体功能只在对应功能分支上开发，完成开发之后再聚合到develop分支上，分分支的时候，以dev-featureName为区分。

2 基于开发分支，同一功能需要不同开发者协作完成，完成开发之后再聚合到develop分支上，分分支的时候，以dev-featureName-name为区分。

bugfix分支

一般情况下，我们只对线上分支的bug拉bugfix分支进行问题修订，确定修补完成，再合并到主分支。所以它的流向会是：

release/master ==> bugfix ==> release/master

而在预发布环境，测试环境，开发环境，因为其造成的影响不是很大，所以一般是不会针对一个具体的bug拉取问题分支的，而是在对应环境分支直接修改所有问题。但如果有必要，为了减少对他人的开发，你也可以拉分支。

同分支历史版本

这一点主要是我们对同一个开发分支，对重要的提交做备注，以及可以找到不同提交状态下的hash值，得到这个值之后，我们可以根据提示的commit msg，结合hash更快的回到某个历史状态。

所以如果你想更好的利用好这一点，对我们提交记录填写的信息的规范性很重要。

版本对比分析，做cr

这个主要发生在两种主要情况：

1 代码合并请求，也就是merge request,当代码发起归并请求时，为了降低风险，我们一般会对将要合入的代码做两个分支的代码对比，仔细查看两个分支的代码区别，一一排查区别与问题。

2 排查问题，主要针对，原来的分支是么有这种问题，新开发分支相对有问题时；或者也可能是相反的关系，我们可以更快的通过代码对比， 找出差异代码就行问题的纠正。

我们需要如何操作

其实，不同分支的用途以及整个分支的变化过程还是比较严格的，基本可以满足我们各种需求，我们有必要了解所有分支的可能，以及代码分支流向。但还必须有几个基本点把握：

1 我们需要知道所有不同的分支分别用于解决什么问题，分支的代码流向设计成如何可以解决什么问题。

2 不是所有团队都严格执行分支流向管理和版本管理，对此不必过于执念，能解决当前需求的情况下，就按照怎么简单怎么来；但是当分支管理出现问题的时候，我们需要心中有一定的分支管理方案。

3 基本的分支状态，代码同步的命令要知道，虽然我们可以借助 工具 来完成，但为了更好的理解这个过程，最好是自己操作一遍命令的方式同步分支代码的过程。。

4 对于分支，除了借助规范，更重要的是培养团队的版本意识，灵活的解决各种问题的分支管理方案。当认知不在一个层次时，你认为很合理的内容可能别人认为没必要；也可能会出现，别人的认知很合理，而自己由于认知不到位，看不到潜在问题，而盲目反对对方的分支管理规范。