接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> ，该命令将文件从暂存区退回到工作区