1. 程式人生 > 程式設計 >Git常用場景使用方法

Git常用場景使用方法

1. 本地存在多個commit:

【場景】程式碼和遠端倉庫一致,本地修改後,存在多次本地commit,直接push最新的提交,push成功,但本地多次commit記錄也會記錄到遠端倉庫中
【舉例】第一次提交:新增File1檔案,檔案內容666666
第二次提交: 新增File2檔案,檔案內容888888,修改File1內容

在這裡插入圖片描述在這裡插入圖片描述

2. 遠端倉庫程式碼回退:

先本地版本回退:git reset commitid
本地回退版本強推遠端倉庫:git push -f

3. rebase操作:

【場景】程式碼和遠端倉庫一致,本地修改後存在多次本地commit,本地多次提交的程式碼沒有衝突,rebase合併本地多次commit

【舉例】如1中例子,第二次提交為最新提交,希望只保留第二次提交
【操作】3-1. git rebase -i commitid

在這裡插入圖片描述

3-2. 之後會進入類似vim的編輯器(i插入修改,修改完:wq儲存)
pick:表示需要提交的commit記錄|squash:表示合併到前一個commit
reword:使用本次提交,但修改commit資訊

在這裡插入圖片描述

3-3. 之後會進入提交資訊編輯頁,修改儲存,rebase完畢,合併成功

在這裡插入圖片描述在這裡插入圖片描述

【注意】 命令中commitid是兩次提交的前一個commitid
第一個pick不可修改,可以將後面的squash
如果頁面顯示noop,就是你的commitid選的是最新提交的commit,這樣是不對的

4. push衝突

【場景】本地commit了,但在push之前,遠端程式碼被別人修改過了,程式碼衝突的情況處理
【舉例】新增一個File3,提交前手動修改遠端倉庫程式碼(模擬別人提交修改了遠端倉庫程式碼),遠端倉庫程式碼被修改後,本地push
【操作】4-1. 新增File3

在這裡插入圖片描述

4-2. 修改遠端倉庫程式碼

在這裡插入圖片描述

4-3. 本地push程式碼,提示衝突,選擇Merge,直接push成功

在這裡插入圖片描述

4-4 . Merge後推送到遠端有兩條commit(因為這次push只修改了File3,並沒有修改File1,Merge後相當於先拉取程式碼再提交,所以直接push成功)

在這裡插入圖片描述

【舉例】新增一個File3,並修改File1,提交前手動修改遠端倉庫程式碼(模擬別人提交修改了遠端倉庫程式碼),遠端倉庫程式碼被修改後,本地push需要手動解決衝突。

【操作】4-a. (版本回退後)新增File3,修改File1

在這裡插入圖片描述

4-b. 修改遠端倉庫程式碼

在這裡插入圖片描述

4-c. 本地push程式碼,提示衝突,選擇Merge後手動解決衝突
Accept Yours: 該檔案選擇你的版本合併到遠端
Accept Theirs: 該檔案選擇遠端的版本,即放棄該檔案的修改
Merge :對比本地和遠端的差異,手動解決衝突,一般都Merge

在這裡插入圖片描述

左邊是本地的修改,右邊是遠端的程式碼,中間是最終推送遠端

在這裡插入圖片描述

看情況對比修改

在這裡插入圖片描述

修改確認後可能會出現push被拒絕,再重新提交一次就好了。

在這裡插入圖片描述

在這裡插入圖片描述

【建議】本地先拉取程式碼,如果衝突手動解決衝突,然後再push

【注意】沒有commit就拉取程式碼,並且Accept Theris,可能會把本地修改過的程式碼覆蓋掉,導致修改的程式碼丟失,注意備份。
-------------------------------------------------想到別的場景後續再補充------------------------------------------------------------

總結

到此這篇關於Git常用場景使用的文章就介紹到這了,更多相關Git常用場景使用內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們!