GIT代码管理规范

2017/05/16

Git简介

git是一种较为先进的代码版本管理及协同工作平台，采用分布式文件块存储：

分布式：代码保存在所有协同成员的计算机上，网速较差时依然可用；而传统的集中式代码版本管理系统则较难脱离网络运行。
文件块：直接以文件块保存整个最新文档，版本提交及恢复速度快：而传统的增量式代码版本管理系统则在每次提交及恢复时都需要对所有的增量进行求和，速度慢。

git常用概念：

仓库（Repositories）：类似我们生活中的仓库，存储东西，在这是网络或者本地实际存放代码的地方，同一个仓库可存多个项目。
参照（References）：可以看做是指向文件块中特定代码版本的指针，可沿代码版本有向图进行向前（一般指提交操作Commit）,向后（一般是恢复操作Restore）, 跳转（不同分支间的切换Switch）。
分支（Branch）：一般是为了进行代码调试或概念开发，从主要的开发版本中分离出一个副版本，并在此基础上进行修改，（实际中我们可以分离出来进行各自的模块开发）使版本有向图呈现分支状态。
合并(Merge)：一般是为了将代码调试或概念开发分支的代码加入到主要版本中，将对两部分的代码进行比较：

a) 先向后回朔两个分支的最近公共节点，通过与最近的公共节点进行比较，分析两个分支各对哪些文件进行了修改（因为是文件块，所以需要对两个版本的文件求差，传统模式则需要对两个版本的记录进行求和）

b) 合并最容易产生的错误（冲突）如果某一个文件在两个版本中均被修改过，则视为“冲突”，这时我们解决的办法是需要人工手动调整其中一个版本，这里推荐使用一个工具（BCompare）可以快速明了的看出修改的地方；否则，即自动将两个版本分别修改后的部分，未修改的部分合并成一个新的版本。
标签（Tag）：不移动的参照（指针），以标记特殊的代码版本副本，比如说项目的里程碑等

Git使用流程

此处输入图片的描述

1. 新建分支

首先，每次开发新功能，都应该新建一个单独的分支

# 获取主干最新代码
$ git checkout master
$ git pull

# 新建一个开发分支myfeature
$ git checkout -b myfeature

2. 提交分支commit

分支修改后，就可以提交commit了。

$ git add --all
$ git status
$ git commit --verbose

git add 命令的all参数，表示保存所有变化（包括新建、修改和删除）。从Git 2.0开始，all是 git add 的默认参数，所以也可以用 git add . 代替。
git status 命令，用来查看发生变动的文件。
git commit 命令的verbose参数，会列出 diff 的结果。

3. 撰写提交信息

提交commit时，必须给出完整扼要的提交信息，下面是一个范本

Present-tense summary under 50 characters //不超过50个字的提要

* More information about commit (under 72 characters).//罗列出改动原因、主要变动、以及需要注意的问题
* More information about commit (under 72 characters).

http://project.management-system.com/ticket/123 //最后，提供对应的网址（比如Bug ticket）

4. 与主干同步

分支的开发过程中，要经常与主干保持同步。

$ git fetch origin
$ git rebase origin/master

5. 合并commit

分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。
那么，怎样才能将多个commit合并呢？这就要用到 git rebase 命令。

$ git rebase -i origin/master

关于合并commit细节可自行谷歌

6. 推送到远程仓库】

合并commit后，就可以推送当前分支到远程仓库了

$ git push origin myfeature
$ git push --force origin myfeature  //rebase以后，分支历史改变了，跟远程分支不一定兼容，有可能要强行推送

7. 发出Pull Request

提交到远程仓库以后，就可以发出 Pull Request 到master分支，然后请求别人进行代码review，确认可以合并到master。

Git分支规范

Git分支示意图

项目中长期存在的两个分支

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分支。

命名规范

功能分支的分支名称应该为能够准确描述该功能的英文简要表述
feature/分支名称
例如，开发的功能为新增商品到物料库，则可以创建名称为 feature/material-add的分支。
bug修复分支、紧急bug修复分支

bugfix/分支名称
hotfix/分支名称

release分支为预发布分支，命名为本次发布的主要功能英文简称

release/分支名称

总结

所有的新功能开发，bug修复（非紧急）都要从develop分支拉取新的分支进行开发，开发完成自测没有问题再合并到develop分支
release分支发布到测试环境，由开发人员创建release分支（需要测试人员提出需求）并发布到测试环境，如果测试过程中发现bug，需要开发人员track到该release分支修复bug，上线前需要测试人员提交merge request到master分支，准备上线，同时需要合并回develop分支。
只有紧急情况下才允许从master上拉取hotfix分支，hotfix分支需要最终同时合并到develop和master分支（共两次merge操作）
除了master和develop分支，其它分支在开发完成后都要删除