GitFlow + Gitlab 工作流及规范
一、 git 命令及配置
1.Git ssh 与 gitLab配置
cd ~/.ssh 检查有没有创建
进行创建ssh命令执行：ssh-keygen -t rsa -C '[email protected]'
查看你生成的密钥 cat ~/.ssh/id_rsa.pub
登录你的gitlab/github/码云等把公钥复制过去
验证下配置的Key 是不是可以正常工作；ssh -T [email protected]
2.Git 命令查询
2.1 创建版本库
git clone
git init #初始化本地版本库
2.2 修改和提交
git status # 查看状态
git diff # 查看变更内容
git add . #跟踪所有改动过的文件
git add
git mv
git rm
git rm --cached
git comit -m 'commit message' #提交所有更新过的文件
git commit --amend #修改最后一次提交
2.3 查看提交历史
git log #查看提交历史
git log -p
git blame
2.4 撤消
git reset --hard HEAD #撤消工作目录中所有未提交文件的修改内容
git checkout HEAD
git revert
2.5 分支与标签
git branch #显示所有本地分支
git checkout
git branch
git branch -d #删除本地分支
git tag #列出本地所有标签
git tag
git tag -d
2.6 合并与衍合
git merge
git rebase
2.7 远程操作
git remote -v #查看远程版本库信息
git remote show
git remote add
git fetch
git pull
git push
git push
git push --tags #上传所有标签
2.8 实现创建分支过程操作
git checkout master #切换到master分支
git checkout -b dev #从当前分支copy dev开发分支
git push origin dev #把新建的分支push到远端
git pull #拉取远端分支
git branch --set-upstream-to=origin/dev #关联
git pull #拉取 验证
二、 gitlab 规范
2.1 基本要求
所有commit必须有注释，内容必须按照注释格式严格执行
合理控制提交内容的颗粒度完成一个功能进行一次commit提交，严禁一次提交涵盖多个功能
正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。 查看当前项目配置信息的命令：git config -l
2.2 版本号
版本号(tag)命名规则：主版本号.次版本号.修订号，如1.1.10 （参考GitHub 语义化命名规范）
版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
对master标记tag意味着该tag能发布到生产环境
对master分支代码的每一次更新(合并)必须标记版本号
仅项目管理员有权限对master进行合并和标记版本号
2.3 gitlab 项目权限介绍
浏览者(Guest)只能浏览代码，无push、pull request等所有写权限
开发者(Developer)拥有浏览、push非主分支、提交pull request工单权限
管理员(Master)拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限######2.3.1 分支使用
每个Git项目固定含有上述所有分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。
功能需求或常规Bug修复，请从develop拉取feature分支；线上紧急问题修复，请从master拉取hotfix分支。
2.3.2 代码提交
一个提交就代表解决一个问题
大问题适当地分解为多个小问题，以便每次小型提交都更易于理解
2.3.2 代码合并
将开发完毕的分支，拉取develop最新代码，merge并解决冲突后，之后在对应的feature分支创建并提交到develop分支，并自动触发merge request请求，然后进行code review，确认无误后再合并。注意：1.每个merge request不要包含不相关的功能 2.merge request提交后需要及时跟踪动态，包括通过、打回等 3.该功能进入提测流程后，需删除之前的功能分支
三、 gitflow工作流
工作流中涉及到的角色介绍：
功能开发者：模块中功能的开发人员；
开发管理员：由项目模块开发的小组长（team leader）担当；
测试管理员：由测试团队指定人员担当；
发布管理员：由生产环境发布团队指定人员担当；
分支说明
名称说明命名规范命名示例合并目标合并操作
master(主分支)线上稳定版本mastermaster----
release待发布分支，下个版本需上线的版本release/xxxrelease/v1.0.0mastermerge request
develop（开发主分支）当前正在开发的分支developdevelopmastermerge request
feature功能分支，每个功能需分别建立自己的子分支feature/版本号-功能名feature/v1.0.0-Logindevelopmerge request
hotfix紧急修复分支hotfix/xxxhotfix/v1.0.1master/developmerge request
分支约定
Git Flow有主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各种开发活动。
master 分支
master分支存放的是随时可供在生产环境中部署的稳定版本代码
master分支保存官方发布版本历史，release tag标识不同的发布版本
一个项目只能有一个master分支
仅在发布新的可供部署的代码时才更新master分支上的代码
每次更新master，都需对master添加指定格式的tag，用于发布或回滚
master分支是保护分支，不可直接push到远程仓master分支
master分支代码只能被release分支或hotfix分支合并
develop 分支
develop分支是保存当前最新开发成果的分支
一个项目只能有一个develop分支
develop分支衍生出各个feature分支
develop分支是保护分支，不可直接push到远程仓库develop分支
develop分支不能与master分支直接交互
每次将develop分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。基于此，理论上说，每当有代码提交到master分支时，我们可以使用Git Hook触发软件自动测试以及生产环境代码的自动更新工作。这些自动化操作将有利于减少新代码发布之后的一些事务性工作。
辅助分支
git_assist.png
辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。跟“历史性”分支相反，这三类分支都是短期分支，针对他们的工作内容完成后，一般都要进行删除。
工作内容完成的标识有两个：开发完成、合并完成，缺一不可。
辅助分支包括：
用于开发新功能时所使用的feature分支
用于辅助版本发布的release分支
用于修正生产代码中的缺陷的hotfix分支
以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。
feature 分支
使用规范：
分支的命名格式必须是版本号-功能名，例如v1.0.0-login
develop分支的功能分支
feature分支使用develop分支作为它们的父类分支
以功能为单位从develop拉一个feature分支
每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
当其中一个feature分支完成后，它会合并回develop分支
当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支
feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
由每组开发管理员负责把所有feature分支开发完成的代码合并到develop分支
feature分支只与develop分支交互，不能与master分支直接交互
如有几个同事同时开发，需要分割成几个小功能，每个人都需要从develop中拉出一个feature分支，但是每个feature颗粒要尽量小，因为它需要我们能尽早merge回develop分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支。
release 分支
使用规范：
命名规则：release/*，“*”以本次发布的版本号为标识
release分支主要用来为发布新版的测试、修复做准备
当需要为发布新版做准备时，从develop衍生出一个release分支
release分支可以从develop分支上指定commit派生出
release分支测试通过后，合并到master分支并且给master标记一个版本号
release分支一旦建立就将独立，不可再从其他分支pull代码
必须合并回develop分支和master分支
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
hotfix 分支
使用规范：
命名规则：hotfix/*，“*”以本次发布的版本号为标识
hotfix分支用来快速给已发布产品修复bug或微调功能
只能从master分支指定tag版本衍生出来
一旦完成修复bug，必须合并回master分支和develop分支
master被合并后，应该被标记一个新的版本号
hotfix分支一旦建立就将独立，不可再从其他分支pull代码
除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
新功能开发流程
从 develop 分支创建 feature 分支；
开发调试完将 feature 分支提交到远程版本库；
提交 pull request 请求合并到 develop 分支；
相关负责人 code review 后如果同意合并后，删除远程 feature 分支，如果不同意，重新修改后再上传 feature 分支请求 pull request。
Pull Request
Pull Request是当功能开发者完成一个新功能后向项目维护者发送合并请求通知的机制。它的使用过程如下：
功能开发者可以通过Gitlab页面发送pull request
开发管理员自己或组织其他的团队成员审查、讨论和修改代码
开发管理员合并新增功能分支到develop分支，然后关闭pull request，并且可以选择删除新增分支
工作流程
1.由开发管理员负责在Gitlab上创建空白的仓库，并clone到本地，在sourcetree的git flow菜单中选择初始化仓库，并push到远端。
2.在Gitlab上设置保护分支，把master、develop分支保护起来，只有指定人可push。
3.功能开发者clone代码到本地，先在sourcetree的git flow菜单中选择初始化仓库。
4.然后再开始新建功能分支，进行开发工作。
5.新功能开发全部完成或部分完成后，功能开发者把最新代码push到远端同样的新功能分支里，并在Gitflow发起pull request给开发管理员
6.开发管理员review代码，选择合并代码到develop，并可选择删除已经合并的新功能分支
7.当开发管理员处理完合并请求后，开发者,切换到develop分支，直接删除自己的本地分支及远程分支，不要点击完成(Finish Feature)，此时开发者pull远端develop分支最新代码即可，可忽视本地的push提醒。
8.release、hotfix分支和feature分支操作类似。
9.不可点击完成新功能、完成发布版本、完成修复补丁，因为这样会导致自动合并代码到master或develop分支