跳转至

Git 使用流程规范

概要: 本文尝试以 thoughtbot/guides 为参考蓝本，以一种正确的方式使用git工具进行开发工作

创建时间: 2022.06.08 21:07:00

更新时间: 2023.08.16 22:27:47

GitHub Workflow

image.png

Git最佳实践

  • 避免使用rebase的方式合并多个commit
  • 将多个小的commit合并为一个单独的commit
  • 使用规范化的commit

Git仓库维护

  • 仓库中尽量避免包含与特定的机器或环境相关的文件
  • 当merge进行完成后，删除被合并的本地和远端特性分支
  • 在特性分支上进行开发工作
  • 经常进行rebase操作来合并来自上游的变更
  • 使用 Pull Request 进行 Code Review

如何开发特性

在下面过程中，我们假定主分支为 master

创建特性分支

首先，在本地，我们根据最新的主分支代码创建自己的特性开发分支

Bash
1
2
3
4
5
6
# 检出并获取最新的主干分支代码
git checkout master
git pull

# 在确保本地没有mydev分支的前提下，创建自己的特性分支并切换到特性分支进行开发工作
git checkout -b mydev

合并上游变更

在开发某一个特性功能或需求时，可能会持续较长时间。此时为了保证我们的代码基于最新的主分支代码开发，需要时常获取远端的最新代码，然后本地变基

Bash
1
2
3
# 获取远端最新代码并变基
git fetch origin
git rebase origin/master
注意：如果变基过程中有冲突，就手动解决直到成功变基

撰写commit

Bash
1
2
3
git add --all  # 添加所有你改动的文件
git status  # 确认必要的文件已添加，并移除不必要的文件
git commit --verbose  # -v 在详细模式下，进行commit操作
verbose模式下进行commit可以十分清晰地看到当前改动的文件及细节
image.png
commit信息务必规范化，业内做的比较好的是Angular项目，里面的commit都比较规范，建议参考。简要而言，可以遵循如下规范：

  1. commit标题不多于50个字符
  2. commit详细信息中每行不多于72个字符
  3. commit底部可以提供此次commit的目的或来源信息，如issue
    Bash
    1
2
3
4
5
6
    Present-tense summary under 50 characters

- More information about commit (under 72 characters).
- More information about commit (under 72 characters).

http://project.management-system.com/ticket/123

合并commit

当特性开发完毕后，如果在特性分支上残留较多的commit，可能会对代码评审人造成干扰，且扰乱主分支的commit记录，此时就需要将冗余的commit进行合并

使用变基的方式合并commit

如果在开发特性的过程中不止一次进行了commit，此时需要使用交互式变基方法合并commit

Bash
1
git rebase -i origin/master
交互过程解释如下（便于演示，此处提交了3次commit）
image.png
从上面可以看到从远到近的三条commit，关于变基中的操作命令有如下解释

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

在上面的命令中，squash 和 fixup 均可以合并commit，区别在于 fixup 时不会保留当前commit信息
squash 效果（将第1条和第2条合并为一个commit，同时保留二者commit信息）
image.png
image.png
fixup 效果(第2条commit消失)
image.png
image.png

使用撤销的方式合并commit

对于上面提交了3次commit的情况，可以先使用如下命令撤销commit

Bash
1
2
3
git reset --soft HEAD~3
git add --all
git commit -v
image.png
image.png
image.png
这样也可以实现合并多个commit为一个的功能

推送commit

在上面的合并commit完成后，将本地的变更推送到远端，使用如下命令可以直接在远端建立对应的特性分支

Bash
1
git push origin mydev

提交Pull Request

*PR or MR ? *
下面是来自GitLab官网的解释

Merge or pull requests are created in a Git management application. They ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name “pull request”, because the first manual action is to pull the feature branch. Tools such as GitLab and others choose the name “merge request”, because the final action is to merge the feature branch.

下面是个人理解

PR，即 Pull Request，直译为拉取请求，个人理解这是相对于主分支而言，将特性分支的代码拉取到主分支上。另外还有MR，即 Merge Request，直译为合并请求，个人理解是相对于特性分支而言，将特性分支的代码合并到主分支上。二者只是叫法不同，实际的作用都是把其它分支合并到主分支上，实现开发项目的功能交付或者故障修复。

此处以 Gitea 版本控制系统为例，在仓库的 合并请求 页面创建新的PR
image.png
image.png
image.png
到此处，我们成功创建了一个 PR
image.png

如何代码评审

代码评审与合入

在提交PR后，一般需要专业人员对你的代码进行评审，可以直接在网页上进行，此处不再赘述。以Gitea为例，添加评审意见，然后修改合并到主分支上的commit后，点击 合并请求 即可成功将此特性分支内容合入到主分支
image.png
image.png

清理特性分支

清理远端分支

清理远端的特性分支可以直接在网页上进行，也可以本地通过执行如下命令行进行

Bash
1
git push origin --delete mydev
image.png

清理本地分支

注意：如果你是在网页上完成了PR操作，那么删除本地特性分支前需要切换到主分支并更新代码到最新

Bash
1
2
3
git checkout master
git pull
git branch --delete mydev
image.png

参考