文档章节

Git 使用规范和工作流说明

ZYallers
 ZYallers
发布于 2017/07/20 12:39
字数 1668
阅读 10
收藏 0

Git 使用规范和工作流说明

在进入本文档的阅读和学习前,请确保你已通读 Git 官方手册 V2 版中核心前 5 个章节,并了解和掌握了 Git 的基本概念和使用方法。

0 声明

除特别说明,游子科技/奥飞智能旗下所有涉及版本控制 Git 的使用和所涉及工作流,均必须「MUST」严格遵守本规范。

本规范自 2016Q1 起正式对游子科技和奥飞智能科技(奥飞娱乐智能事业部)研发部生效。

1 推荐客户端工具

推荐各开发人员使用 SourceTree 作为主要的代码管理工具,将命令行作为辅助工具。

2 Git 全局配置

  • 必须「MUST」设置 Git 用户相关信息,如下所示:

    # 中文名 公司邮箱
    # 张三 zhangsan@domain.com
    git config --global user.name "张三"
    git config --global user.email "zhangsan@domain.com"
    
  • 必须「MUST」设置如下编码配置:

    # 原样checkout,Unix LF 换行格式commit。
    git config --global core.autocrlf input
    # UTF-8 编码
    git config --global i18n.logoutputencoding utf8
    git config --global i18n.commitencoding utf8
    

3 使用 .gitignore file

不同平台语言的项目工程库需要合理使用 .gitignore 将以下类别文件从版本控制中剔除:

  • 各种密钥、密码等服务器敏感配置文件。
  • 针对本地开发环境的配置文件。
  • 文件缓存类临时性文件。
  • 其他项目规定的文件类型。

开发人员可以在 gitignore项目 中找到平台/语言/框架相关的基础 .gitignore 配置。

4 使用 .gitattributes file

不同平台语言的项目工程库需要设置 Git 属性来规范 Git 对比(diff)和合并(merge)的方式,开发人员可以在 Git 属性模板基础上对项目工程库进行定义。

See Also: Path-based git attributes https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

5 使用 Git-flow 工作流

所有项目和产品研发必须「MUST」以 Git-flow 工作流 模型进行分支定义。

  • 图形化界面请使用 SourceTree 提供的 Git-flow 功能进行分支创建和合并。
  • 命令行工具请参考 Git-flow 工作流 中的示例,推荐使用 nvie/gitflow 脚本创建各种分支。

6 一个日常开发示例

以下命令行示例用于讲解日常新功能开发时的基本操作。

  1. 首先克隆 ssh://git@github.com/xxx/test.git

    # ~/home
    git clone ssh://git@github.com/xxx/test.git
    
  2. 建立分支 developfeature/user-extension

    # ~/home
    cd test
    (master)$: git branch develop
    (master)$: git branch feature/user-extension
    
  3. 切换当前分支到 feature/user-extension,开发新功能

    (master)$: git checkout feature/user-extension
    (feature/user-extension)$: git add xxx
    (feature/user-extension)$: git commit -am 'Added function user-add' -s
    ## BLABLABLA
    (feature/user-extension)$: git add xxx
    (feature/user-extension)$: git commit -am 'Added function user-delete' -s
    
  4. 功能开发完成后,Push 本地 feature/user-extension 至 remote feature/user-extentsion

    git push origin feature/user-extension
    
  5. 建议在 http://github.com/ 上发起 Pull Request 之前 rebase

7 Git commit message 书写规范

开发人员必须「MUST」遵循 Git 官方使用手册中给出的 commit 书写规范:

本次提交 commit 的摘要(50 个字符或更少)

如果必要的话,加入更详细的解释文字。在大概 72 个字符的时候换行。在某些情形下,第一行被当作一封电子邮件的标题,剩下的文本作为正文。分隔摘要与正文的空行是必须的(除非你完全省略正文);如果你将两者混在一起,那么类似变基等工具无法正常工作。

空行接着更进一步的段落。

  • 句号也是可以的。
  • 项目符号可以使用典型的连字符或星号 前面一个空格,之间用空行隔开, 但是可以依据不同的惯例有所不同。

7.1 规范讲解

  1. 第一行为对改动的简要总结,建议长度不超过 50 个字符,用语采用命令式而非过去式。第一行结尾不要留句号,无论是英文的「.」句号或者是中文「。」句号。
  2. 第二行为空行。
  3. 第三行开始,是对改动的详细介绍,可以是多行内容,建议每行长度不超过 72 个字符。如果代码托管在 Github 上,那么推荐在此通过 #ID 方式引用本次提交所关联的任务(Issue)。
  4. 建议使用中文,务必 UTF-8 编码。也可使用全英文,首字母大写。除专有名词外,禁止在描述中中英文语句混搭。
  5. 避免注释不清晰。比如只有「修正 BUG」、「改错」、「升级」、「添加某文件」等,没有其他内容,等于没说。 6.「提交」的概念是具有独立的功能、修正等作用。小可以小到只修改一行,大可以到改动很多文件,但划分的标准不变,一个提交就是解决一个问题的。对格式的修正,不应该和其他功能修补一起提交,这种情况应该考虑使用 git add --editgit add -p 也可以用用,更复杂和强大一些。在提交前,按实际情况,可使用 Rebase 压缩自己本地的多个小提交。

