问题: 由于项目的版本线混乱, 导致可能需要在不同分支上切换, 而且某些功能也可能在不同分支上移动.
一个版本可能有多个功能点, 一个版本又对应于一个分支, 如果一个功能点有多个提交, 那么当其他分支需要这个功能点时怎么办? cherry-pick或patch都可以实现, 但是都各有麻烦的地方: cherry-pick需要找出要移动的功能点相关的提交记录, 而patch需要功能点的提交记录都是连续的. 实际开发中不同功能点之间的提交记录往往是穿插的. 如果某个功能点相关的改动只生成一个commit,这将极大的简化功能点在分支间的移动工作. 那么是否可以实现改动某次提交和将现有改动追加到某次提交上呢?
下面是cherry将某个功能点从一个分支移动到其他分支的示意图:
如上图, 可以使用cherry-pick将某个功能点从branchA移动到branchB上, 步骤如下:
- 切到branchB分支上
- 执行命令
git cherry-pick 0096b95 7bfbaaa 326d7d8
那么问题来了, 如果某个功能点提交了很多次且log信息不规范, 那我们找commit-hash的时候就得费一番功夫了, 可不可以将后来的改动追加到以前的某个commit上呢? 或者直接更改改以前的某次提交?
答案是: 可以! (git中将当前改动追加到上一次提交上可以使用命令git commit --amend实现, 下面介绍的两种解决方案都使用了这样命令)
<一> 下面是直接更改某次提交的操作步骤:
- 将HEAD移到需要更改的commit上:
git rebase f744c32cf74454a74bb2f80e5e38b120cb475af1^ --interactive
找到需要更改的commit, 将行首的pick改成edit, 按esc, 输入:wq退出 - 更改文件
- 使用
git add 改动的文件添加改动文件到暂存 - 使用
git commit --amend追加改动到第一步中指定的commit上 - 使用
git rebase --continue移动HEAD到最新的commit处
这里会有冲突, 需要解决:- 编辑冲突文件, 解决冲突
git add .git commit --amend
解决冲突之后再执行git rebase --continue
上述方法, 是改动某个指定的commit, 如果我要将工作空间中已经改动的东西追加到某个commit上, 那么改如何做呢?
<二>将工作空间中的改动追加到某次提交上的步骤如下:
- 保存工作空间中的改动
git stash - 后面的步骤就和上面的决绝方案的步骤差不多, 只是第2步的
更改文件改成执行命令git stash pop, 其他步骤都一样
这样处理之后, 如果branchB分支需要branchA分支上的某个功能, 只需要找到这个功能的惟一的一个提交记录即可, 就不需要在很多commit之中寻找这个功能点的相关提交记录. 更改合并之后再移动功能点, 就简单了许多, 执行找到功能点的惟一一个提交记录, 让后使用git cherry-pick commit-hash即可, 操作示意图如下:
总结: 上述更改摸个提交记录/将现有改动追加到某个commit之上的方案在实际开发环境中的需求并不多, 而且实现起来有相当的局限性, 原因如下:
- 如果版本规划比较清晰, 就不会出现某个功能在不同版本之间穿梭的情形, 出现这种情况的大部分原因是:
多个版本的开发并发进行(产品你TMD当我们是电脑么, 有多个cpu同时运行啊?! 不好意思, 忍不住爆粗口了-_-!) - 实际开发中一次提交中的改动不可能只改动一个功能点 (如果模块或者功能点的边界划分的十分清晰, 是可以做到每次只改动一个功能点的)
