這篇文章主要介紹了Git常用場景使用,本文給大家介紹的非常詳細，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下。
1. 本地存在多個commit：
【場景】代碼和遠程倉庫一致，本地修改后，存在多次本地commit，直接push最新的提交，push成功，但本地多次commit記錄也會記錄到遠程倉庫中
【舉例】第一次提交：添加File1文件，文件內(nèi)容666666
第二次提交： 添加File2文件，文件內(nèi)容888888，修改File1內(nèi)容
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后相當(dāng)于先拉取代碼再提交，所以直接push成功)
【舉例】添加一個File3，并修改File1，提交前手動修改遠程倉庫代碼(模擬別人提交修改了遠程倉庫代碼)，遠程倉庫代碼被修改后，本地push需要手動解決沖突。
【操作】4-a. (版本回退后)添加File3，修改File1
4-b. 修改遠程倉庫代碼
4-c. 本地push代碼，提示沖突，選擇Merge后手動解決沖突
Accept Yours: 該文件選擇你的版本合并到遠端
Accept Theirs: 該文件選擇遠端的版本，即放棄該文件的修改
Merge ：對比本地和遠端的差異，手動解決沖突，一般都Merge
左邊是本地的修改，右邊是遠端的代碼，中間是最終推送遠端
看情況對比修改
修改確認后可能會出現(xiàn)push被拒絕，再重新提交一次就好了。
【建議】本地先拉取代碼，如果沖突手動解決沖突，然后再push
【注意】沒有commit就拉取代碼，并且Accept Theris，可能會把本地修改過的代碼覆蓋掉，導(dǎo)致修改的代碼丟失，注意備份。
-------------------------------------------------想到別的場景后續(xù)再補充------------------------------------------------------------
總結(jié)
到此這篇關(guān)于Git常用場景使用的文章就介紹到這了,更多相關(guān)Git常用場景使用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
文章轉(zhuǎn)自腳本之家，原文鏈接：https://www.jb51.net/article/193000.htm
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
