在团队协作中，好好地应用 Git可以为团队开发带来更高的效率收益， 也能保证整个工作流的完整推进。本文通过参考多篇优秀的Git实践文章总结而成，旨在为使用GIT标准分支开发流程的开发团队新人提供一份参考指南
一、一些好的习惯
1.1 提交
- 提交时的
粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低； - 不要每提交一次就推送一次
- 用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方
1.2 推送
- 当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。
1.3 合并
- 在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用git rebase来代替git merge；反过来或者不是父子关系的两个分支以及互相已经git merge过的分支，就不要采用git rebase了，避免出现重复的冲突和提交节点。
二、常用操作命令简介
常用命令如下：
# 提交
git commit
# 添加跟踪
git add [--all]
# 推送
git push
# 拉取
git pull
# 分支操作
git branch [-d]
# 合并
git merge
# ”挑拣”提交
git cherry-pick
# 检出分支
git checkout [-b] BRANCH_NAME
# 暂存
git stash
- 更多命令参考： Git常用命令详解
三、分支管理
说到分支管理，就需要知道
Git Flow分支模型，它定义了Git分支的一个规范，参照这个模型，可以应用于大部分工程场景
Git Flow 分支模型：能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。
- 注意：它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。
-
简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：
-
项目中长期存在的两个分支(
主要分支)：master：主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。develop：开发分支，该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建。
-
其它分支为短期分支，其完成功能开发之后需要删除（
派生分支）：feature/*：特性（功能）分支，用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。bugfix/*：bug修复分支，用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。release/*：发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。hotfix/*：紧急bug修复分支，该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分
-
主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个
3.1 工具
好的工具可以方便开发操作，这里推荐SourceTree，它有一个创建Git Flow工具流选项，可以快速在工程中创建对应分支并管理。当然，也可以走命令行路线来创建Git Flow，参考文章： 研发团队GIT开发流程
下载地址： 注意安装过程可能需要科学上网
3.2 工具与实践
按下
command ,或ctrl ,调出「Preferences」界面并切换到「Git」标签，勾选「Use rebase instead of merge by default for tracked branches」([对提交分支默认使用变基代替合并])和「Do not fast-forward when merging, always create commit」（【合并时不要使用快进方式，总是创建提交】）
- 这样设置之后，在点「Pull」按钮拉取代码时会自动执行git pull --rebase；并且，每次合并时会自动创建新的包含分支信息的提交节点。
- 接下来，点击工具栏中的「Git Flow」按钮将相关的流程自动化。如果没有特殊需求，直接按下对话框中的「确定」。初始化完成后会自动切换到 develop 分支。
分支权限设置: 对于master 和 develop 分支，需要进行保护，只有项目负责人有权推送和删除。
3.3 开发功能
-
在确定发布日期之后，将需要完成的内容细分一下分配出去，负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话，创建分支并做一些初始化工作之后就推送创建远程分支；否则，直到功能开发完毕要合并进 develop 前，不要创建远程分支。
-
功能开发完并自测之后，先切换到 develop 分支将最新的代码拉取下来，再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」，如果有冲突则自己和配合的人一起解决。
-
然后，到 GitLab 上的项目首页创建合并请求（merge request）。
-
「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮，在出现的表单中将处理人指派为项目负责人。
-
项目负责人在收到合并请求时，应该先做下代码审核(Code Review)看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。
3.4 测试功能
负责测试的人创建一个 release 分支部署到测试环境进行测试；若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。
3.5 发布上线
当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。
建议打 tag 时在信息中详细描述这次发布的内容，如：添加了哪些功能，修复了什么问题。
3.6 修复问题
当发现线上环境的代码有小问题或者做些文案修改时，相关开发人员就在本地创建 hotfix 分支进行修改，具体操作参考「开发功能」。
如果是相当严重的问题，可能就得回滚到上一个 tag 的版本了。
补充
关于分支的命名：除了主要分支的名字是固定的之外，派生分支是需要自己命名的，这里就要有个命名规范了。强烈推荐用如下形式：
•feature——按照功能点（而不是需求）命名；
•release——用发布时间命名，可以加上适当的前缀；
•hotfix——GitLab 的 issue 编号或 bug 性质等。
参考文章: 团队开发中的Git实践，研发团队Git开发流程
