落叶无痕
0%

GIT协作指南

发表于 分类于 Changyan：

自动摘要: Git使用规范 团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。 Sec01工作流指南 分支分类 历史分支master:存储了正式发布的历史,为 ……..

Git 使用规范

团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。

Sec01 工作流指南

分支分类

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

流程图解

img

Sec02 命名规范

分支命名

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

示例： release/转投优化-20181111

常见问题

分支管理策略

1. develop为集成开发分支
1
2
3
提交规则： 
自己分支自测完毕；
review通过再合并；
2. 本地分支管理
1
2
3
4
本地分支必须从**线上版本节点**checkout();
本地分支要做到勤提交，分小功能提交；
一个功能点一个分支(自己控制)，至少保证保留两个分支：新版本分支、优化分支；
本地分支merge到develop分支时，必须先merge develop到本地分支，自测通过再提交；
3. 注意事项
1
2
3
4
开发者相同版本尽量不要修改相同功能，提前划分或协商清楚；
如果修改代码涉及多人功能，提交完毕请及时告知相关人员；
开发者每天更新develop分支内容到本地分支，避免大规模merge; 
fixbug分支修改测试完，立即合并到develop上！

分支提交流程

建议使用GitHub Desktop 软件完成以下工作。

第一步：新建分支

首先，每次开发新功能，都应该新建一个单独的分支（详情参考《Git分支管理策略》）。

第二步：提交分支commit

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

第三步：撰写提交信息

提交commit时，必须给出完整扼要的提交信息。（详情参考Sec03）

第一行是不超过50个字的提要，然后空一行，罗列出改动原因、主要变动、以及需要注意的问题。最后，提供对应的网址（比如Bug ticket）。

第四步：与主干同步

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

第五步：合并commit

分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。

那么，怎样才能将多个commit合并呢？这就要用到 git rebase 命令。

1
$ git rebase -i origin/master

git rebase命令的i参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。互动界面，先列出当前分支最新的几个commit（越下面越新）。每个commit前面有一个操作命令，默认是pick，表示该行commit被选中，要进行rebase操作。

详情参考Tute Costa的例子，来解释怎么合并commit。

commit的下面是一大堆注释，列出可以使用的命令。

  • pick：正常选中
  • reword：选中，并且修改提交信息；
  • edit：选中，rebase时会暂停，允许你修改这个commit（参考这里）
  • squash：选中，会将当前commit与上一个commit合并
  • fixup：与squash相同，但不会保存当前commit的提交信息
  • exec：执行其他shell命令

上面这6个命令当中，squash和fixup可以用来合并commit。先把需要合并的commit前面的动词，改成squash（或者s）。

Pony Foo提出另外一种合并commit的简便方法，就是先撤销过去5个commit，然后再建一个新的。这个用法请参考这篇文章，这里就不解释了。

第六步：推送到远程仓库

合并commit后，就可以推送当前分支到远程仓库了。
git push命令要加上force参数，因为rebase以后，分支历史改变了，跟远程分支不一定兼容，有可能要强行推送（参见这里）。

第七步：发出Pull Request

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

Sec03 提交规范

Commit

Commit message一般包括三部分：Header、Body和Footer。

1
2
3
4
5
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
1
<type>(<scope>): <subject>
  • type（类型）：用于说明commit的类别，规定为如下几种
    • feature：新增功能；
    • fix：修复bug；
    • docs：修改文档；
    • refactor：代码重构，未新增任何功能和修复任何bug；
    • build：改变构建流程，新增依赖库、工具等（例如webpack修改）；
    • style：仅仅修改了空格、缩进等，不改变代码逻辑；
    • perf：改善性能和体现的修改；
    • chore：非src和test的修改；
    • test：测试用例的修改；
    • ci：自动化流程配置修改；
    • revert：回滚到上一个版本；
  • scope（范围）：【可选】用于对 commit 提供补充说明，应该为阅读提交日志或者发行版本说明中的提交日志的人有用。例如：修复了”authors blurb”中的某些内容，那么以”authors”作为”scope”是合适的。如果你修改了”landing page”的工作方式，那么使用”landing  page”或者”home”作为”scope”才合适。
  • subject（主题）：commit的简要说明，尽量简短，遵循以下准则
    • 描述做的内容，不描述做的状态。即：“修改README”，而不是“README修改完成”
    • 行尾不需要添加标点符号

Revert Commits

如果想恢复前一个提交，必须使用 revert 类型，后面与被恢复的提交的“Header”相同。提交的主体必须使用正文开始： This reverts commit <hash>.，其中的“hash”是被恢复的提交的 SHA。

Body

对本次commit的详细描述，可分多行。遵循以下规则

  • 描述做的内容，不描述做的状态。即：“修改README”，而不是“README修改完成”
  • 与前面的行为相比你的修改动机

不兼容变动：需要描述相关信息如果修复了某个Issue的问题，使用“Closes”关键字

1
Closes #234

如果需要关闭多个Issue，使用逗号分隔Issue的编号

1
Closes #123, #234, #345

如果对某个Issue有影响，但是没有完全修复，使用“Updates”关键字

1
Updates #234

正确的 Message 格式示例

New Features

1
2
3
feat(monetization): add BestAzon support
feat(Chinese): add better font support for Chinese language
feat(footer): make external links Nofollow

Fixes

1
2
fix(reST): indents in line blocks is not preserved
fix(gist): embedded Github gist are not laid out correctly

Documentation

1
2
3
4
docs(add): metadata variables
docs(add): release notes for 3.0.0
docs(update): change category of reading-time article
docs(update): set author information

其他杂项

1
2
3
4
chore(livereload): use es2015 syntax for gulp configuration
ci(docs): use sitemap plugin in production only
ci(docs): add default tasks.py file
refactor: move Google and Bing claims to their individual files

Merge

代码合并、master分支操作，请在 git 上提交 merge request,负责人进行代码review后，才能同意合并操作。

Tag(Version)

采用三段式，v版本.里程碑.序号，如v1.2.1

  • 架构升级或架构重大调整，修改第2位
  • 新功能上线或者模块大的调整，修改第2位
  • bug修复上线，修改第3位

参考文献

Git 使用规范流程

Git 分支管理策略

Git Commit Guidelines

How to Write a Git Commit Message

欢迎关注我的其它发布渠道