1. head detach

git branch显示detach是一种特殊的状态，表明目前的HEAD指针指向一个具体的commit id而不是一个分支，是一种较危险状态，是一个临时的状态，一旦丢弃，似乎就不 好找回了。这个出现在repo download-topic时会出现这种detach的情况。

解决方法很暴力，就是从这个临时状态新建一个分支，然后换到这个新建的分支tmp上，此时head指针指向新建的tmp分支，临时的修改也在新建的tmp的分支上。

git branch tmp
git checkout tmp

然后，从tmp分支切换回正常分支dev，将tmp分支merge进入dev分支，如果出现conflict，处理之。最后删除tmp分支，happy ending！

git checkout dev
git merge tmp
git branch -d tmp

2. git cherry-pick

考虑下面这种情况，有一个稳定的master分支，在dev分支上进行新功能的开发。如果现在需要进行demo，希望展示dev分支上的一个功能，但是不希望将整个dev分支合并，只希望合并某个commit。此时可以使用git cherry-pick.

下面是在master上的Git log

下面是dev上的Git log

# 切换到master分支
git checkout master
git cherry-pick 10d307d1bbe56fc7047db47378bcacee102eec45

这样，就将dev上的特定commit合并进入了master，log如下图所示。当然，可能会出现conflict，需要手动solve。

3. rebase

rebase有几个典型的应用场景。

3.1 合并多次commit

某些代码管理网站中，一次的commit就会对应一条修改记录，这样如果在开发同一个功能时，进行了多次commit，就可以rebase进行commit的合并。

git rebase -i HEAD^3

HEAD^3表示合并当前三个的commit。执行完上一句命令后，会弹出选择界面，选择需要保留的commit前面写p(pick)，选择需要合并的commit前面写s(squash)。然后，又会弹出界面，将不需要的commets注释掉即可。

3.2 合并线上版本

基于master进行开发后，master很可能会有新的提交，如果之间merge则会出现关于merge的commit，显得commit历史并“不干净”。可以在提交前，rebase一下。

git rebase master