Git使用规范示例

一、 Git工具推荐

推荐使用Git Extension

二、分支管理策略

分支	Master	Developer	Feature	Fixbug	Release
名称	主分支	开发分支	功能分支	修补bug分支	预发布分支
图示
分支作用	代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。	这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）	功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。	修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。 修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支	预计发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的 版本进行内部测试。 预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。
前缀	master	develop	feature-*	fixbug-*	release-*

三、 Git 使用规范

a.     每次开发新功能都要创建一个新的功能分支

b.    每次要使用Rebase进行代码合并

c.     一次不要提交过多的文件，要根据代码修改的目的拆分成多次提交（方便跟踪和代码检查）

d.  对于新人或经验不够的人要采用Pull request的方式，然后其他人负责合并pull request.

e.  代码合并时，要认真的去看冲突的地方，看懂别人的代码在做什么，然后再决定再怎么合并，如果看不懂就把另外一个人找过来沟通请教一下再决定怎么合并。

f.  Git 每次提交代码，都要写 Commit message（提交说明），目前建议采用angular，这是目前使用最广的写法，比较合理和系统化，并且有配套的工具

四、 辅助工具

a.    husky

用于阻止坏的git commit， git push等

{

  "scripts": {

      "precommit": "npm run lint-staged",

      "prepush": "npm run lint:ci",

      "...": "..."

    },

     lint-staged": {

        "src/**/*.js": "eslint"

    }

}

b.    检查 Commit message 是否符合格式

validate-commit-msg

用于检查 Node 项目的 Commit message 是否符合格式。

它的安装是手动的。首先，拷贝下面这个JS文件，放入你的代码库。文件名可以取为validate-commit-msg.js。

接着，把这个脚本加入 Git 的 hook。下面是在package.json里面使用 ghooks，把这个脚本加为commit-msg时运行。

  "config": {

    "ghooks": {

      "commit-msg": "./validate-commit-msg.js"

    }

c.    生成 Change log

如果你的所有 Commit 都符合 Angular 格式，那么发布新版本时， Change log 就可以用脚本自动生成

生成的文档包括以下三个部分。

○ New features

○ Bug fixes

○ Breaking changes.

每个部分都会罗列相关的 commit ，并且有指向这些 commit 的链接。当然，生成的文档允许手动修改，所以发布前，你还可以添加其他内容。

conventional-changelog 就是生成 Change log 的工具，运行下面的命令即可。

$ npm install -g conventional-changelog

$ cd my-project

$ conventional-changelog -p angular -i CHANGELOG.md -w

上面命令不会覆盖以前的 Change log，只会在CHANGELOG.md的头部加上自从上次发布以来的变动。

如果你想生成所有发布的 Change log，要改为运行下面的命令。