项目实训进度记录【4.11灾难】

是的，我们的后端发生了灾难，它分叉了，它回不来了。

起因是一位在自己本地耕耘了很久的队友突然要push上去，然后由于本地和远端冲突，git让她解决冲突，她误操作导致远端仓库把她辛勤耕耘的代码给覆盖了。她很着急，然后一通操作猛如虎，把自己本地代码从git history中找回来了，这次她吸取了教训，于是在处理冲突的时候把远端仓库给覆盖了。于是我开始找回被埋葬的远端仓库，但我也不是很会git，在我小心翼翼的操作下，我们的git越来越乱，直到最后无法收拾，只好请求场外支援。

师哥说，应该给每个人建一个分支，每个人先在自己的分支上耕耘，做好一个小项目就commit&push到自己的远端分支上去，这样每个人的代码万一被覆盖了，可以很快地找回。然后再进入dev分支，把自己分支上的修改merge到dev分支上面来，再把dev分支变化push到远端。应该有一个项目的大boss负责审核dev分支上的更新，审核通过之后再merge到master上面去。

师哥忙了一早上帮我们解决分叉。我已经不太记得他尝试了哪些方法了，但结果是，全部失败。师哥又请了另一位场外支援，第二位师哥提出了和第一位师哥相同的方法，第一位师哥说，对，我也是这么想的，你来，你试试。第二位师哥一通操作猛如虎，也失败了。最后，两位师哥的一致结论是，重新建库吧，这个库没救了。

于是我重新建库，并且用智能工人的方式合并两个分叉的代码。合并好了之后给push到master上面。

以防灾难再次发生，我整理出每次开发前后需要执行的git命令，发给组员。并且晚上我逐一为组员在本地和远端创建自己的分支。并且，我吸取了后端的教训，因此趁着前端还没有发生灾难，我也逐一为组员创建了自己的前端仓库的本地和远端分支。

#每次开发的操作：
git branch #确定自己在master下
git pull
git checkout <myname>
git merge master
进行开发
git add . #（不能直接commit，否则报错）
git commit -m “提交说明”
git push
git checkout master
git pull
git merge <myname>
解决可能的冲突
git push

其实这个灾难的根源并不是解决冲突的误操作，一个多月没有update的本地和远端的冲突不是人力可以解决的。这场灾难在一个多月前就已埋下了祸根。所以我后来和队友们强调了很多很多遍，写代码前先update，写一个小功能就commit（前提是不报错）。