Git(11)-cherry-pick、reset、rebase

git 提供了【修改】【完善】版本库中提交的机制。有很多需要让你去修改或返工某个提交的情况，例如：在某个问题编程器遗留问题前修复它。
【注意事项】如果一个分支已经公开，就不应该重写、修改、更改该分支的任何部分。应该使用git revert命令产生新的提交。

命令概览

git reset commit_flag   # --soft、--mixed、--hard 三个选项， 移动HEAD指向的提交

git checkout branch1    # 转移一个分支上的提交->另一个分支上
git cherry-pick commit_flag 

git revert commit_x    # 撤销某些内容，产生一个新的提交

git checkout topic     # 改变topic分支的基础为master分支上的最新提交
git rebase master      # 等价于git rebase master topic

git rebase --continue   # 解决冲突后变基操作
git rebase --skip      # 跳过某些会产生冲突提交，以避免某些冲突。
git rebase --abort    # 可以终止变基础操作，使版本库恢复到变基前的状态
git rebase -i [startpoint] [endpoint]  # 和并多次提交并变基

git rebase -i合并多次提交

1.get reset 重置HEAD指针的指向

git reset 调整HEAD引用指向给定的提交，默认情况下会更新索引以匹配该提交。该命令的三个选项对应对HEAD、索引和工作目录的影响记录于下表。

git reset 命令将原来的HEAD存放在ORIG_HEAD 中。

|选项 | HEAD | 索引| 工作目录|
|–|–|–|–|–|
| git reset --soft | yes | no| no|
| git reset --mixed| yes | yes | no|
| git reset --hard | yes | yes| yes|

git reset HEAD --废弃最新提交的入库状态，可以重新编辑废弃提交中新加的文件，添加全新文件，产生新的添加哦。
git reset --soft --仅仅调整提交消息，You can, but you don’t it. 提倡用git commit --amend.
git reset --hard --完全废弃最新提交。改变工作目录，原有的未保存修改将丢失，新文件被删除 。

注意事项：如果将reset 命令应用在分支名上，会造成很多没必要的问题。

2.git cherry-pick

[有趣的程序员，挑樱桃呢]。

1. 转移一个提交：用于 将一个分支的 特定提交 引入 一个不同的分支中，常见用法是将 开发分支的提交 移植到 维护分支 上。

git checkout master              # 需要引入新提交的目标分支
git cherry-pick commit-id1       # 在master 分支上新建一个提交，提交的内容是 commit-id1相对于commit_id0的新增内容【commit_id0 是 commit-id1 的上一个提交】
# 可能伴随着解决冲突                # 没有冲突的话，就会直接复用原有的提交信息，直接在当前分支上产生一个新的提交

2. 转移一批提交：另一个常见用途 用于重建一系列提交， 即从一个提分支中选一批提交，然后把他们引入新的提交中。

git checkout master
git cherry-pick commit-id1..commit-id3

3.git revert

与git cherry-pick 命令作用相反：引用一个新的提交，消除给定提交的内容。（我想：git revert 无需解决冲突，但是如果某个提交基于需撤销的提交，撤销该提交后可能会出现问题）记得在提交日志中记录相关的撤销信息。

git revert commit_x

4.git commit --amend修改提交

当最新的提交 需要 小范围的修改，可以使用git commit --amend 补救一下最新提交。 （其实它可以修改任意提交，但是一般情况下不推荐），对于普通git commit --amend 会弹出编辑会话，可在里面修改提交信息。

5.git rebase 变基提交

每一个在编辑的准提交都是基于某个父亲提交进行的，可以改变准提交的基础，即使用rebase操作。
一个常见的用途是–保持你正在开发的一系列提交相对于另一个分支(master)的最新提交进行的。

git checkout topic  # 切换到topic分支, topic 分支是基于 master 分支的某个提交建立的
git rebase master   # 变基础操作， topic分支基于master分支的最新提交建立。
# 以上两个命令等价于
git rebase master topic

5.1 git rebase --onto

一条分支上的开发线 整个 移植到不同的分支上

git rebase --onto master maint^ feature      # feature分支基于maint^， 将feature 提交的基础变为master分支。

5.2rebase 产生冲突，解决冲突/终止变基

变基操作一次只迁移一个提交，从原始提提交迁移到新的提交基础。因此每个移动提交都可能产生冲突。

如果在rebase 的过程中发生了冲突，git 会自动挂起 rebase进程，当你手动解决冲突后，使用git rebase --continue命令恢复变基操作。

git rebase --continue命令提交解决冲突后的内容，继续处理需要变基的下一个提交。

git rebase --skip 命令可以跳过某些提交，以避免某些冲突。但是这是非常不提倡的，产生的问题可能会像滚雪球一样。

git rebase --abort 可以终止变基础操作，使版本库恢复到变基前的状态（后面半句是否需要配合其他命令）

5.3git rebase -i

重新排序、编辑、删除、把多个提交合并成一个、把一个提交分离成多个

git rebase -i master~3  # 会自动打开编辑器，编辑重新排序文件。
# 提交默认按照最老->最新的顺序排列， 每个提交都有前都有一个pick, 放在最前面的提交将最先被拾起应用到目标分支
# 修改提交顺序后，保存退出。
# squash 提交会合并的前一个提交中，（自动弹出）合并提交信息模版，是两个提交信息的简单合并

Git 将两个提交合并为一个

6. rebase Vs merge

把在branch1上的一系列提交rebase branch2的头部 与 合并两个分支 产生的效果是一致的，即在branch2 的新头是两个分支内容的组合。rebase 还是 merge 需要依据实际情况而言。具体技巧希望后续会说

要记住的重要概念：

1. 变基础操作会把提交重新线性化成新的提交。如果想要保留分支和合并结构需要使用

git rebase --preserve-merges master dev

2. 不可达的旧提交会消失
3. 如果有分支2基于 变基提交1，很有可能需要对2也进行相应的变基操作。