點擊上方“前端教程”，選擇“星標”

每天前端開發干貨第一時間送達！

作者：echozh

juejin.im/post/5d5b4c6951882569eb570958

前置條件：

在正式開始之前，我們需要先確定幾個概念。下面所提到的 master 分支默認為代碼提交的主分支。

本地分支和遠程分支

本地分支是指我們在日常開發中自己通過?git checkout branch xxx?建立的分支，遠程分支是我們經過?git push -u origin xxxx?推到 git 服務器的分支，在我們推送之后，git 會幫我們在本地建立一個以?orgin/?開頭的分支，這個我們也叫遠程分支。

我們日常操作的就是本地分支 xxx 和遠程分支?origin/xxx，origin/xxx?就是遠程的 git 服務器在我們本地建立的一個分支的對照版本(我覺得這樣說應該比較容易理解)，我們日常的?git fetch --all?就是將本地的 origin/xxx 與 git 服務器的 origin/xxx 分支進行同步。

commit id

我們每次提交代碼都會根據本次提交的內容生成一個幾乎唯一的 id ，這個 id 重復的概率幾乎為 0，我們可以這樣理解，我們每次的提交都會生成一個唯一索引的記錄，不管是本地的 git，還是遠程的 git ，我們都將她理解為一個數據庫，只要我們進行了 commit 操作，那么可以幾乎確定，我們的代碼是不會丟失的，我們都可以通過 commit id 找到那條提交記錄的內容。

本篇文章不會講解，分支與分支之間的版本比較等內容，作者比較菜，怕掌握不好度翻車。

使用指南

創建分支

創建分支我們可以使用?git checkout branch xxx?來創建一個新分支，這個很容易理解，但是如果我們現在在分支 branch-1，但是我們想新建一個基于遠程 master 最新版本的分支，我們該怎么辦呢，不能說現在我回到 master，然后?git pull?拉取最新的 master 分支代碼，然后創建分支，很繁瑣對不對。

這里我們就可以進行里一個操作了：git fetch --all?記得我們上面提到的吧，同步遠程分支代碼，?--all?可以改成?origin/master?，然后進行?git checkout branch xxx origin/master?后面的?origin/master?代表我們是基于遠程分支 origin/master 進行創建的。

追加提交記錄

比如我現在已經在本地 commit 一次了，但是發現還有東西忘改了，如果我在 commit 一次就會生成兩條記錄，這樣從提交記錄上看可能不太好看，然后我們就可以使用?git commit --amend對上一次的提交記錄進行追加。

這個操作的前提是上一次提交必需沒有推送到遠程分支，否則，你會發現操作之后在進行?git push?會提示你版本不一致不允許提交，當然如果你可以保證提交沒有錯誤，且這一個分支只有你自己一個人玩，那你就可以使用?git push -f?進行強制提交了，這個操作很危險，謹慎使用。

merge 還是 rebase

我比較喜歡 rebase 操作，所以在這里就只會講解 rebase 操作了。rebase 的使用場景。

使用場景 1：

比如現在你在 branch-a 分支工作，但是這個任務有點困難，你已經在這個分支工作很長時間了，很長時間都沒有同步 master 分支的代碼了，然后同組的小伙伴合并了一個新功能這個功能你需要使用，這個時候你就可以在當前分支使用?git rebase origin/master?了，這個操作會將你在這個分支的提交附加于最新的 master 分支版本之后，很明顯這個操作之后你當前本地的 branch-a 和遠程的?origin/branch-a?已經不一樣了，所以有一個缺點就是你只能選擇?git push -f?進行提交。

使用場景 2：

你同組的小伙伴修改了你在 branch-a 分支也修改過的代碼，并且你的小伙伴已經提交了，這個時候，你的 branch-a 分支就會和?origin/master?分支有沖突，嗯，這個時候你也可以使用?git rebase origin/master?這個操作來解決沖突，并同步最新的 master 的代碼。

使用場景 3：

你和小伙伴共同在 branch-a 分支提交代碼，結果小伙伴比你先提交了，這個時候你再提交會發現版本不一致無法提交，這個時候我們就推薦使用?git pull --rebase，其實?git pull?命令后面是有一個默認參數的那就是 --merge，會給我們剛接觸 git 的同學造成很多麻煩。所以在這?git pull --rebase?是一個不錯的選擇。

