目录
本文会分为两部分讲解，第一部分介绍Git的基础概念、常见客户端、常用命令，是一个基础说明。第二部分介绍Git的管理流程，主要是GitFlow，Github Flow、Gitlab Flow和ExeFlow四种。
Git是一个基于GNU协议的开源分布式版本控制系统，是由Linux的创始人Linus Torvalds在2005为了进行Linux内核的研发时自己编写的。不同于之前的大部分客户端-服务器模式的代码管理系统，在每台电脑上的每个Git目录都是一个完整的代码仓库，包含了历史所有的提交记录并且可以完整查看所有版本，而不需要有服务器或者网络连接。
2019年9月Git的当前的最新版本为2.23.0.
TortoiseGit，就是我们俗称小乌龟。他们为Svn也提供了很优秀的windows客户端。而且这是一个开源的软件，当前最新的版本位2.8.0 。
安装之后会自动注入系统的右键菜单，在任何路径右击之后都会出现
如图的选项，这是在非git仓库时。当在git仓库右键点击时完整菜单如下
查看提交记录
Sourcetree是Atlassian提供的一款免费的Git客户端工具，目前的版本是3.2.6。
安装之后直接打开客户端使用，整体界面大致如图。
Idea是Java开发非常热门的IDE，其中也集成了多种SCM工具，自然也包括Git的客户端，整体的使用感受还是不错的。
最后名不符实的再加上一个命令行吧，有很多同学还是习惯手敲命令的。
Git主要有四块存储区域：
还有另外一个版本的流程：
add & commit 实际上就是一个文件加入版本控制的过程，在受git管理的目录下新建一个文件，首先要将它标记为add，接下来commit到本地的仓库，就完成了本地的版本管理。
之后可以选择是否执行push操作，如果执行就是将本地的变更提交到远程服务器上，这样别人就可以获取到你的更新了。
branch是常见的创建分支应用的语法，git和传统的cs模式的SCM的工具相比branch的代价是非常小的，影响也是非常小的。git的branch可以只存在与本地，轻易和合并与删除。
上图就是很多Flow流程中可能存在的多个分支（实际上这些分支本地和远程都是存在的）。
我们本地的一个项目可能就会存在多个分支，我们使用checkout命令，签出一个分支之后，环境中的文件都会变为该分支的相关文件。
pick是挑选的意思，我们看一下示意图
这是要求将 bugFix 分支上的 C3 、side 分支上的 C4 以及another分支上的C7通过cherry-pick的形式拿到 master分支上。这是很典型的一个使用cherry-pick的场景，bug修复的合并。
通过上面的branch和push，我们已经切出不同的分支并且提交了，接下来就是要合并我们的提交内容到主分支上，这时我们可能会面临两个命令选择 merge和rebase。
这两个命令有什么区别呢？我们通过一个模拟界面来看一下：
使用merge命令
使用rebase命令
建议：
rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
merge 会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交。
为什么建议使用rebase，因为通常我们是feature分支基于master分支进行rebase，master是长期固定分支，feature是临时分支，我们不希望因为临时分支的变更影响到master分支的提交记录，而且通常情况下master分支是锁定不允许直接提交的。所以建议大家使用rebase，这样能够在不影响master分支的情况下还能够合并最新的内容。
我们这里主要讲四种flow进行对比，GitFlow，GitHub Flow，GitLab Flow，ExeFlow。
我对于项目管理的核心理解有两点：
GitFlow来源应该是 Vincent Driessen 在2010年1月发表的这篇《A successful Git branching model》，基本是现在Git中最出名的流程管理方法了。
我整理了其对应的流程图，其中加粗的是指长期分支。可以看到master和develop是其中的长期分支，对外的发布基于master分支，对内的研发基于develop分支。需要发布版本时，是从develop分支切出release分支，最终合并至master。所以我理解在GitFlow中，最重要的实际上是develop分支，它承载了实际功能的开发修正和发布，而master最大的作用有两个，一是发布，二是热修正（hotfix）。
GitFlow的流程我理解时偏重时间，而非需求的。也就是说如果临近发布时间，而需求没有完成，其唯一的选择就是延期，因为按照流程，release分支是从develop分支切出，如果测试的环境是基于develop，很可能是没有打到发布标准的，所以只能等打到发布标准后才能进行后续步骤。但是好处在于开发只用基于develop分支，很难出现漏合并代码或者bug修正之类的情况。我也觉得这份流程在大型企业内部是比较难推进的，因为它的环境管理还不够，它的release、master分别对应预发布和正式环境，develop我觉得还不够清晰，因为这块我们通常是需要两个环境，开发和测试环境。所以对于多环境管理我觉得是需要根据不同的企业的要求进行改造的。
顾名思义，GitHub Flow就是GitHub推荐的管理流程
可以看到，只能用简单2字形容，只有master和feature两个分支概念，其中master是长期分支。所以我还加上了Github官方的一些说明。
我觉得这不是一份可以用于企业级复杂项目管控的Git 流程，最基础的就是没有多环境管理，无法想象多角色配合时只基于master分支如何进行。master究竟用于测试环境还是随时可发布的正式环境呢？其次这份流程应该也是偏重于需求而非时间。理由和GitFlow一样。
我觉得GitHub推出的这份flow主要是应用于其平台上大部分托管的小型开源项目，并且尽量结合平台提供的其他组件。对于企业内部不够合适。
GitLab Flow自然是基于GitLab环境的flow管理流程
这个Flow实际上最核心的分支是基于master，生产环境是production，预发布环境是pre-production。我觉得对于多环境的问题实际上和GitFlow很相似，也是开发和测试环境不够清晰。
提交、审核基于GitLab的MR进行。截图的部分就是GitLab官方的MR的说明。
GitLab Flow与GitFlow的差别我觉得仅仅在于master与develop的分支命名，还有就是加入了MR（但是由于GitFlow不基于任何服务端环境，所以这块是可以整合的），问题也很相似。
由于上面几种Flow在时间和需求都是选择了需求而延迟了时间，我也顺便讲一下选择时间而放弃一些需求的Flow流程吧。
这是我之前一家公司的流程设计，服务端是GitLab。
实际工作场景：
我们的系统由于主要是面向大型企业内部使用，存在复杂的分发流程和权限控制，经过长时间的累积业务模型也很复杂各种关联和引用，所以有一些大型任务的开发周期可能会比较长，到达2-3个月的周期。
我们的迭代周期正常是1个月。流程大概如下：
流程图：
这里有几个特点：
先来说说有点，根据之前提供的流程来看，我们企业要求的是时间保障而需求可以调整。所以在指定时间节点到来时，我们会确定一份可以发布的需求清单，根据这份清单来合并至release，从而最终能够发布。这是一个比较典型的保时间点，放需求的流程管理。
但是这个会有下面几个问题：
但是由于这个流程解决了我们实际生产流程中的问题，所以整体在控制和配合上带来的收益远大于我们的障碍。所以这套流程还是长期推广了起来。
Git是一个工具，Flow是一套管理流程。最重要的并不是我们在用什么，而是我们解决了什么问题？我们试图解决的问题到底是不是真实的问题，还是我们一厢情愿臆想出来的。整个过程，实际上是我们针对企业的环境和问题进行发掘的解决的过程，而不是单纯挑选工具和流程的过程。
记得先问自己，我现在到底要解决的是什么问题？
原文：https://www.cnblogs.com/pluto4596/p/11634314.html