/*
* merge rebase 与 cherry-pick 区别
*/
cherry-pick 用于将另一个分支的某一次或几次commit应用到当前分支。它可以选择性地拉取代码修改。
merge 用于将两个分支合并成一个新分支。它会把整个分支上的所有修改都合并过来。
具体区别:
cherry-pick 通常用于将bug修复从发布分支应用到开发分支。只合并特定的commit,不会包含目标分支的所有修改。
merge 用于合并功能分支到主分支。它把一个完整功能分支的所有修改都合并过去。
cherry-pick 保留原commit的SHA值和注释等信息,merge则会生成新的commit信息。
merge 可能需要处理代码冲突,cherry-pick如果存在冲突需要手动解决。
merge 合并整个分支历史,cherry-pick只应用指定commit而不包含历史。
总之,当需要应用另一个分支的部分修改时用cherry-pick,需要合并整个分支时用merge。它们侧重的场景不同。
cherry-pick、merge和rebase都是用于合并更改的工具，但它们各自适用于不同的场景。
选择哪一种取决于具体需求、团队工作流程以及想要的提交历史的形态。
git cherry-pick 适用场景：
当只想将某个分支上的一个或几个特定提交应用到当前分支时，而不是整个分支的更改。
在处理较大的代码库或多个项目时，如果需要将一个修复或功能从一个分支移植到另一个分支。
优点：
可以精确选择哪些提交应用到当前分支。
不会改变目标分支的历史。
缺点：
如果频繁使用，可能会导致提交历史混乱。
需要手动解决每个cherry-pick操作中的冲突。
git merge 适用场景：
当想要将两个分支的历史合并在一起时，特别是在功能开发完成后将功能分支合并回主分支。
优点：
保留了分支的完整历史和合并点，易于跟踪特性的合并。
自动合并没有冲突的更改。
缺点：
可能会产生复杂的提交历史图，尤其是在频繁合并的项目中。
git rebase 适用场景：
当想要在合并前将一个分支的更改"移植"到另一个分支的基础上，通常用于保持线性的提交历史。
在准备将本地更改合并到共享分支之前，将共享分支的最新更改应用到本地分支。
优点：
创建一个更干净、线性的提交历史。
可以在合并之前解决冲突，使最终合并更加简洁经常需要将多人的工作合并到一个共享分支。
缺点：
改变了分支的提交历史，对于共享分支使用时需要小心，可能会导致团队成员之间的混乱。
需要解决在rebase过程中出现的冲突。
总结
如果需要合并整个分支的更改，通常使用git merge。
如果需要保持提交历史的清晰和线性，或者在合并之前更新分支，使用git rebase。
如果只需要从另一个分支拾取某些特定的提交，使用git cherry-pick。