rebase 的另外一個騷操作：合并 commit

git rebase -i HEAD~X x?代表從當前的提交記錄往回回溯的提交記錄的個數，執行這個操作之后我們就可以看到一個這樣的交互界面：

上面我的 x 是 5，所以在這會有 5 個記錄，接下來我們需要以一個記錄為目標，將其他的記錄全都合并到目標記錄：

我們將其他的 pick 改為 s，s 是指 squash，下面截圖的下面會有相應的解釋，然后我們只需要保存退出即可，接下來會跳出一個?commit message?填寫的界面：

這個界面是讓我為新的提交記錄填寫新的?commit message，這個可自行發揮，然后還是保存退出即可。然后我們使用?git log?就可以看到一個新的提交記錄：

git cherry-pick

我們可能會有這樣一個使用場景，在分支 branch-a 需要分支 branch-b 的某次提交，這個時候我們就可以先找到 branch-b 的那次提交記錄的 id，然后在 branch-a 分支進行?git cherry-pick b-commit-id?將 branch-b 分支的提交記錄拿過來了

那如果我們只需要 branch-b 分支的某個文件呢該怎么辦呢，莫慌再交你一個操作，git checkout xxx file?這個操作可以將其他分支的文件拉取到當前分支，注意這個操作是覆蓋式的，也就是如果你這個分支的這個文件已將存在，那么這個操作將會覆蓋你當前分支的這個文件。可以發揮一下 xxx 也可以是遠程分支。

git checkout branch -- file

那么這個操作又是干嘛的呢，這個操作可以將你的某個文件還原到某個分支的版本。如果某次你手誤提交了錯誤的文件，但是改動又忘了，那么這個命令或許可以幫到你。

git prune

根據官方的解釋，直白一點的翻譯就是刪除 git 數據庫中不可訪問的對象，那我的理解是這樣的，git prune?刪除的是你本地 .git 下的 object 目錄下，沒有被使用到的 hash 值，我理解的是它會刪除 origin/xx 開頭的沒有用到的分支，這個分支在你的遠程的 git 服務器中已經刪除但是本地任然存在 origin/xxx 的映射，這個時候你就可以使用?git prune?來刪除本地的 origin/xxx 的映射。

但是官方推薦使用的是 git gc，而想刪除本地的 xxx 分支，就只能只用?git branch -D XXX，在這附上一條我們部門自己寫的一個清除本地無用分支的?shell git fetch --all --prune && git branch -vv | grep gone | awk '{ print $1 }' | grep -v pit | xargs git branch -D。

git stash

git stash?可以幫助我們來暫存一些更改，我推薦的是如果只是少部分的更改，使用 stash 是可以的，多了的話，推薦新建分支來保存更改，以免自己忘記了哪個 stash。那我們該如何取出這些更改呢，最常用的就是?git stash pop?它會將你最新一次的 stash 從一個緩存數組里面推出來，這樣的話如果我們操作不當很可能就丟失了這些更改。

我推薦的是使用?git stash apply，這個會將你最新一次的 stash 從緩存數組里面 copy 一個副本返還給你，缺點就是，你本地的 stash 數組會越來越大，當然，你可以定時清空一下。還有一個場景，如果我想取出指定的 stash 該怎么辦呢，在這我們可以使用 git stash list 來查看一下自己本地的 stash 記錄的形式：

我圈出來的就是每次 stash 的類似于 id 的一個東西，后面會顯示是在什么分支 stash 的，所以現在我們就可以使用?git stash pop/apply stashid?來取出指定的 stash。

后記

目前覺得這些在日常工作中使用的比較多，還有一個 patch 沒說，因為用得比較少，如果再想到其他的內容我會在這篇文章上進行修改。如果本文有錯誤的地方還請大家可以指正，謝謝。

覺得本文對你有幫助？請分享給更多人

關注「前端教程」，一起提升前端技能！

好文章，我在看?? 《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的git stash pop冲突_这有一份 git 日常使用清单，你需要吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。