一次git事故的回顧和學習

此次回顧是針對之前在上海開發過程中，呂鵬提交的**被我覆蓋掉的事故。希望通過學習了解事故發生的原因，避免以後在工作中重蹈覆轍。

以下是我自己的理解，可能會有錯誤，大家及時指正。

a) 事件回顧：為了簡便描述，s代表我，l代表呂鵬。

i. l進行了數次提交。

ii.

s使用pull -merge進行拉取，出現了合併衝突。

iii.

s在解決合併衝突的過程中，發現l提交的修改出現了自己的待提交區，s以為這些**不需要重複提交，

就對這些修改進行了discard

，然後進行了push。

iv.

l在使用pull -rebase拉取**以後，發現自己的修改被覆蓋掉了。

b) 原因

分析：

i. git主要有三個區域，工作區，暫存區，本地倉庫。三者的關係就不詳細說了。

ii.

git merge 和 rebase的區別。merge是git將本地的修改和遠端倉庫的修改做了乙個合併，更新到本地倉庫，是基於本地樹；rebase是先將本地的提交刪除，以遠端倉庫的修改作為基礎，將本地修改作用在上面，是基於遠端樹。

iii.

git pull 和 git fetch的區別。在本地存在著每乙個分支對應遠端倉庫的指標(以t指代)，裡面儲存了最後一次的commit id。這個指標可以理解為遠端倉庫的映象。本地倉庫(l)和遠端倉庫(r)在技術實現上是沒有交集的，兩者是通過t這個橋梁實現的。

雖然從結果上看，git pull = git fetch + git merge，實際上，git pull會將本地庫l更新至遠端庫r的最新狀態，而l中的commit id並沒有發生變化。

iv.

在s使用了預設的pull merge以後，由於合併衝突，實際上合併中斷了，此時工作區和本地倉庫的樹是存在差異的。s將l提交的修改在本地discard以後，push到t的樹就忽略了這些修改，在push到遠端倉庫r中時，git就認為這些類是被刪掉了，因此之前的修改就被覆蓋掉了。

c) 通過這次回顧和學習，大致了解了git的內部工作原理。建議以後的工作，盡量使用git bash進行操作，先執行git fetch檢視有哪些修改，再執行git rebase。如果使用smartgit的話，將git pull的模式改為預設 rebase

。避免同樣的事故再次發生。