git规范

发表于

分支

分支分类

  • master: 存储了正式发布的历史,为主分支(保护分支)，不能直接在 master 上进行修改代码和提交;
  • develop:作为功能的集成分支,开发完成需要提交测试的功能合并到该分支;
  • feature: 大家根据不同需求创建独立的功能分支，开发完成后合并到 develop 分支；
  • release: 发布分支，主要用于测试或修复 bug。
  • fix: 为 bug 修复分支，需要根据实际情况对已发布的版本进行漏洞修复，必须从 master 拉取；

branch

分支命名

功能分支： featrue/功能名称
发布分支：release/版本号-功能名称-发布日期
维护分支：fix/版本号-问题概述或 issueid-日期 (最好使用 issue 建立问题描述?)

分支管理策略

develop 为集成开发分支

自己分支自测完毕； review 通过再合并；

本地分支管理

  • 本地分支要做到勤提交，分小功能提交；
  • 本地分支 merge 到 develop 分支时(rebase ? )，必须先 merge develop 到本地分支，自测通过再提交；

开发者相同版本尽量不要修改相同功能，提前划分或协商清楚；
如果修改代码涉及多人功能，提交完毕请及时告知相关人员；
开发者每天更新 develop 分支内容到本地分支，避免大规模 merge(?);
fixbug 分支修改测试完，立即合并到 develop 上

提交相关

关于提交 git commit message

详细内容格式

1
2
3
4
5
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

使用 git commit -m 'XXX' 时，输入的’XXX’其实是<type>(<scope>): <subject>的部分

type

type 在 commit 的是否必须存在。

  • feat: 添加新特性
  • fix: 修复 bug
  • docs: 仅仅修改了文档
  • style: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
  • refactor: 代码重构，没有加新功能或者修复 bug
  • perf: 优化相关，比如提升性能、体验
  • test: 增加测试用例
  • chore: 改变构建流程、或者增加依赖库、工具等
  • revert: 回滚到上一个版本

scope

scope：【可选】用于说明 commit 的影响范围

subjec

subject：commit 的简要说明，尽量简短

Body

对本次 commit 的详细描述，可分多行

不兼容变动：需要描述相关信息

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
BREAKING CHANGE: 隔离作用域绑定定义已更改。

    要迁移代码，请遵循以下示例：

    Before:

    scope: {
      myAttr: 'attribute',
    }

    After:

    scope: {
      myAttr: '@',
    }

   删除的“inject”一般对指令没有用处，因此不应该有代码使用它。

关闭 Issue

  • 关联 Issue（Issue #1, #2, #3）
  • 关闭 Issue（Close #1, #2, #3）
1
Closes #234

可用 github 关闭 issue，或者与自己的任务相关联

Commitizen 使用方法

全局安装

1
npm install -g commitizen

然后，在项目目录里，运行下面的命令，使其支持 Angular 的 Commit message 格式。

1
$ commitizen init cz-conventional-changelog --save --save-exact

以后，凡是用到git commit命令，一律改为使用git cz。这时，就会出现选项，用来生成符合格式的 Commit message。

规范提交信息

cz-conventional-changelog

1
npm install cz-conventional-changelog -D

生成 change log

conventional-changelog-cli 通过提交记录生成 CHANGELOG.md

https://github.com/conventional-changelog-archived-repos/conventional-changelog-cli

安装

1
npm install -g conventional-changelog-cli

生成 change log

1
conventional-changelog -p angular -i CHANGELOG.md -s

通过以上命令你就会发现在项目中多了个CHANGELOG.md文件，表示生成 Change log 成功了。

生成的文档包括以下部分

  • New features
  • Bug fixes
  • Breaking changes.

查看分支图

1
git log --graph --oneline --decorate

提交关键词搜索

1
git log --grep keywords

合并代码

git merge

将一个分支合并到当前分支

1
git merge dev

git pull = git fetch + git merge

1
2
3
4
5
6
7
> git fetch orgin master //将远程仓库的master分支下载到本地当前branch中
>
> git log -p master  ..origin/master //比较本地的master分支和origin/master分支的差别
>
> git merge origin/master //进行合并
>
>

merge

git rebase

变基，改变当前分支的基点

1
git rebase dev

git pull —rebase = git fetch + git rebase

在 mywork 分支上 rebase，将基点从 C2 改为 C4，在 C4 后添加 C5’ C6’（即：C5 C6 的拷贝节点，与 C5 C6 不是一个节点但内容保留）

rebase0

移除 C5 C6 节点

rebase1

追后结果

rebase2

综上 rebase 是对一个分支做“变基”操作，这意味着改变这个分支的 base commit。它会在新的 base 上一个一个地运行这个分支上的所有 commits.

rebase 冲突

  • rebase 过程中也会出现冲突 解决冲突后，使用 git add .添加，然后执⾏ git rebase --continue。接下来 Git 会继续应⽤用余下的补丁。
  • 任何时候都可以通过如下命令终⽌止 rebase，分⽀支会恢复到 rebase 开始前的状态 git rebase --abort

注意：

不要 rebase 一个已经在远程库中已经存在的分支，只能 rebase 你自己使用的私有分支。

git-rebase-error

rebase 远程分支在提交将导致历史混乱，并且 merge 后存在多个完全相同修改记录

其他操作

合并多个 commit 为一个完整 commit

rebase

1
git rebase -i  [startpoint]  [endpoint]

-i的意思是--interactive，即弹出交互式的界面让用户编辑完成合并操作.

[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit。

pick：保留该 commit（缩写:p）
reword：保留该 commit，但我需要修改该 commit 的注释（缩写:r）
edit：保留该 commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
squash：将该 commit 和前一个 commit 合并（缩写:s）
fixup：将该 commit 和前一个 commit 合并，但我不要保留该提交的注释信息（缩写:f）
exec：执行 shell 命令（缩写:x）
drop：我要丢弃该 commit（缩写:d）

将某一段 commit 粘贴到另一个分支上

rebase

将 develop 分支中的 C~E 部分复制到 master 分支中，这时我们就可以通过 rebase 命令（如果只是复制某一两个提交到其他分支，建议使用更简单的命令:git cherry-pick）

1
git rebase   [startpoint]   [endpoint]  --onto  [branchName]

[startpoint] [endpoint]仍然和上一个命令一样指定了一个编辑区间(前开后闭)，--onto的意思是要将该指定的提交复制到哪个分支上。

rebase

此时 HEAD 所指向的内容正是我们所需要的，但是 master 分支是没有任何变化的，git只是将 C~E 部分的提交内容复制一份粘贴到了 master 所指向的提交后面，我们需要做的就是将 master 所指向的提交 id 设置为当前 HEAD 所指向的提交 id 就可以了

1
2
git checkout master
git reset --hard  0c72e64

git 打 tag

tag 对应某次 commit, 是一个点，是不可移动的。

branch 对应一系列 commit，是很多点连成的一根线，有一个 HEAD 指针，是可以依靠 HEAD 指针移动的。
所以，两者的区别决定了使用方式，改动代码用 branch ,不改动只查看用 tag。

1
2
3
4
5
6
7
git tag <tagName> // 创建本地tag

git push origin <tagName> // 推送到远程仓库

git tag -d <tagName> // 本地 tag 的删除

git push origin :<tagName> // 远程 tag 的删除：

git alias

查看已有别名

1
git config --global --list

编辑别名

1
git config --global --edit

🌰：

1
2
3
4
5
6
[alias]
        st = status
        ci = commit
        pl = pull
        ps = push
....