1.找到原分支的hash值

在原分支下面执行
git log --oneline
b35b237c9f4

2.在新分支上执行

git cherry-pick b35b237c9f4

error: could not apply b35b237c9f4… 修复缺陷
hint: After resolving the conflicts, mark them with
hint: “git add/rm ”, then run
hint: “git cherry-pick --continue”.
hint: You can instead skip this commit with “git cherry-pick --skip”.
hint: To abort and get back to the state before “git cherry-pick”,
hint: run “git cherry-pick --abort”.
hint: Disable this message with “git config set advice.mergeConflict false”
warning: Cannot merge binary files

绝大多数情况下，如果两个分支都对同一个二进制文件（如 .apk、.jar、.png 等）进行过修改，cherry-pick 或 merge 时注定会发生冲突。
为什么二进制文件注定会冲突？
Git 是一个基于文本行的版本控制系统。对于代码等文本文件，Git 可以对比行与行的差异并尝试自动合并。
但是对于 APK 这样的二进制文件：
Git 无法读取其内部结构，也无法进行“按行合并”。
只要目标分支（你当前所在的物理分支）和源分支（你提取 commit 的分支）上的这个 APK 文件自它们分叉以来都发生过任何改动，Git 就无法判断应该保留哪一个，因此一定会报 Cannot merge binary files（无法合并二进制文件）并产生冲突。

如何快速解决这个冲突？
由于是二进制文件，你无法像普通文本文件那样打开它去手动修改冲突标记（<<<<<<< 等）。你只能做“二选一”的抉择：
保留当前分支的版本（–ours）
采用你正在 cherry-pick 的那个提交里的新版本（–theirs）
既然你的提交注释是“修复一些缺陷”，你通常是需要使用 cherry-pick 带来的新 APK 覆盖旧 APK。
你可以按照以下步骤解决：

1. 采用 cherry-pick 提交中的新 APK 文件（推荐）
   在冲突状态下，运行以下命令，直接使用“对方”（即你要 cherry-pick 的提交 b35b237c9f4）的 APK 文件：
   git checkout --theirs 1.apk

2. 将该文件标记为已解决（暂存）
   git add 1.apk

3. 继续完成 cherry-pick

git cherry-pick --continue

此时会弹出编辑器让你确认提交信息，保存并退出即可顺利完成同步.

Linux 终端中默认的 nano 编辑器。你可以通过以下步骤保存并退出：
快捷方式（最推荐，一步到位）：
按键盘上的 Ctrl + X（退出）。
此时屏幕最下方会询问：Save modified buffer?，按键盘上的 Y 键（表示 Yes 确认保存）。
接着屏幕会显示文件名 .git/COMMIT_EDITMSG，直接按 Enter（回车键） 确认。
此时编辑器就会自动保存并关闭，Git 也会继续完成 cherry-pick 提交。

常规方式（分步操作）：
按 Ctrl + O（写入/保存，即底部菜单的 ^O Write Out）。
按 Enter（回车键） 确认文件名。
按 Ctrl + X（退出，即底部菜单的 ^X Exit）。
(注：底部菜单中的 ^ 符号代表键盘上的 Ctrl 键。)

为什么还需要 git push？
所有的操作目前只在“本地”：
你刚才做的 git cherry-pick、解决冲突、以及在 nano 编辑器里保存并退出，这些操作全部都只发生在你的本地电脑上（你的本地 master 分支）。
远程仓库还没有更新：

git push origin HEAD:refs/for/master