问题是git commit --amend 引发的。 一条commit已经push到远端develop了,可是后来又在这条commit上进行了amend操做,致使这条commit的哈希码发生了变化。而且后续又在这条commit以后进行了N条commit操做。java
<Begin>git
大概的状况画了个简图,如图所示。下面的绿色就是最后相同的地方,红色的那条作的是相同的功能message是同样的,可是提完develop以后又改动了不少而后使用amend挤压了。xcode
这个时候比较头疼了,由于那条amend的commit里面是发生了太多改动,我采用的是能够避免冲突的方法,可是会改develop的commit树安全
git checkout develop git reset 2c4532 //上面97,98,99的改动会被放出来 git stash //先把这些改动存起来 git reset --hard 5d67bc //等因而把96彻底剔除了,代码回到了95的状态 git cherry-pick 8a6f7f //把那一条修改后的功能commit(96的feature)粘贴过来,这一步100%不会有冲突 git stash pop //把以前存起来的那些改动再放出来,这一步不能保证100%无冲突,但实际因为两个功能模块离得比较开,因此也没有发生冲突。 git add . git commit -m " " //把develop上面的97,98,99三条commit 挤压成了一条后commit git cherry-pick 86f6cc d34c7 2817f5 //这一步把feature分支的97,98,99三条commit粘贴过来,由于这三条基本是基于8a6f7f开发的,因此也没有发生冲突。 董铂然博客园
<End>spa
这样改完以后develop的commit树如上图所示(第97条就是把以前的97,98,99挤压成的1条),能够编译经过功能都能实现。 可是缺点是这时候须要强推develop了。3d
组里另外一我的提出的解决方案是code
<Begin>(图再贴一遍 省的往上翻)blog
git checkout feature //操做都在feature分支进行,不动develop的代码 git reset 5d67bc //把feature分支上“不科学”的commit 96,97,98,99 所有放出来 git stash //所有临时存起来 git rebase develop //快进一下,合入了全部develop的新代码 100%无冲突 git stash pop //把以前揉在一块儿的4条commit的代码一块儿放出来,这时候会有大量冲突。 git add . git commit -m "fix" //解决冲突后commit一下 //而后再把最后的一条commit merge入develop,最后的结果时develop以下
<End>开发
能够看出这种作法,不须要强制push develop的代码。理论上更加科学,可是中间须要解决大量的冲突。博客
过后检讨一下,以为两种方法其实各有优劣,若是组内成员很少,能够在你们的监督下 完成强推develop的操做。 由于解决了大量冲突可能会比 很是清晰了解差别后-f强推develop更容易出现错误。 固然若是是大型项目,几十人团队,而且远端都绑上了编译检查,和merge规则的项目也只能使用第二种方法了。
对于一个码农而言,比写出bug更恐怖的是把代码弄丢了或弄乱了。 对于这种问题也是有一种统一的解决方案
①.git reset --hard 哈希码 , 这条很是广泛,若是出现问题有点乱直接回到一个安全的commit
②.git reflog 对于有rebase或merge这种操做,第一条指令就用不了了,由于被污染的并不只仅是最后一条commit。 这时要用这个万能恢复指令,回到一个操做的哈希码。
③.可是前两种方法都是对于一些已经加入过git的代码进行恢复。 若是一些代码尚未commit 这时候弄丢了 那些指令就都帮不了你了。 这时候只能看IDE有没有local history了。(local history至关于IDE帮你实现了一个相似于git的功能)以前就有过一次第3种状况的经历,当时是把没commit的代码给reset了 使用localhistory得以恢复。好在如今iOS的xcode 和 Android的Android Studio都是有local history的,
若是上文说的问题有更好的解决方案,也欢迎一块儿讨论。