目录

缘由

接触了一个新的项目，发现分支和以前做平台接国内各大安卓渠道相像，由于国内渠道当时有300多，所以项目的分支在一段时间内相应的也会很多，所以git graph是相当复杂，缠绕交织的，看着人也百感交集。和一位开发讨论聊起了这个事，发现大部分项目更多的是使用合并，几年前给非开发同事讲解如何使用SVN的合并（非RD当时能用svn就很不错了），发现其他还是不少开发也没有搞清楚过merge，更不用说碰到这么多分支交错的merge来merge去的，导致项目主分支各种三方自动commit的消息，看起来很凌乱的时间线，那怎么拥有一个干净整洁的版本管理时间线和日志消息呢？

可能你也想到，那就是有人提到的git rebase，rebase可以说用的人还真不多，因为很多项目都停留在merge，或是对rebase陌生从而不敢去尝试了解，所以我们也很有必要备忘下一些关于rebase的基础知识，以备临时讲解时需要，大部分常用git的开发者看官方文档就可以理解透了。

假设3个分支

假设有3个分支，master、func1、func2

  • master 主分支，一般用于发布（这里假设用于做底层开发）
  • func1 基于master，用于开发上层功能1
  • func2 基于master，用于开发上层功能2

示例1，基于common-test实现func1和func2功能：

  • 0 开发者0 在master做底层代码开发
  • 1 开发者1、开发者2 在各自本地开发环境从master分别拉出开发分支func1 和 func2
  • 2 开发者0 在master继续迭代底层功能代码，新增common-test.md
  • 3 开发者1 在本地func1分支迭代上层功能代码（新增func1.md）
  • 4 开发者2 在本地func2分支迭代上层功能代码（新增func2.md）
  • 5 开发者1 的func1分支需要同步master分支的common代码，可以先把本地代码都commit，再rebase到本地master（前提本地master更新到最新，func1将基于本地最新master，并重新应用func1之前的commit）
  • 6 开发者2 的func2分支需要同步master分支的common代码，可以先把本地代码都commit，再rebase到本地master（同上func1操作）
  • 7 开发者1 在func1分支开发完成，本地commit，再次rebase到master（前提master更新到最新）
  • 8 开发者1 切换到master并更新到最新，然后并将func1分支合并到master，最后push master
  • 9 开发者2 在func2分支开发完成，本地commit，再次rebase到master（前提master更新到最新）
  • 10 开发者2 切换到master并更新到最新，然后将func2分支合并到master，最后push master

示例2，基于loginService实现web和pc登录

  • 0 开发者0 在master新增loginService服务
  • 1 开发者1 在本地开发环境更新master到最新，func1分支rebase到master
  • 2 开发者2 在本地开发环境更新master到最新，func2分支rebase到master
  • 3 开发者1 在func1分支实现web的login，新增webLogin代码，并commit
  • 4 开发者2 在func2分支实现web的login，新增pcLogin代码，并commit
  • 5 开发者0 在master分支上修复loginService bug
  • 6 开发者1、开发者2在各自func1和func2分支上重新rebase下master的最新修复的代码（前提本地master更新到最新）
  • 7 开发者1 继续在func1上开发，完成开发，并commit
  • 8 开发者2 继续在func2上开发，完成开发，并commit
  • 9 开发者1 更新本地master分支，将func1合并到master（squash，将func1分支的所有commit重写成一个commit）
  • 10 开发者2 更新本地master分支，并将func2合并到master（squash，同上）

注：当然也可以不考虑使用squash，保留每个开发者的历史真实commit记录

参考

Git Book 中文版 - rebase

Git - 变基