2017-10-04 53 views
0

我有很多小的提交的一個簡單的項目會引起問題。我想擺脫其中的一些。我現在正在測試這個測試項目。我有一個模擬遠程存儲庫的文件夾和兩個連接到它的其他文件夾,test1test2。這是遠程和本地資源庫的狀態之前,我做了什麼:卸下頂蓋承諾與其他本地資源庫

* 0000002C (HEAD -> master, origin/master, origin/HEAD) Small commmit 12 
* 0000002B Small commmit 11 
* 0000002A Small commmit 10 
* 00000029 Small commmit 09 
* 00000028 Small commmit 08 
* 00000027 Small commmit 07 
* 00000026 Small commmit 06 
* 00000020 Big commmit 02 
* 00000015 Small commmit 05 
* 00000014 Small commmit 04 
* 00000013 Small commmit 03 
* 00000012 Small commmit 02 
* 00000011 Small commmit 01 
* 00000010 Big commit 01 

我跑git reset --mixed擺脫對小情侶的承諾到第一個大單:

git checkout master 
git reset --mixed 00000020 
git add . 
git commit -m "New starting" 
git push --force origin master 

一切都OK 。力推後,遠程存儲庫已更新,我已經不再是那些小提交:

* 0000002D (HEAD -> master, origin/master, origin/HEAD) New starting 
* 00000020 Big commmit 02 
* 00000015 Small commmit 05 
* 00000014 Small commmit 04 
* 00000013 Small commmit 03 
* 00000012 Small commmit 02 
* 00000011 Small commmit 01 
* 00000010 Big commit 01 

在其他文件夾中,我拿來了更新,這是日誌:

* 0000002D (origin/master, origin/HEAD) New starting 
| * 0000002C (HEAD -> master) Small commmit 12 
| * 0000002B Small commmit 11 
| * 0000002A Small commmit 10 
| * 00000029 Small commmit 09 
| * 00000028 Small commmit 08 
| * 00000027 Small commmit 07 
| * 00000026 Small commmit 06 
|/ 
* 00000020 Big commmit 02 
* 00000015 Small commmit 05 
* 00000014 Small commmit 04 
* 00000013 Small commmit 03 
* 00000012 Small commmit 02 
* 00000011 Small commmit 01 
* 00000010 Big commit 01 

我不知道如何繼續。從我想要更新的另一個文件夾中有0000002D提交origin/master,並且在兩個不同的分支中有本地主文件。你認爲現在需要做什麼來使這個本地存儲庫與第一個文件夾處於相同的狀態?我試過git rebase,但失敗了。 git merge創建一個新的提交和合並本地masterorigin/master當然,這將是一個解決方案。

謝謝。

+1

這就是爲什麼你不應該強迫推。已經拉過你原來的改變的人基本上會被迷惑爲地獄 –

+0

我意識到這一點。我已經準備好這個測試來看看會發生什麼。我很高興我沒有在現場項目中做到這一點:p – Celdor

+1

這就是爲什麼你應該爲新開發創建獨立的分支,爲每一個新的開發項目創建更小的分支,並且基本上永遠不要在主分支上重寫歷史記錄多個團隊成員的工作。同時也是一個不錯的主意,只保留你親自在當地工作的「小小變化」,只有在你需要別人的幫助或完成時才推動 - 因爲那樣你就可以改寫你心中內容的局部變化,並且按照你想要的方式推送提交(或者只是合併/重新分配到共享分支)。 – LightCC

回答

2

如果你有信心,你的第二個資料庫沒有已經不在你的第一個庫的任何變化,在你的第二個庫運行此:

git fetch 
git checkout -B master origin/master 

這將強制重置您的本地版本的masterorigin/master相同。

對於這種情況,瞭解「the perils of rebasing」,或在您的情況下,復位是非常重要的。

總之,只要你變基或重置密碼,你重新寫你的提交歷史。認爲你正在編輯舊提交是直觀的,但實際上你正在從舊提交中獲取更改並從它們創建新的提交。

這意味着你更新你的第二個存儲庫之前,它仍然有所有原始的提交。當你更新它時,它只是簡單地添加到你創建的新提交中 - 在你的案例中,「新開始」,併合並所有內容。

+1

謝謝。我不知道結賬的選項-B。 – Celdor

+0

@Celdor它是我個人的最愛。請享用! :) –