标签：最新版本 flow 针对 面向 download image 角色 免费 集成测试
本文主要帮助已经掌握或者想要掌握Git的开发者，如何更好的应用Git，以及更好的将Git与DevCloud结合应用。
从狭义上来说，版本控制系统是软件项目开发过程中管理代码所有修订版本的软件，能够存储、追踪文件的修改历史，记录多个版本的开发和维护，事实上我们可以将任何对项目有帮助的文档交付版本控制系统进行管理。版本控制系统（Version Control Systems）主要分为两类，集中式和分布式。
集中式版本控制系统的特点是只有一台中央服务器，存放着所有研发数据,而其它客户端机器上保存的是中央服务器最新版本的文件快照，不包括项目文件的变更历史。所以，每个相关人员工作开始前，都需要从这台中央服务器同步最新版本,才能开始工作。
集中式版本控制系统的优点：
1. 操作简单，使用没有难度，可轻松上手。
2. 文件夹级权限控制，权限控制粒度小。
3. 对客户端配置要求不高，无需存储全套代码。
集中式版本控制系统的缺点：
1. 网络环境要求高，相关人员必须联网才能工作。
2. 中央服务器的单点故障影响全局，如果服务器宕机，所有人都无法工作。
3. 中央服务器在没有备份的情况下，磁盘一旦被损坏，将丢失所有数据。
分布式版本控制系统的特点是每个客户端都是代码仓库的完整镜像，包括项目文件的变更历史。所有数据分布的存储在每个客户端，不存在中央服务器。可能有人会问，我们公司使用Git分布式存储工具，也有“中央服务器”啊？其实,这个所谓的“中央服务器”仅仅是用来方便管理多人协作，任何一台客户端都可以胜任它的工作，它和所有客户端没有本质区别。
分布式版本控制系统的优点：
1. 版本库本地化，版本库的完整克隆，包括标签、分支、版本记录等。
2. 支持离线提交，适合跨地域协同开发。
3. 分支切换快速高效，创建和销毁分支廉价。
分布式版本控制系统的缺点：
1. 学习成本高，不容易上手。
2. 只能针对整个仓库创建分支，无法根据目录建立层次性的分支。
使用华为软件开发服务，首先需要免费注册一个华为云账号。
Git是一款开源的分布式版本控制系统(Distributed Version Control System) ，诞生于2002年，由Linux之父Linus Torvalds带领Linux开源社区开发完成，初衷是用其管理Linux内核的庞大的开源代码。在当今敏捷开发成为主流,研发周期短，跨地域协同开发多的大形势下，选择Git版本管理工具是大势所趋。国内外有很多基于Git的云端代码托管服务，华为软件开发服务（Devcloud）配置管理服务就是其中之一。
代码托管（CodeHub）是面向软件开发者提供的基于Git的在线代码托管服务，包括代码克隆/下载/提交/推送/比较/合并/分支等。代码一键下载到本地，基于本地IDE开发，开发完毕一键推送云端，实现线上线下协同开发
Git Bash客户端软件是本地PC使用git必须安装的软件，如果本地没有安装，请到https://git-scm.com/downloads下载。
安装成功以后，在开始菜单中会增加Git Bash选项。
安装完成，运行Git Bash，在弹出终端页面按照下面操作进行个人配置。
运行Git Bash, 生成一对SSH密钥，在弹出的终端中输入下面命令，回车后会提示您输入一个密码，建议不输入，一路回车即可。
此时，会在~/.ssh文件夹下生成了一对密钥，公钥id_rsa.pub和私钥id_rsa，私钥无需处理，保存在本机就可以了，公钥的内容需要拷贝到软件开发服务中。
创建项目
在华为云官网首页 产品 软件开发服务，进入华为软件开发服务首页。
点击右上角“新建”按钮新建项目
输入项目名称，选择开发流程，输入项目描述，点击“新建”按钮即完成了一个项目的创建。
在开发云代码服务中，点击上方“新建仓库”按钮
新仓库的详细配置如下:
新建成功
第一步：运行Git Bash，在终端执行如下命令，会将.ssh文件夹下的id_rsa.pub公钥内容（灰色背景的字符串）打印到终端，拷贝这些字符串，注意不要有多余的空格。
第二步：在开发云代码服务中，点击右上角的“设置SSH密钥”
第三步：继续点击右上角的“添加SSH密钥”
第四步：粘贴拷贝的公钥字符串，添加“标题”，点击“新建”就可以了。
在本地准备克隆代码的目标文件夹，右键打开git bash终端
执行如下命令：
一次修改被成功提交到远端仓库会历经四个阶段，1本地工作区->2缓存区->3版本库->4远端版本库，通过执行相应的Git命令，文件在这四个区域跳转，并呈现不同的状态，主要涉及三步操作：
#git add/rm filename //将新增、修改或者删除的文件增加到暂存区
#git commit –m “commit message” //将已暂存的文件提交到本地仓库
#git push //将本地代码仓库修改推送到远端仓库
Git新建分支的本质就是创建一个指向最后一次提交的可变指针，所以，Git分支的创建不是复制版本库的内容，仅仅是新建了一个指针，它以40个字符长度SHA-1字串形式保存在文件中。
#git branch branchName commitID
基于commitID即某一个全球版本号拉出新分支，如果没有commitID则基于当前分支的HEAD拉出新分支。
如下图新建feature分支执行的命令为git branch feature
#git checkout branchName
如下图切换到feature分支执行的命令为git checkout feature
无论哪种工作流都会涉及到分支合并（把一个分支中的修改整合到当前分支），主要有两种方法：三方合并（merge） 和衍合（rebase）。我们通过对同一种场景进行不同操作体会两种合并方法的区别。
场景：master分支新增了C4节点， hotfix分支新增了C3节点，现将hotfix分支合并到master分支：
1. 三方包括hotfix新增节点C3，master新增节点C4，以及两者的共同祖先节点C2。这种合并操作简单，但新增合并节点C5，形成了环形，版本记录可读性差。
#git checkout master
#git merge hotfix
2. 衍合先将master分支新增节点C4以补丁形式保存在.git/rebase目录中，然后同步hotfix分支最新代码，再应用补丁C4’。
#git checkout master
#git rebase hotfix
类型一：两个合并分支修改了同一行代码
解决方法：
1. 分析哪种修改方法正确，手动合并；
2. 提交修改。
类型二：文件被重命名为不同的名字
解决方法：
1. 确认哪个名字是正确的，删除错误的；
2. 提交修改。
什么是Git工作流？你可以理解为代码管理的分支策略，它不仅仅是版本管理范畴，更服务于项目流程管理和团队协同开发。所以，我们有必要制定适合自己研发场景的工作流。
下面介绍四种工作流的工作方式、优缺点，以及使用中的一些注意事项。
1. 集中式工作流
2. 功能分支工作流
3. gitflow工作流（Devcloud推荐）
4. forking工作流
集中式工作流适合5人左右小开发团队，或是刚从SVN工具转型为Git的团队，它只有一个默认的maste分支（相当于svn的trunk主分支），所有人的修改都是在master分支上进行的。但是，这种工作流无法充分发挥git优势和多人协同，不推荐使用。
工作方式：
开发人员将master分支从中央仓库克隆到本地，修改完成后再推送回中央仓库master分支。
优点：
不涉及分支交互操作
缺点：
1. 不适合人员较多的团队，当人员10+时，解决开发人员之间的代码冲突会耗费很多时间；
2. master分支提交频繁；
3. master分支不稳定，不利于集成测试。
Tips：如何尽量避免产生冲突和不合理的提交历史？
开发人员在开发一个新功能之前，一定要在本地同步中央仓库最新代码，使自己的工作基于最新的代码之上；开发完成后，在提交新功能到中央仓库前，需要先fetch中央库的新增提交，并rebase自己的提交。这样做的目的是，把自己的修改加到中央仓别人已经提交的修改之上，使最终的提交记录是一个完美的线性历史，而不是环形。
举例：
1. 开发人员A和开发人员B同时在某个时间拉取了中央仓库的代码
2. 开发人员A先完成了自己的工作，并提交到中央仓库
3. 开发人员B需要在本地执行git pull –rebase中央仓库的新提交，这时开发人员B的本地仓库就包含了开发人员A修改的内容，并在A的基础上增加了自己的修改
4. 开发人员B将代码推送到中央仓库
通过新建几个功能分支，增加开发者的交流和协作，它的理念是所有的功能开发都应该在master分支外的一个独立分支进行，这种方式隔离了开发者的工作空间不被互相干扰，保证了master分支的稳定性。
工作方式：
开发人员每次在开始新功能开发前，需要在master分支上拉取一个新分支，并起个有描述性的名字，比如video-output或issue-#1061，这样可以让分支用途明确。功能分支不但存在开发人员本地仓库，也应该推送到中央仓库，这样就可以在代码不合入master分支的情况下与其他开发人员分享代码。
优点：
分支合并前可以使用pull request进行code review；
降低了master分支的提交频率
缺点：
只有一个master分支作为集成，仍然不是很稳定，不适合大型开发
Gitflow一般用于管理大型项目，它为不同的分支分配一个很明确的工作角色，并定义分支之间什么时候进行交互。
工作方式：
master分支：生产分支，最稳定的版本，一直是ready to deploy状态。不接受开发人员直接commit，只接受从其他分支merge操作。在很多企业中，这个分支被默认开启分支保护，只有维护者可以操作。
hotfix分支：从master分支拉取的临时修复分支，用于解决一线紧急bug。bug解决后需要合入master分支并打上新的版本号，这个修改也需要同时合入develop分支。
develop分支：从master分支拉取的开发分支，用于功能集成。包含所有要发布到下一个Release的代码用于开发集成、系统测试。
release分支：临近既定的发布日，就从develop分支上拉取一个release分支，任何不在当前分支中的新功能都推到下个发布中。release分支用于发布，所以从当前时间点之后新的功能不能再加到这个分支上，这个分支只做Bug修复、文档生成和其它面向发布的任务。当对外发布的工作都完成了，release分支合并到master分支并分配一个版本号打好Tag；另外，这些从release分支新做的修改要反向合并回develop分支。
feature分支：开发者使用的特性分支，父分支是develop分支，当新功能完成时，合入develop分支。新功能提交从不直接与master分支交互。
开发人员提交新功能的两种途径：
1. 团队有专人review审核新功能
a) 开发人员将feature分支推送到华为软件开发云代码托管平台（中央仓库）
b) 发起一个从feature分支合并到develop分支的pull request请求，并指给review专员
c) review专员审核。如果通过，将feature分支的新功能合并到develop分支，并删除feature分支；如果未通过，拒绝该请求并注明拒绝原因。
2. 开发人员自审核新功能
a) 开发人员在本地仓库将feature分支合并到develop分支，并删除feature分支
b) 将本地develop分支的修改推送到华为软件开发云代码托管平台（中央仓库）
优点：
1. 使用一个用于发布准备的专门分支（release分支），使得一个团队可以在完善当前的发布版本的同时，可以在develop分支并行继续开发下个版本的功能。这也打造了可视化的发布阶段，团队成员都可以在仓库网状结构中可以看到发布状态；
2. 使用紧急修复分支（hotfix分支）让团队可以处理紧急问题的同时而不打断其它工作或是等待下一个发布再合入hotfix修改。我们可以把hotfix分支想成是一个直接在master分支上处理的临时发布；
3. 大型项目人员协作频繁，流程较多，合理的多角色分支帮助研发有条不紊进行；
4. 更符合devops理念。
缺点：
1. 学习成本较高；
2. 如果团队不遵守使用约定，带来的影响更大。
Forking工作流区别于前三种工作流的最大特点是每个开发人员都有一个从公共仓库fork出来的属于自己的公共仓。Forking工作流适合外包、众包以及众创和开源场景。接包方的开发人员从项目公共仓fork自己的公共仓库进行操作，并不需要被项目公共仓直接授权。
工作方式：
将“项目公共仓”fork出一个“个人公共仓”
将“个人公共仓”clone到“本地仓库”
操作“本地仓库”，修改完成后提交到“个人公共仓”
为“个人公共仓”提交一个pull request给项目维护者，申请代码合入“项目公共仓”
项目维护者在本地review、验证本地提交，审核通过后push进入“项目公共仓”
Tip：如果开发人员A的代码未被审核通过合入“公共仓库”，而此代码对开发人员B有借鉴作用，开发人员B可以直接从开发人员A的“个人公共仓”拉取代码。
优点：
1. 开发人员之间若需要代码协作，可以直接从其他人的“个人公共仓”拉取，无需等到代码提交到项目公共仓；
2. “项目公共仓”无需为每个代码贡献者授权；
3. 项目维护者通过审核pull request成为代码安全的重要防线；
4. 仓库分支的选择可以根据项目实际情况综合使用前三种工作流。
缺点：
1. 提交步骤繁琐，开发人员代码到最终版本库的周期较长。
研发团队可以根据实际研发场景制定合理的工作流，能有效提高项目管理水平和团队协同开发能力， 并通过DevCloud的CodeHub平台，高效、安全的管理代码资产，将更多的精力集中在业务开发上，实现持续集成、持续交付和快速迭代的目标。
华为云DevCloud，5人以下额度范围内，可以免费使用，并且可以预约免费的产品演示和技术交流，详情查看华为云官网
华为云实战开发】5.如何快速创建免费Git代码仓库【华为云技术分享】
标签：最新版本 flow 针对 面向 download image 角色 免费 集成测试
原文地址：https://www.cnblogs.com/huaweicloud/p/12016294.html
