开发流程和 git 使用笔记

技术评审流程

基于 RFC 的

在 XDF 开发做重要功能点之前一般都会有一个技术评审流程，在开发重要的功能点之前，请发起 Request For Comment (RFC)进行讨论:

1. 将 template.md 复制到新文件并填写详细信息。提交这个 RFC 在你自己的
   repository fork。
2. 提交一个 merge request (MR)请求到 main repository。每个 RFC 有自己的 MR 请求，不要将
   RFC 与其他文件修改关联。这个 RFC MR 的名称格式为 RFC: <RFC名称>。
3. 相关人员通过 PR review。在通过 PR view 之后，PR 发起者把 RFC 的 status 改成 in-progress,
   更新 RFC MR，合并 MR 到 main repository。
4. 实现 RFC 描述的功能的 issue 名称格式为 RFC IMPL: <<RFC名称>>。如果已经完成了 RFC 中描述的功
   能，将 MR 的 status 从 in-progress 更改为 completed。

如果在第 2 步中没有办法进行 MR 操作，必须在 master 分支上撰写 RFC，也可以通过 issue 来进行 RFC 的
讨论。关联的 issue 名称为 RFC: <RFC名称>。

RFC 内容：

• 必要的数据库表设计
• 必要的性能指标

RFC 状态:

• draft:
• in-progress:
• completed:

Refernces:

• CockroachDB RFC

基于石墨文档的

通过石墨文档的 comment 机制进行 review

编码开发流程

Gitflow
template.md

说明：

1. 以上是简化后的 Gitflow；
2. 须对于关键分支在 GitLab 上设置“分支保护”，设置“Allowed to push”为“No one”；
3. 在 Gitlab 上用 Merge Request 过程进行 Code Review，须由非本人接受 merge 操作。

References:

• Git Feature Branch Workflow
• Gitflow Workflow
• [CockroachDB Contributing Guide]
  (https://github.com/cockroachdb/cockroach/blob/master/CONTRIBUTING.md)
• [Kubernetes Developer Guide]
  (https://github.com/kubernetes/community/tree/master/contributors/devel)
• grpc-java Contributing Guide

配置 Git

保证你的系统上有 Git Bash Shell。Windows 系统从 https://git-scm.com/download/win 上
下载安装文件。MAC 系统可以使用 Brew 进行安装。

在 Windows 的 Git Bash Shell 运行 git config -l | grep autocrlf，运行结果应该是
core.autocrlf=true。如果不是运行 git config --global core.autocrlf true。

用新东方的企邮做如下配置，例如你的企邮是 liumin@ff.cn，那么运行以下命令：

git config --global user.name "Min Liu"
git config --global user.email liumin@ff.cn

推荐和 Git 一起使用 Beyond Compare。在 Windows 上安装完 Beyond Compare 4 之后，在 Git Bash 中运行
以下命令：

git config --global diff.tool bc3
git config --global difftool.bc3.path "c:/Program Files (x86)/Beyond Compare 4/bcomp.exe"
git config --global difftool.prompt false

difftool.bc3.path 可能需要根据你安装 Beyond Compare 的位置调整一下。

git difftool 会使用配置好的 Beyond Compare 进行文本比较。

Git commit message format:

Short (72 chars or less) summary of changes

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a
    single space, with blank lines in between, but conventions vary here

关于如何写 commit message，参见[Writing good commit messages]
(https://github.com/erlang/otp/wiki/Writing-good-commit-messages)。

编码规范

我们遵循 Google Style Guides:

• Google Java Style Guide
• Google JavaScript Style Guide
• Shell Style Guide
• Google Python Style Guide
• Google HTML/CSS Style Guide
• Google Objective-C Style Guide
• Google C++ Style Guide
  -Google TypeScript style

JSON 的命名规范遵循 JavaScript 的，参见 Camel case: defined。

其他各个模块可以根据自己的需要在此基础之上进行细化。

使用 UNIX 风格的 UTF-8 编码的文本文件，缩进采用两个空格。源代码的注释和 git commit message 尽量使
用英文，除非是要用中文解释业务。

详细的 gitworkflow

先把 master repository 上的代码 clone 到本地，把 origin 改成 upstream

git clone git@gitlab.xxx.com:demo.git
git remote rename origin upstream

在 Gitlab 上从 main repository 做一个 fork repository, 在本地的 git 目录用以下命令加上 fork remote：

git remote add fork git@gitlab.xxx.com:demo.git

在本地的 git 上建立一个 branch，例如 git checkout -b dev-leqiang

# 显示所有分支
git branch -a

# 切换分支和创建分支
git checkout -b branch_name tag_name

# 删除本地分支
git branch -d dev-leqiang

# 强制删除
git branch -D dev-leqiang

# 删除远程分支
git push origin --delete dev-leqiang

# 强制提交
git push -f origin

# 多个git commit合并成一个commit
git rebase -i HEAD~x

# rebase处理完冲突继续操作
git rebase --continue

# 提交单个commit到fork repository
git push <fork repostory> dev-leqiang

# 用以下命令和upstream的master保持同步
git fetch upstream master
git rebase upstream/master

# 查看当前分支树历史提交
git log

# git 回滚到某个版本，不保留修改
git reset --hard 5375a685e8cc163454c7e57087ffb6df41716fd3

# git 回滚到某个版本，保留修改
git reset --soft <HASH>

# 把所有没有提交的修改暂存到stash里面
git stash
git stash pop 恢复