合并分支
可使用
一、使用 merge 合并
使用 merge 进行两个分支的合并。
# {合并到分支}
git merge origin
# 使用 ours 策略合并到当前分支
git merge -s ours origin/{合并到分支}
# 不自动提交合并
git merge --no-commit origin/{合并到分支}
# 将多天记录合并为一条
git merge --squash origin/{合并到分支}
1. 强制合并两个不相干的分子
git merge {branch name} --allow-unrelated-histories
通过 git merge master 命令来合并这些修改，然后再用 rebase 命令理顺其历史纪录。该命令需要一个参数，以说明要将活动分支上的最新修改纳入哪一个分支。
git rebase master
但如果 rebase 命令在执行过程中遇到冲突情况，该命令进程就会被打断，相关文件中也会出现冲突标志。需要先手动或通过合并工具对文件进行清理，并重新将它们添加到暂存区中。然后再执行 rebase 命令加 --continue 选项，从该点继续之前的进程。
git rebase --continue
也可以用--abort 选项取消这次的 rebase 命令，或者用--skip 选项跳过引起冲突的提交。这样该次提交就被直接忽略，其中的修改将不会出现在新分支上。
2. 解决冲突
git mergetool 命令用于合并冲突解决工具并解决冲突，通常在合并后使用：
git mergetool
查看冲突版本
git diff
3. 手动解决
在编辑器内进行解决是最好的办法。
4. 取消合并
git reset --merge
或：
git reset --hard HEAD
上述命令将还原到 git merge 之前。
如果想在中止或在它已经结束后放弃：
git reset --hard ORIG_HEAD
二、使用 git cherry-pick 精细合并
git cherry-pick 提交命令用于 选择性地将制定提交（ commit ）应用到当前分支 。它允许经其他分支的特定修改复制到当前的分支，而无需合并整个分支。
- 精确复制提交 ： 将其他分支的某个（或多个）提交的修改内容应用到当前分支
- 避免全分支合并 ： 只引用需要的改动，而非整个分支
常用于维护分支和的提交移植到开发版本：
# 应用单个提交
git cherry-pick <commit-hash>
# 应用多个（按提交顺序）
git cherry-pick <commit-hash1> <commit-hash2>
# 应用一个连续的提交范围（ A 到 B 的所有提交，不包括 A ）
git cherry-pick A..B
# 应用连续的提交（包括起点 A）
git cherry-pick A^..B
1. 常用选项
| 选项 | 说明 |
|---|---|
-n 、 --no-commit | 应用修改但不自动提交（可手动调整后再提交） |
-x | 在提交信息末尾添加 （ cherry picked form commit ... ） 公开分支慎用 |
-e 、 --edit | 允许修改提交信息 |
--abort | 终止操作并恢复到 cherry-pick 前的状态（解决冲突失败时） |
--continue | 解决冲突后继续操作 |
--skip | 跳过当前提交 |
若误合科不需要的提交，可通过 cherry-pick 重新应用正确的提交。
- 提交哈希变化 ：
cherry-pick会生成 新的提交 （哈希值改变），因为提交时间/作者可能不同 - 依赖关系 ： 若提交依赖其他未选择的提交，可能导致代码错误（需确保上下文一致）
- 重复提交风险 ： 避免在公共分支多次
cherry-pick同一提交（可用-x标记来源） - 冲突处理 ： 复杂改动可能引发冲入，需手动解决（类似合并冲突）
2. 冲突处理
当 cherry-pick 的提交与当前分支代码有冲突时，Git 会暂停操作并提示冲突文件。
-
- 打开冲突文件，找到
<<<<<<<、=======、>>>>>>>标记的冲突区域，手动修改代码
- 打开冲突文件，找到
-
- 添加解决后的文件到暂存区
git add <冲突文件名> -
- 继续完成
cherry-pick
git cherry-pick --continue - 继续完成
-
- （可选）放弃本次
cherry-pick（回到操作前状态）
git cherry-pick --abort - （可选）放弃本次
-
- （可选）退出但保留当前修改（不回滚）
git cherry-pick --quit
3. 用途
git cherry-pick 是精细化代码管理的利器，适用于：
- ✅ 夸分支移植特定修复/功能
- ✅ 避免不必要的合并
- ❌ 不适合大范围历史重写（优先用 rebase ）
- ❌ 频繁
cherry-pick可能导致历史混乱，特别是在多人协作的项目中
三、git revert
git revert 提交命令跟 git cherry-pick 提交命令大致是相同的，但有一个重要区别：它应用给定提交的逆过程。因此，此命令用于引入一个新提交来抵消给定提交的影响。
跟 git cherry-pick 命令一样， revert 命令不修改版本库的现存历史记录。相反它往历史记录中添加新提交。
git revert {}~{}
四、本地丢失提交记录后
不小心丢失历史记录（执行了 rm -rf .git），可通过下面的操作
1. 初始化仓库
初始化本地仓库并建立与远程仓库的链接
git init
git remote add origin [git@xxx]
2. 拉取远程仓库的最新记录
使用 fetch 拉取远程仓库的最新记录而不是使用 pull 直接合并
git fetch origin main
3. 创建临时分支并保存本地修改
先将本地的修改保存到一个临时的分支上，避免新的修改丢失
git add -A
git commit -m "暂存误删 .git 后的本地修改的"
git branch temp
4. 本地与远程历史对齐
切换到主分支，并将重置为主分支的历史
git checkout main # 切换到 main 分支，如果没有 main 分支，先创建： git checkout -b main
git reset --hard origin/main # 将本地 main 分支与远程分支一致
5. 合并临时分支
使用 merge 将临时分支上的修改合并到当前的分支上：
git merge temp --allow-unrelated-histories