前言
虽然现在 Git 的可视化操作工具有很多也用的很爽，但多少还是得知道 Git 命令的常用操作和一些概念。毕竟面试的时候也有可能会问起一些工作流程。去年有幸外派到大公司接触到一群大佬，和他们对比起来的话在一些基础的细节方面和他们有很大差距吧。
本文也是参考的掘金社区上面的文章，出处已在末尾一一标明。
我刚工作那会最先使用的SVN，先简单介绍一下。
SVN
SVN 是比较经典的集中式版本管理工具，版本是集中存放在中央服务器的，所有的版本都存放在中央服务器，如果脱离中央服务器，开发者基本上无法工作。（不能更新/提交代码）。其优点可能就是操作简单，直接使用图形管理工具即可。
GIT
分布式版本控制系统，他没有中央服务器，每个人的电脑就是一个完整的版本库。开发完成再将各自代码推送到远程Git仓库即可。
GIT 相关概念
Workspace：工作区，就是本地再开发改动的地方，当前最新的内容，再开发过程中就是对工作区的操作。
Staged / Index: 暂存区 当执行 git add 的命令后，工作区的文件就会移入暂存区，暂存区标记了当前工作区那些内容是被Git管理的。所以当完成某个需求或者功能时第一步就要git add先提交到暂存区。
Repository：本地仓库，位于自己电脑上，通过git commit提交暂存区的内容会进入本地仓库。
Remote：远程仓库，用来托管自己代码的服务器，远程仓库的内容能够被分布到多个地点的处于协作关系的本地仓库修改，本地仓库需改完成代码之后通过git push同步到远程仓库。
Git三种状态
- Untracked: 未跟踪
- Unmodify: 文件已经入库，未修改
- Modified: 文件已修改
- Staged：暂存状态
Git工作流介绍
- 集中式工作流
- 功能分支工作流
- Gitflow 工作流
- Forking 工作流
集中式工作流
以中央仓库master分支作为项目所有修改的单点实体，所有的修改都提交到这个分支上，适合单人开发或三人小团体开发一次性项目。
功能分支工作流
这张工作方式是以集中式工作流为基础，再为不同的功能分配单独的功能分支来进行。这种工作流方式主干分支依然是master分支，但是开发者在进行日常需求开发时不能直接将代码提交到master分支上，一般是为特定需求创建一个新的功能分支。在各自分支上开发就不会弄乱主干分支代码，保证master分支的稳定性。同时还可以做对应的Pull Request 请求去和合并代码。还有利于Code Review，也有利于代码的权限
Gitflow 工作流
目前非常成熟的一个方案，没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并且定义分支之间职责和什么时候进行交互，他定义一个项目发布的严格分支模型，gitflow 工作流常驻的分支有两个：主干分支 master、开发分支 dev（master分支存储了正式发布的历史，而dev分支作为功能的集成分支），此外针对项目研发的各个阶段，也可以设定特定的分支。
1.主要分支
主要分支包括Master 和 Develop（Dev）前者用于正式发布，后者用于日常正常开发，常设分支用这两个就够了，不需要其他的了
Master分支（主） 该分支代码可以随时部署到生产环境，这个分支只能从其他分支合并，并且不能在这个分支做任何修改，每次封板后由主程序员合并release代码进来，发布完以后打上tag，开发人员不能随意操作。
develop分支（开发）用来开发的分支，通常可以直接在其上进行开发，在每次发布版本（release）和线上紧急bug（hotfix）修复后，需要同步到其上。理论上此版本只在开发阶段使用，提测时不可以直接修改， 而在测试结束后由release分支合并到其上。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
2.临时性分支
除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：功能分支 （feature），预发布分支 (release)，修补bug分支 (fixbug)，这三种分支都属于临时性需要， 使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
release分支（预发布）： 在发布正式版本之前（即develop合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，所有测试阶段的bug全部在此分支修复，测试结束后，必须合并进Develop和Master分支。 它的命名，可以采用release-xx的形式。
feature分支（功能）： 为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。功能分支的名字，可以采用feature-XX的形式命名。如果在团队开发时，有一个功能的开发周期要长过本次版本开发周期， 建议开启一个 feature 进行单独开发，当需要此功能的时候，只需要将 feature 合并入 develop 分支，下次一并提测即可。 这样设计可以避免这个功能在尚未开发完成或者通过测试的时候混入发布的版本，而导致不可预知的不稳定。当然也可以同时开启多个 feature 分支进行不同新功能开发，在合适的时候合并提测即可。
hotfix分支（bug修复）： 软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-XX的形式。 线上bug修复的热补丁分支，应由 master 拉出，并在修复完成后合并入 master 和 develop 保证两分支的bug已修复。
3. 新功能开发中，各角色的工作流程
(1.)前置阶段(新功能启动)
- 开发主管->基于master主干创建一个develop分支。
现有主干分支: master、develop
(2.)开发阶段(开始开发)
- 功能开发人员->基于develop分支创建一个feature_XX分支。
- 功能开发人员->在feature_XX分支上开发新功能。
- 功能开发人员->新功能开发完成以后，在git上发起Pull request把代码合并到到develop分支上。
- 开发主管->确认代码没问题，通过该合并请求。
现有主干分支: master、develop、feature_XX
(3.)测试阶段(开发完毕)
- 开发主管->基于develop分支创建一个分支名为release-1.0.0的预发布版本。
- 测试人员->对release-1.0.0分支的代码进行测试，测试通过在git发起Pull request把release-1.0.0代码合并到到master分支上。
现有主干分支: master、develop、feature_XX、release-1.0.0
(4.)发布阶段(测试通过)
- 开发主管->基于master分支创建一个里程碑版本(tag)名为1.0.0-Release。
- 删除完成使命的其他分支:feature_login、release-1.0.0。
现有主干分支: master、develop、1.0.0-Release(tag)
4.线上代码出现bug时，各角色的工作流程
(1.)前置阶段(提交bug)
- 测试人员->发现问题，基于1.0.0-Release里程碑版本在git上新建一个issue。
现有主干分支: master、develop、1.0.0-Release(tag)
(2.)修复阶段(开始修复bug)
- 功能开发人员->基于1.0.0-Releasetag创建一个hotfix_XX(该issue序号)分支，开发人员在hotfix_XX分支上修复bug，修复完成后，在git上发起Pull request把代码合并到到master主干上。
- 开发主管->确认代码没问题，通过该合并请求。
现有主干分支: master、develop、1.0.0-Release(tag)、hotfix_0001
(3.)测试阶段(bug修复完毕)
- 测试人员->对master分支的代码进行测试。
现有主干分支: master、develop、1.0.0-Release(tag)、hotfix_0001
(4.)发布阶段(测试通过)
开发主管->基于master分支创建一个里程碑修复版本(tag)名为1.0.1-Release， 删除完成使命的其他分支:hotfix_XX。
现有主干分支: master、develop、1.0.0-Release(tag)、1.0.1-Release(tag)
Forking 工作流
Forking 工作流是分布式工作流，充分利用了Git在分支和克隆上的优势。可以安全可靠地管理大团队的开发者（developer），并能接受不信任贡献者（contributor）的提交。
Forking 工作流与其它工作流截然不同。与其使用唯一的服务端仓库作为「中央」代码库，它给予每个开发者一个服务端仓库。也就是说每个贡献者都有两个 Git 仓库，而不是一个，一个私有的本地仓库和一个公开的服务端仓库。
Forking 工作流的主要优点在于贡献可以轻易地整合进项目，而不需要每个人都推送到单一的中央仓库。开发者推送到他们自己的服务端仓库，只有项目管理者可以推送到官方仓库。这使得管理者可以接受任何开发者的提交，却不需要给他们中央仓库的权限。
结论是，这种分布式的工作流为大型、组织性强的团队（包括不可信的第三方）提供了安全的协作方式。它同时也是开源项目理想的工作流。namespace 不同了，权限都在自己手里，成为 Fork 项目的 Maintainer。
工作流程
不管使用什么代码管理工具，什么工作流程，在提交之前都应该书写清晰明了的 commit message 减少沟通成本，提高工作效率。