7.2 摘要前缀

每次提交的改动建议添加「英文」关键词前缀,用于指示本次改动的主题。

  • Add 新加入的需求
  • Fix 修正Bug
  • Change 修改功能
  • Update 完成任务或者模块变化做的更新
  • Remove 移除功能
  • Refactor 重构功能

7.3 注意事项

  • 以上示例中除第一行摘要部分必须「MUST」填写外,其余内容可选择性编写,但一旦选择编写,必须「MUST」遵守 7.1 中的规范。
  • 始终保持第二行留空。
  • 特殊情况
    • 版本号更新 格式: Bump version: 0.1.2-dev → 0.1.2

8 Github Pull Request (PR) 提交规范

  1. 每个 PR 必须「MUST」在提交时需在标题中添加 [PR] 前缀用于邮件推送时区分 PR 和 ISSUE.
  2. 每个 PR 必须「MUST」仅包含一个主题。每个 PR 应该仅包含针对单一主题的一系列变更,不要在一个 PR 中包含多个主题。举例来说:假设你开发了 X 和 Y 两个不同主题的相关内容,若此时将所有 commit 以同一 PR 的形式进行提交,如若 Reviewer 仅认可与 X 相关的变更但不同意 Y 主题的相关变更——这将导致我们将无法对此 PR 进行合并操作。
  3. 每个 PR 提交人必须「MUST」指定一名 Code Reviewer 进行代码审查,并必须「MUST」由 Code Reviewer 进行合并。

9 参考资料

  1. https://ruby-china.org/topics/15737
  2. https://github.com/erlang/otp/wiki/Writing-good-commit-messages
  3. https://www.gitignore.io
  4. https://github.com/thephpleague/skeleton
  5. https://www.reddit.com/r/PHP/comments/2jzp6k/i_dont_need_your_tests_in_my_production
  6. https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

© 著作权归作者所有

共有 人打赏支持
ZYallers
粉丝 1
博文 59
码字总数 19100
作品 0
佛山
程序员
加载中

评论(1)

ZYallers
ZYallers
:+1:
初创公司应该如何做好持续集成和部署?

持续集成和部署是每一个互联网开发团队都必须要面对的问题,特别是在初创公司,由于业务和技术团队快速增长,技术积累较弱的,所以一个高效的,可持续的运维规范尤为重要。 最近一段时间一直...

90xa
2016/03/19
87
0
Git LFS 1.0 发布,Git 的大文件支持

Git LFS 1.0 发布,现已提供给 GitHub.com 的所有仓库。 Git LFS 是开源 Git 扩展,GitHub 在 4 月份发布,集成到 Git 工作流中。 Git LFS 1.0 包含一些新特性和 bug 修复,值得关注的改进:...

oschina
2015/10/02
2.8K
7
详解使用git commit 工作流的标准姿势

前言 之前我写过一篇有关于git提交的文档《用gitmoji来提交你的git commit吧》,然而在实际上应用并不是很方便,大多情况得翻阅gitmoji对照表来写commit,且并不规范,仅仅适用于自己开发的项...

mytac
07/13
0
0
Gerrit 代码审核服务器的工作流和原理

Gerrit 代码审核服务器的工作流和原理 谷歌 Android 开源项目在 Git 的使用上有两个重要的创新,一个是为多版本库协同而引入的 repo,这在之前我们已经详细讨论过。另外一个重要的创新就是 ...

mysky221
2014/11/01
0
0
好代码是管出来的——Git的分支工作流与Pull Request

  上一篇文章好代码是管出来的——使用Git来管理源代码 介绍了常用的版本控制工具以及git的基本用法,从基本用法来看git与其它的版本控制工具好像区别不大,都是对代码新增、提交进行管理,...

dotNET跨平台
06/25
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

Minifilter的动态安装、加载及卸载

MINIFILTER框架的文件系统过滤驱动,无法使用的CreateService和OpenService进行动态加载。 看了一下,使用Inf文件安装Minifilter驱动的方式是在注册表驱动服务项下比传统驱动多创建了Instanc...

simpower
23分钟前
1
0
idea新建springCloud项目(6)- Config Server使用

1.在IDEA新建springCloud项目-Config Server 修改版本,和之前建的eureka项目版本一致,修改完记得刷新: 删除掉不需要的文件: 2.把Config S 服务注册到eureka上去,配置git地址,启动项目 ...

monroeCode
29分钟前
3
0
大数据可视化项目开发总纲

第1章 开发文档总纲 1.1 开发工具清单 名称 版本 备注 Pentaho-bi server pentaho-server-ce-7.1 Pentaho Cde为其内置工具 Pentaho-prd pentaho-prd-ce-7.1 Pentaho Report Designer报表工具...

ZhangLG
29分钟前
2
0
pip安装超时问题

pip3 install --default-timeout=100 tensorflow 设置为100秒 参考: User Guide How to solve ReadTimeoutError: HTTPSConnectionPool(host='pypi.python.org', port=443) with pip?......

亚林瓜子
31分钟前
1
0
fragment 旋转时保持当前实例

设备旋转时保存Fragment的交互状态: setRetainInstance(true);

zdglf
33分钟前
1
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部