Git知识补充

记录在项目过程中遇到的git相关的问题，并作为知识点进行记录

• Git Flow
• Cherry Pick

test

https://github.com/cwxyr/nuedc-2019-openmv

https://github.com/MegEngine/MegEngine

https://github.com/xiongjiamu

https://github.com/apache/echarts

https://github.com/MegEngine/MegEngine/blob/master/cmake/BuildFlatBuffers.cmake

https://gitlab.com/gitlab-org/gitlab-vscode-extension

https://gitcode.com/apache/echarts

https://codechina.csdn.net/csdnassistant/developer/-/wikis/CSDN开发者周刊征稿

https://codechina.csdn.net/csdnassistant/developer/-/wikis/CSDN%E5%BC%80%E5%8F%91%E8%80%85%E5%91%A8%E5%88%8A%E5%BE%81%E7%A8%BF

https://gitee.com/openharmony/docs

Git Flow

git的workflow，按照目前主要的git工具来看，有三种常见的workflow，分别是：

1. git flow
2. github flow
3. gitlab flow

git flow

git flow 是最早出现的workflow，他通过 master 和 develop 两个分支来维护项目，在使用过程中git flow的分支有如下两个特点：

• 长期存在 master 和 develop 两个分支
• 短期存在 feature branch（功能分支）、fix branch（补丁分支）以及release branch（预发分支）三个分支

master 是用于对外发布的稳定版本， develop 是用于日常开发，存放着最新的开发版本；短期存在的分支一旦开发完成，就会被合并到 develop 或 master 分支，然后被删掉。

Git flow 的优先是版本清晰可控，缺点是维护成本较大，需要维护两个长期存在的分支。此外，这种模式是基于“版本发布”的，目标是通过一段时间的开发后产出一个新版本。与目前的 CI/CD 需求不太匹配，在 CI/CD 中，master 和 develop 分支基本保持一致，并无太大差别，导致这种模式实用性降低。

github flow

github flow 是 git flow 的精简版，专门用于“持续发布”，与 git flow 相比，他只用维护一个长期分支 master，这种 flow 模式下的工作流程也比较简单，主要有以下几个步骤：

1. 根据需求从 master 上新建一个分支（不区分 fix 和 feature）
2. 在新的分支中按照需求/功能进行 coding
3. coding 完成后向 master 分支提出 Pull Request（PR）请求，同时 master 分支的维护人员会收到通知，会对 PR 进行 review（ PR 合并前可以一直进行代码的 commit 修改工作）
4. review 完成之后，PR 就可以被接受，同时相应的代码也会被合并到 master 分支，同时之前的分支会被删掉

从上面的步骤可以看出，github flow 可以很好的适应持续发布的流程，可以随时向 master 提交 PR。

不过，这种模式下也存在一些问题，因为只有一个 master分支的前提是假设了 master 分支的更新与产品更新是一致的，也就是 master 分支的最新代码，也会被默认当前线上的代码。但实际情况中，经常会出现 master 分支中的代码与产品更新不一致的情况，线上产品运行的版本极有可能是落后于最新的 master 分支的。

gitlab flow

gitlab flow 是一种综合了 git flow 以及 github flow 两者优点的模式，他不仅适用于不同环境的弹性开发，也保持了单一主分支的便利性，主要以下几个特点：

• 上游优先：gitlab flow有一个上游原则（upstream first），存在一个主分支 master，他是所有分支的上游，只有上游分支采纳的代码更新才能够应用到其他分支上去。
• 持续发布：对于持续发布，gitlab flow 除了在主分支外，还会设置 pre-production 和 production两个分支，三者之间的上下游关系如下： master > pre-producton > production ，比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
• 版本发布：对于版本发布，gitlab flow 是将每次要发布的版本从 master 分支上 checkout 出一个 xxx stable（稳定版本） 分支，并将其作为 xxx-stalbe 对外发布，此后，只有bug fix 才可以合并到这些 stable 分支上，同时更新小版本号

---

知识点

• squash commit ：压缩多个commit，在发起 PR / MR 之前，需要先将多个commit squash 成一个（前提是这个分支只有你一个人开发，且没有跟 master 合并过。）

  执行命令如下：

  git rebase -i HEAD~4
  
  # 输入上面命令后，会进入一个edit界面，eidt其中未被注释的信息，只保留最上面一行的 pick，同时将下面所有的 pick 修改为 squash，然后 保存并退出
  
  # 上一步保存退出后，会进入到修改commit 信息的 edit界面，这里需要修改一下新的commit信息，同时注释掉不需要保留的 commit 信息，然后 保存并退出，这个时候多个 commit 信息的 squash 操作就已经完成
  

  参考链接squashing commits with rebase

• cherry pick：提交指定的 commit 到其他分支，适用于将当前分支上某个/多个 commit 单独提交到其他分支上的时候。

  执行命令如下：

  # 提交单个/多个 commit
  git cherry-pick <commit Hash-1> <commit Hash-2>
  # 提交分支上的最近一次 commit
  git cherry-pick branch-name 
  # 提交多个连续的 commit ( A ~ B之间的所有commit，A 必须是要早于B提交的，且A不会被提交过去)
  git cherry-pick A..B
  # 提交多个连续的 commit ( A~B 之间所有的commit，且包含A)
  git cherry-pick ^A..B
  # 转移多个 commit 但不提交 ( -n 表示 --no-commits)
  git cherry-pick <commit Hash> -n
  # 提交多个 commit 并追加 cherry-pick信息(会在 commit 信息的最后增加 cherry picked from commit ...)
  git cherry-pick <commit Hash> -x
  # ---------------------
  # 在 cherry-pick 合并时产生冲突，可以使用的命令
  # 解决冲突后继续进行 cherry-pick
  git add .
  git cherry-pick --continue
  # 放弃，并回到操作前的样子
  git cherry-pick --abort
  # 退出 cherry-pick，但是不回到操作前的样子
  git cherry-pick --quit
  

  参考资料：git cherry-pick 教程