实战应用
本文主要讲述在本地进行开发的常见技巧，偶尔牵扯和远程仓库的交互。
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，简化操作。
具体步骤
具体操作主要分为两步：
- 使用文件创建用户名和密码
cd ~
touch .git-credentials
vim .git-credentials
https://{username}:{password}@github.com # 记得在真正输入的时候是没有大括号的
- 添加 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)