为何须要版本管理

前言

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

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

解决问题

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

服务器环境

服务器环境是咱们使用版本后最优先解决的问题，因此在版本里咱们优先设置了针对环境的不一样主分支，这些分支是每一个环境所肯定使用的分支，若是公司有在使用自动化部署，极可能会把环境与分支作严格的对应。好比下面的对应关系：

环境	分支名	备注
线上	release	发布以后，有的公司可能会针对重要的release发布version
预发布	beta	拟生产环境，主要回归功能在线上数据和环境下是否有问题
测试	qa/test	主要的测试环境，也有的称为集成测试，由于有的开发代码可能原先是单独测试，没有考虑互相的影响
开发	develop	主要的开发环境，开发分支，开发完成后都要归并到这个分支

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

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

所以，咱们制定了相应的每一个分支更具体的定义，以及相应的分支流向。

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

线上历史发布版本

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

项目类型	发布缘由、频率	备注
开源项目（技术框架）或者公司四研发的客户端软件版本	大的功能更新，更新频率更低	主要是针对功能版本发版本，避免版本发布过于频繁对用户的影响，比较明显的像基本的技术框架，app版本
非开源项目（后端项目版本，web版本）	周期性迭代（频率很高）	周期性迭代，是指每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 对于分支，除了借助规范，更重要的是培养团队的版本意识，灵活的解决各类问题的分支管理方案。当认知不在一个层次时，你认为很合理的内容可能别人认为不必；也可能会出现，别人的认知很合理，而本身因为认知不到位，看不到潜在问题，而盲目反对对方的分支管理规范。

面试相关

通常技术面试，多少都会问到大家的项目研发流程如何，代码是基于git如何进行分支管理的，发布流程中的代码流向是如何的，若是你以前只是放任团队里其余人说你要提个mr，而不知道为何如此，可能本文正是你应该知道的常识。

友情连接

git常识小册:www.yuque.com/robinson/gi…