【无标题】

Git 使用的实践与规范
更多内容请看《团队中的 Git 实践》。
Git 是现在很常用并且很好的代码版本管理工具。
基本概念
罗列一下 Git 日常使用的一些命令，以及简述 Git flow 是个什么东西。
常用命令
Git 中的命令有很多，但工作中常用的无外乎那么几种：
git fetch——从远程仓库获取代码更新；
git pull——从远程仓库拉取最新代码到本地仓库；
git status——查看本地文件状态；
git add——将本地文件的修改添加到「提交列表」；
git commit——将「提交列表」中的文件提交到本地仓库；
git stash——将未提交的已修改文件添加到暂存区；
git rebase——更改提交所基于的节点；
git merge——合并其他分支的代码到当前分支；
git push——将提交到本地仓库的改变推送到远程仓库。
从远程仓库新拉取代码时：
git remote——设置远程仓库源；
git clone——从远程仓库克隆代码到本地。
对分支进行操作时：
git checkout——切换分支或节点；
git branch——新建或删除分支。
代码出现问题时：
git reset——将当前代码重置到指定提交节点；
git revert——把当前代码恢复到指定提交节点并产生新的提交节点。
上述代码的具体含义和使用方式请看官方文档或廖雪峰所写的《Git教程》。
Git Flow
这是一个很成熟的分支管理模型，它能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。
需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。
简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：
master——最为稳定功能最为完整的随时可发布的代码；
hotfix——修复线上代码的 bug；
develop——永远是功能最新最全的分支；
feature——某个功能点正在开发阶段；
release——发布定期要上线的功能。
看到上面的「master」和「develop」加粗了吧？代表它们是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：

更多信息可参考 xirong 所整理的《Git工作流指南》。
团队协作
如果一个团队在使用 Git 时没有一些规范，那么将是一场难以醒来的噩梦！
代码提交
如何去写一个提交信息，《Git: 教你如何在Commit时有话可说》中做了很好的说明。在具体开发工作中主要需要遵守的原则就是「使每次提交都有质量」，只要坚持做到以下几点就 OK 了：
提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；
不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。
假如已经把代码提交了，对这次提交的内容进行检查时发现里面有个变量单词拼错了或者其他失误，只要还没有推送到远程，就有一个不被他人发觉你的疏忽的补救方法：
1、把失误修正之后提交，可以用与上次提交同样的信息；

2、终端中执行命令 git rebase -i [SHA]，其中 SHA 是上一次提交之前的那次提交的，在这里是 3b22372；

3、这样就将两次提交的节点合并成一个，甚至能够修改提交信息！

谁说历史不可篡改了？前提是，想要合并的那几次提交还没有推送到远程！
代码推送
建议当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。
代码拉取
请读张文钿所写的《使用 git rebase 避免無謂的 merge》。
代码合并
在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，就不要采用 git rebase 了，避免出现重复的冲突和提交节点。
分支管理
工具选择
我一直不喜欢「＊＊最好用」这种命题，主观性太强，不会有一个结论。所以，原则上只要不影响到团队，用什么工具都是可以接受的。
但根据情况来看，建议使用图形化工具，例如 SourceTree。如果想用命令行，可以啊！先在心里问下自己：「我 Git 牛逼不？会不会惹麻烦给别人？」
在团队中应用 Git Flow 时，推荐使用 SourceTree + GitLab 的形式：
用 SourceTree 创建 feature 等分支以及本地的分支合并、删除；
用 GitLab 做代码审核和远程的分支合并、删除。
SourceTree 和 GitLab 应该是相辅相成的存在，而不是互相取代。
工具配置
在使用 SourceTree 时，进行配置之后可以将一些规范性的东西自动化处理。
按下 command + , 调出「Preferences」界面并切换到「Git」标签：
勾选「Use rebase instead of merge by default for tracked branches」，这样在点「Pull」按钮拉取代码时会自动执行 git pull --rebase；
勾选「Do not fast-forward when merging, always create commit」以在每次合并时创建新的提交节点。

点「Pull」按钮后出现的界面应该是这样——

操作流程
首先，一定要把主要分支，也就是 master 和 develop 给保护起来。通过 GitLab 为那两个分支设置权限，除了各项目的负责人外不允许进行推送和删除等操作。
开发功能
在确定发布日期之后，将需要完成的内容细分一下分配出去，负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话，创建分支并做一些初始化工作之后就推送创建远程分支；否则，直到功能开发完毕要合并进 develop 前，不要创建远程分支。
功能开发并自测之后，先切换到 develop 分支将最新的代码拉取下来；再切换回自己负责的 feature 分支把 develop 分支的代码合并进来，合并方式参照上文中的「代码合并」；如果有冲突则自己和配合的人一起解决；最后，到 GitLab 上创建合并请求（merge request）给项目负责人。
项目负责人在收到合并请求时，应该先做下代码审核看看有没有明显的严重的错误；有问题就找开发人员去修改，没有就接受请求并删除对应的 feature 分支。
测试功能
在将某次发布的所需功能全部开发完成时，负责测试的人创建一个 release 分支部署到测试环境进行测试；若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。
发布功能
当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。
建议打 tag 时在信息中详细描述这次发布的内容，如：添加了哪些功能，修复了什么问题。
问题修复
当发现线上环境的代码有小问题或者做些文案修改时，相关开发人员就在本地创建 hotfix 分支进行修改，具体操作参考「开发功能」。
如果是相当严重的问题，可能就得回滚到上一个 tag 的版本了。
命名规则
除了主要分支的名字是固定的之外，派生分支是需要自己命名的，这里就需要有个命名规范了。强烈推荐用如下形式：
feature 分支：按照功能点（而不是需求）命名；
release 分支：用发布时间命名，可以加上适当的前缀；
hotfix 分支：issue 编号或 bug 性质等。
另外还有 tag，用语义化的版本号命名。