共计 2043 个字符，预计需要花费 6 分钟才能阅读完成。
Git 的研发应用场景是怎样的，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
Git 诞生于 2002 年，由 Linux 之父 Linus Torvalds 和他的团队开发并不断完善，它秉承了 Linux 的开源精神，为广大研发团队带来了非常棒的版本控制体验。下面立足 Git 的工作原理，深入探讨各种研发场景中工作流等问题。
Git 工作模式
代码提交过程
一次修改被成功提交到远端仓库会历经四个阶段，1 本地工作区 - 2 缓存区 - 3 版本库 - 4 远端版本库，通过执行相应的 Git 命令，文件在这四个区域跳转，并呈现不同的状态：
1. 已修改（modified）：包括三种文件，新增文件，被修改的文件，被删除的文件
2. 已暂存（staged）：对已修改的文件执行 git add 或 git rm 操作，文件就变成已暂存状态，进入暂存区。暂存区实际上就是一个文件索引目录树，记录了所有文件名、文件状态信息，它已索引的方式建立了文件名和文件内容（在对象库.git/objects 中保存）的对应关系。
3. 已提交（committed）：对已暂存的文件执行 git commit 操作，文件就变成已提交状态，进入本地版本仓库。
4. 已上传：对已提交的文件执行 git push 操作，文件就变成已上传状态，进入远端版本仓库。
Git 如何记录每次提交
我们思考一下，版本控制系统应该如何记录每次提交呢？正常的思维肯定是记录“差异”（delta），也就是前后两个版本中文件内容的不同，确实大多数版本控制系统是这么做的，比如我们所熟悉的 CVS，SVN。但是，Git 却不这样！每次提交更新时，Git 会对全部文件作一个快照（snapshot），并保存指向这次快照的索引。
这种保存方式带来很多好处，切换版本时，直接引用指向目标版本的索引即可，不需要像差异存储那样，需要版本之间的 merge，速度会快很多，更重要的是，为后文所讲到的轻量级分支切换提供了前提条件。
Git 分支
Git 新建分支的本质就是创建一个指向最后一次提交的可变指针，所以，Git 分支的创建不是复制版本库的内容，仅仅是新建了一个指针，它以 40 个字符长度 SHA- 1 字串形式保存在文件中，这难以想象的轻量级就是源于“快照”保存的版本设计理念。
Git 工作流
什么是 Git 工作流？你可以理解为代码管理的分支策略。这里从典型的 GitFlow 工作流出发，配合我正在使用的代码托管平台 (华为软件开发云)，给大家详细讲解工作流是如何服务于项目流程管理和团队协同开发。
Ømaster：主线分支，版本有较强稳定性，供生产环境部署使用，这个分支只能从其它分支合并，不能在这个分支上直接提交修改。
新建分支：
在开发云界面输入新分支名，并选择从哪个分支检出即可。
Ødevelop：主开发分支，用来集成测试最新合入的开发成果，包含要发布到下一个 Release 的代码。
Øfeature：特性分支，每个特性一个分支，用于开发人员提交代码并进行自测。一旦开发完成，我们合并回 Develop 分支进入下一个 Release。
Øhotfix：补丁分支，生产环境发现新 Bug 时创建的临时分支，问题验证后，合并到 Master 和 Develop 分支，所以 Hotfix 的改动会进入下一个 Release
Ørelease：发布分支，发布新版本时，基于 Develop 分支创建，发布完成后，合并到 master 和 develop 分支。
各个分支之间的关系可以从开发云的“仓库网络”中查看：
优点：项目管理流程明确
缺点：相对复杂，需要同时维护两个长期分支，不适合网站项目。
分支合并
无论哪种工作流都会涉及到分支合并（把一个分支中的修改整合到当前分支），主要有两种方法：三方合并（merge）和衍合（rebase）。我们通过对同一种场景进行不同操作体会两种合并方法的区别。
场景：master 分支新增了 C4 节点，hotfix 分支新增了 C3 节点，现将 hotfix 分支合并到 master 分支：
1. 三方包括 hotfix 新增节点 C3，master 新增节点 C4，以及两者的共同祖先节点 C2。这种合并操作简单，但新增合并节点 C5，形成了环形，版本记录可读性差。
a)PC 端命令操作方式：
#git checkout master
#git merge hotfix
b) 开发云平台页面操作：
第一步：
第二步：
2. 衍合先将 master 分支新增节点 C4 以补丁形式保存在.git/rebase 目录中，然后同步 hotfix 分支最新代码，再应用补丁 C4’。
#git checkout master
#git rebase hotfix
冲突解决
类型一：两个合并分支修改了同一行代码
解决方法：
1. 分析哪种修改方法正确，手动合并；
2. 提交修改。
类型二：文件被重命名为不同的名字
解决方法：
1. 确认哪个名字是正确的，删除错误的；
2. 提交修改。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。
