接Git分支合并冲突解决，在使用rebase合并冲突情况下，如果不小心，执行完add后执行了commit，此时本地仓库HEAD处于游离态（即HEAD指向未知的分支），如何解决？

解决方法

（1）此时，分支处于 无分支 状态，创建并切换到新分支（git checkout -b conflict），从而解决HEAD游离状态；

（2）放弃此次rebase操作（git rebase --abort）；

（3）在dev分支上merge新分支，出现冲突（git merge conflict）；

（4）冲突修改后提交；

（5）删除新分支，合并到远程仓库。

以上篇文章项目为例

（1）git1在index.html文件中添加“add 2 by git1”，并提交

　　

　　分支树如下：

　　

　　

（2）git2同时在index.html文件中添加“add 2 by git2”，并提交

　　

　　分支树如下：

　　

　　

（3）git2从远程仓库fetch最新文件，此时状态如下，dev和origin/dev在不同的分支上

　　

　　

　　执行rebase，发生冲突（之前所有操作都是在dev分支）

　　

　　冲突后，分支切换到dev|REBASE 1/1，其中1/1表示有一个提交的冲突。git status可以看到dev分支基于origin/dev的最新提交dc6c350进行rebase。

　　

　　查看分支，发现当前分支为 (no branch, rebasing dev)

　　

　　分支树如下，与origin/dev相同：

　　

　　

（4）为验证HEAD游离态，git2解决完冲突后，执行提交

　　

　　

（5）此时，HEAD已处于游离状态，分支为  无分支 ，

• 创建并切换新分支conflict，解决游离问题

　　

　　

• 丢弃本次rebase操作，分支切回dev

　　

　　此时dev分支任然为rebase之前的状态，如下：

　　

• dev分支merge合并conflict分支（该分支解决已之前的冲突），但由于dev保持原貌，合并依然会发生冲突

　　

　　由于发生冲突，此时分支切换到 dev |MWEGING 。index.html文件如下，说明冲突的在“add 2 by git1”行

　　

• 解决冲突，然后提交，此时自动切换到dev分支

　　

　　分支树如下，可以看到HEAD指向了dev最新提交，origin/dev与远程仓库一致，conflict分支指向原来冲突修改的分支：

　　

　　

• 删除conflict分支

　　

　　提交到远程仓库，分支树如下：

　　

　　

总结

• 解决HEAD指针游离态，并将修改合并到开发分支。
• rebase除了 --continue外，还有 --skip 和 --abort 操作，其中skip会忽略自己的提交，而更新为远程仓库版本；abort会放弃本次合并操作，回到rebase之前的状态。
• git reset HEAD <file> ，该命令将文件从暂存区退回到工作区