Git 和 Git 分支模型

本文基于使用私有部署的 GitLab 来作为代码仓库,来讲述我们在使用 Git 作为版本控制工具方面的实践。

配置 SSH KEY

为了可以免密拉取和提交代码,需要配置 SSH key。

  1. 查看是否已有 SSH key 存在

打开终端,输入 ls -al ~/.ssh

ls -al ~/.ssh
# Lists the files in your .ssh directory, if they exist

如果存在,跳到 3 步,否则,跳到第 2 步

  1. 生成 SSH Key

打开终端,复制以下命令,记得替换邮箱地址

ssh-keygen -t rsa -b 4096 -C "[email protected]"

一路回车即可,不要设置密码

  1. 复制 SSH Key 到 GitLab

    运行以下命令,复制 SSH Key 到剪贴板

pbcopy < ~/.ssh/id_rsa.pub
# Copies the contents of the id_rsa.pub file to your clipboard

打开 GitLab -> Profile Settings -> SSH Keys 右键粘贴或者 Command + V,把刚刚拷贝的 SSH Key 添加到 Key 文本域里面,注意不要有新行或空格,随意起一个 title,点击 Add key 按钮确认添加。

git-flow-2021-10-14-22-16-41

  1. 测试 SSH 连接

通过以下命令测试 SSH 连接,记得将 gitlab.com 替换成私有部署的 GitLab 域名。

如果连接成功,会看到下面这样的信息

Welcome to GitLab, @listen!

掌握 Git 基本知识

git-flow-2021-10-15-01-54-52

常用命令:

# 从远程主机克隆仓库到本地
git clone [url]

# 新建一个分支,并切换到该分支
git checkout -b feature/login

# 显示本地仓库状态
git status

# 添加当前目录的所有文件到暂存区
git add .

# 提交暂存区到仓库区
git commit -m [message]

# 修改上一次提交
git commit --amend -m [message]

# 用 rebase 模式合并代码
git pull --rebase origin master:feature/login

# 删除在远端已经不存在的分支,以及同步远端 tag
git fetch --tags --prune origin

# 解决冲突后,继续 rebase
git rebase --continue

# 上传本地指定分支到远程仓库,并建立追踪关系
git push -u origin feature/login

# 强行推送当前分支到远程仓库对应分支,即使有冲突
git push --force

# 停止追踪指定文件,但该文件会保留在工作区
git rm --cached [file]

# 改名文件,并且将这个改名放入暂存区
git mv [file-original] [file-renamed]

请务必理解 merge 和 rebase 的区别open in new window

如果遇到意外,可使用 git refloggit reset --hard 来救命。

推荐使用 Sourcetreeopen in new window 可视化管理 Git 仓库,专注于编码。

brew install --cask sroucetree

提交规范

一个 Commit 只应该做一件事情,或者添加、删除功能,或者处理 BUG,或者修改构建配置等等。

一条 Commit 消息,由标题和正文两部分组成,通常只有标题,而没有正文。

标题应当简洁明了地陈述清楚,在什么领域,为了什么,做了什么事情。标题尽量简短,不要超过 30 个汉字。标题必须以动词开头。譬如:

# 添加验证码登录

# 添加 vivo 推送

# 处理因为苹果 logo 未能通过审核的问题

# 修改 eslint 配置,以禁止行内样式

# 移除个人中心无用的方法

# 调整主页样式

如果有需要,可以空一行,书写正文,解释为什么要这么做,如果是修复 Jira 上的 BUG,把 BUG 的链接放在这里。譬如

# 处理切换用户,数据没有同步的问题

# https://jira.xxxxxx.com/browse/DA-248

禁止像如下那样编写 commit 信息

修复 DA-248

DA-248 代表什么问题,你倒是说清楚呀。

理解 Git 分支管理模型

阅读基于 Git 的分支管理模型open in new window,理解什么是 Git Flow GitHub Flow Trunk Based Development

我们使用的分支管理模型主要基于 Trunk Based Development

git-flow-2021-10-15-01-55-13

master 分支是我们的持续集成分支,是个受保护的分支,不允许直接 push 代码。

也就是说,以下命令将会失效

git push origin master

日常开发流程

  1. 当有新的需求时,从 master 分支 checkout 一个 feature 分支

分支可以以功能名称命名或以开发者的名字命名,如 feature/login

# 创建新的 feature 分支
git checkout -b feature/login
  1. 定期从 feature 分支 rebase 到 master 分支
git pull --rebase origin master:feature/login

如果有冲突,解决冲突,继续 rebase

git rebase --continue

不要等到自己负责的功能完成后才将代码 rebase 到 master 分支,要养成及时更新代码的习惯。这样可以避免许多冲突。

  1. 功能开发完成后,推送 feature 分支到远程仓库
git push -u origin

如果使用 SourceTree,在推送代码时,不要把推送所有标签勾上

  1. 创建 Merge Request,请求合并 feature 分支到 master 分支

git-flow-2021-10-15-01-55-28

创建 Merge Request 后,只要代码还没有合并,都可以持续提交代码,甚至强制提交。

git push --force

代码通过 review 合并后, feature 分支通常会被删除,可使用以下命令清理本地仓库,以免堆积过多无用分支。

git tag -l | xargs git tag -d #删除本地 tag
git fetch origin --prune #同步远程 tag,并删除本地无用分支

release

需要发版时,由项目 owner 创建 release 分支,并打上 tag 作为版本号,发布新的版本。

如果线上版本有 BUG,通常在 master 分支进行修复,然后由项目 owner 根据情况 merge 或 cherry-pick 到对应的 release 分支,打上新的 tag 并发布新的版本。

git-flow-2021-10-15-01-55-44

学习参考资料

上次更新: 11/16/2021, 7:46:25 AM