【Git 系列】实战应用的常见技巧【一】

实战应用

本文主要讲述在本地进行开发的常见技巧，偶尔牵扯和远程仓库的交互。

VScode中关于Git的插件

下面推荐两个好用的插件：Git Graph 和 GitLens。

Git Graph

Git Graph 能够可视化 commit 和 branch，通过点击的方式创建 branch、切换 branch、合并 branch、提交 commit 等操作。大大简化了操作难度。下图为branch 和 commit的可视化。

GitLens

GitLens 在 VScode 插件中的展示

GitLens 可以有丰富的功能。个人使用该插件，主要查看每个文件中不同内容的作者，自动同步 remote。当然，功能不止于此，大家可以自己挖掘。由于该插件无法可视化 branch 和 commit，所以需要配合第一个插件使用。下图为使用的效果图。

免密push和pull

背景

默认情况下，当你需要 push 和 pull 远程仓库，需要输入账号和密码，非常繁琐。使用下面方法就可以实现免密 push 和 pull，简化操作。

具体步骤

具体操作主要分为两步：

1. 使用文件创建用户名和密码

cd ~ 
touch .git-credentials
vim .git-credentials 
https://{username}:{password}@github.com  # 记得在真正输入的时候是没有大括号的

2. 添加 git config 内容

执行git config --global credential.helper store命令后，用户主目录下的 .gitconfig 文件会多了一项：

[credential]
	helper = store

上述两步执行后，执行 git push 就无需密码（有可能需要开新终端才有效）

使用 Git 开发的正确姿势

背景

想必大家都通过各种 Git 命令，或者通过插件进行 branch 和 commit 的建立，删除和合并。虽然，整个开发过程也可以完成，但是对 branch 和 commit 都是随意建立和删除，这使得整个开发流程的管理非常混乱。下面介绍的方法，可以帮助我们将 branch 和 commit 管理更加清晰，并与业界对齐。下图展示了采用此方法开发的流程示意图。

方法的总览

开发中，Git中总共包括三类分支：master、develop supporting branch。整个开发过程中，这三类分支贯通始终，各司其职。下面总体上介绍三类分支的功能。

• master 分支：永远是可以用于生产应用的分支，每个 commit 都是可以生产应用

• develop 分支：相当于内测版本，所有特性的开发都依赖该分支，当 develop 上积累了一定的新特性，就可以准备发行该版本。

• supporting 分支：又细分为三个子分支

  • feature branch 需求分支：当有新特性想要增加，需要为该新特性创建新分支
  • release branch 发布分支：当 develop 分支稳定，可以创建该分支，用于上线的调整
  • hotfix branch 修复分支：当 master 分支中，发现 bug， 需要创建该分支，用于 bug 的修复

master 分支和 develop 分支在初始就需要创建，并且贯穿始终，不会被删除。而 supporting 分支完全依赖 master 或 develop 分支，有自己的生命周期，分为三步：创建-使用-删除。

由于 supporting 的三类分支完全依赖master 和 develop 分支，所以仅介绍 supporting 分支就能够了解 master 和 develop 的分支的作用和使用场景。那么对于不同的 supporting 分支，都需要依赖哪个分支进行创建？分支的命名有何要求？分支完成后，都需要合并到哪个分支？各个分支的特点有哪些？下面的章节中将介绍这些细节。

需求分支

创建时机：当在 develop 开发过程中，有新的需求产生，此时，需求分支就需要被创建

分支作用：完成某个新需求的研发

分支来源：develop 分支

分支去向：develop 分支

分支命名：任意能体现该需求的名字，但不能为master、develop、以“release-”开头和以”hotfix-“开头

特点：

• 该需求是否要整合进正式版本是未知的，所以需要单独创建该分支
• 只要该需求尚在研发，就需要一直保留
• 该需求分支完成后，将被合并到 develop 分支中，作为下一个待发布版本的功能之一（或者由于无法实现而被删除）

使用流程：

1. 突然有个新的需求发生，从develop创建该需求分支。
git checkout -b feature_branch develop 
# 该命令含义：1. 从develop分支创建新分支 feature_branch，并从当前分支切换到feature_branch

2. 进行该需求的研发

3.研发完成后，将该分支合并到 develop
git checkout develop # 切换到 develop 分支 
git merge --no-ff feature_branch 
#合并需求分支。 --no-ff 参数表示No Fast Forward，在合并使，即使可能是fast forward方式，也会创建一个新的commit节点。
#后面将介绍fast forward 和 no fast forward的区别。

4. 删除分支 和推送 
git branch -d feature_branch #删除该需求分支 
git push origin develop # 如有需求，需推送到远程仓库 

下图展示了 fast forward 和 no fast forward 在合并后的区别。

发布分支

创建时机：当 develop 分支特性积累一定数量，此时，就可以选择创建发布分支

分支作用：完成本次发布的准备工作，或者修复一些小 bug

分支来源：develop 分支

分支去向：develop 分支和 master 分支

分支命名：以 “release-” 开头

特点

• 发布分支用于辅助新版本发布的准备工作，例如小 bug 的修复，或者版本号的修改等等。
• 有发布分支，可以不妨碍 develop 的继续扩展 ，也不妨碍发布的进行。

使用

1. 创建发布分支 
git checkout -b release-1.2 develop #创建并切换到"release-1.2"分支

2. 完成发布的准备工作或者小bug的修复等
git commit -a -m "bug修复" #提交代码

3. 当发布分支完成代码的提交（如果修复过bug，则要合并到develop分支）后，需要将发布分支合并到master分支上，并进行tag操作，如：
git checkout master # 切换到maste分支
git merge --no-ff release-1.2 # 合并 发布分支
git tag -a "v1.2" #打上标记 

如果发布分支过程中，修复了bug，需要将发布分支合并到 develop分支：
git checkout develop #切换到develop分支
git merge --no-ff release-1.2 # 合并发布分支 

4. 删除分支和推送 
git branch -d release-1.2  #删除分支 
git push origin master 

修复分支

创建时机：发行版本，反馈有 bug，此时需要创建修复分支

分支作用：紧急修复 bug

分支来源：master 分支

分支去向：develop 分支和 master 分支

分支命名：以 “hotfix-” 开头

特点：

• 用于紧急修复master分支上的bug。修复完成后，需要合并到master分支和develop分支。

使用

1. 发现bug，创建修复分支
git checkout -b hotfix-1.2.1 master

2. 修复bug后
git commit -a -m "修复bug"
git commit -a -m "版本更新为1.2.1"

3.完成修复后，进行合并master和develop
git checkout master
git merge --no-ff hotfix-1.2.1 
git tag -a 1.2.1 #tag操作

# 合并修复分支到develop分支
git checkout develop 
git merge --no-ff hotfix-1.2.1

4. 删除修复分支
git branch -d hotfix-1.2.1

总结

为了更加规范的管理 branch 和 commit，介绍了上述的方法。整个开发流程核心的分支为三类，master、develop 和 supporting 分支。其中，master 分支和 develop 分支都是贯穿始终。而 supporting 分支，有自己的生命周期：创建-研发-删除。所以管理最复杂的即 supporting 分支中的三类子分支，每类子分支的创建分支来源和合并分支去向非常重要。

参考文章

一个成功的Git分支模型 - 简书 (jianshu.com)

git 和 jupyter 使用小技巧 ｜ 言之凿凿 (todebug.com)