溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細介紹“Git使用方法有哪些”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Git使用方法有哪些”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。
遠程倉庫區：也就是我們代碼最終提交的歸宿，沒啥好說的。
遠端分支本地副本：這個其實主要儲存了遠程倉庫各分支數據在本地的一個副本，你可以打開你 Git 項目下的 .git 文件，里面有個 refs/remotes，這里就主要存的就是遠程倉庫的分支信息，一般你執行 push 或者 pull、fetch 都會往這里進行更新。
本地分支：這里就是我們經常會打交道的區域，你在執行 commit 之后，本質上就是提交到了這個區域，你可以查看你的 .git 目錄下的 refs/heads 目錄，里面存的就是我們本地的分支代碼信息。
暫存區：這個區域就是我們每次執行 git add 之后會存到的區域，用來與本地倉庫之間做一個緩存，同時也是 Git 底層設計上來說也算是比較重要的一個區域，它能幫助 Git 在做 diff 的時候提高查找性能。
工作區：這個一般就是我們寫代碼的地方，比如你的 vscode 打開的項目，你可以進行代碼編輯的地方。
除此之外，還有一個特殊的區域，那就是本地的 git 儲存區，它是用來干嘛的呢？一般來說你可能在某些場景下會用到它，我們有的時候本地改了代碼，但是突然有個人過來問你另一個分支的問題，同時這個時候你在實現某個功能，實現一半，又不想提交到 Git 倉庫中，那么你就可以考慮使用 git stash save "臨時存一下"，這個時候它就會幫你存到這個儲存區，你去其他分支做完事情回來，再 git stash pop就好了。
日常工作中，我們可能在 Git 使用上頻繁交互的流程大致會是這樣的（不同規范下會有一些區別，但是大差不大）：
來了一個新需求，我們會從 master checkout 一個新的 feature 分支出來進行開發。
開發完某個功能點，我們會執行 git add 將代碼提交到暫存區。
執行 git commit 將代碼提交到本地倉庫
執行 git push 將代碼提交到遠端分支
當我們開發完所有需求之后，可能會設立一個專門的測試分支比如名叫 dev 的分支，那么我們就把代碼合并到這個測試分支上，發布測試環境進行測試。
測試完畢之后，我們就需要合代碼了，這個時候，我們可以發起一個 merge request，將我們的代碼走 CR 流程合并到 master 分支。
在提交 MR 的過程中，我們一般需要先自己預先將 master 分支的代碼合并到當前需要被合并的分支，提交并解決沖突。
以上流程大致概括了一般常規的 Git flow 流程，不同的公司可能會設計自己的規范，這里就不過多指示了。
git stash
git clone
git init
git remote
git branch
git checkout
git add
git commit
git rm
git push
git pull
git fetch
git merge
git log
git reset
git reflog
git revert
git cherry-pick
git tag
git rebase
乍一看，眼花繚亂，當場決定放棄，還是用可視化工具吧。莫慌，且讓筆者為你娓娓道來。
一般來說，我們本地如果想要使用 Git 管理一些資源文件，首先我們需要有一個倉庫才行。常用的方式莫過于，第一去 Gitlab / Github 先創建一個倉庫，然后再拉到本地，那這個時候我們就可以用到我們的 clone 命令了。
上面也有初步介紹這個命令的用法，就是用來臨時存一下不想被提交的代碼變更的，常用命令如下：
git stash save 'xxx': 儲存變更
git stash list: 查看儲存區所有提交列表
git stash pop: 彈出并應用最近的一次儲存區的代碼提交
git stash drop stash@{n}: 刪除某次儲存記錄
git stash clear: 清楚所有 stash 信息
它的數據將被存在你倉庫 .git 文件下的 refs/stash 里。
最基礎也是最常用的用法莫過于直接使用
git clone xxx.git
這樣就能輕松把一個倉庫代碼拉到本地了，但僅僅知道這一點似乎還不太夠。一般我們直接 clone 下來不帶參數的話，它會默認停留在 master 分支，有的時候我們依舊需要一些其他訴求，比如怎么拉到本地之后自動切到指定分支呢？
git clone xxx.git -b branch2
有了倉庫之后，我們總不能一直在 master 分支搞事吧，一般是不是都需要開個新分支改代碼，再最后完事了再合到 master，那就需要用到下面介紹 git branch 命令了，不過呢，在講到具體的分支操作之前呢，筆者還是要先補一下有關于本地倉庫的初始化的流程。
除了我們從遠端建倉庫，有的時候我們自己本地也是可以自己初始化一個 Git 倉庫來操作的，這個時候我們就直接使用 git init 就能輕松為當前目錄創建一個 git 倉庫，也就能開始對當前目錄的改動納入版本管理庫了。
不過本地 init 的倉庫沒法和遠端進行交互，所以我們還是需要去 github/gitlab 創建一個遠端倉庫，然后關聯一下，也就是 git remote 命令了。
用于和遠程倉庫進行關系綁定處理等等操作。
git remote add: 添加一個遠程版本庫關聯
git remote rm: 刪除某個遠程版本庫關聯
比如我們本地有個初始化好的倉庫，同時還有一個創建好的遠程空倉庫，那么我們就可以執行一下操作讓他們關聯起來：
git remote add origin xxx.git先添加到本地倉庫
git push -u origin master：表示把當前倉庫的 master 分支和遠端倉庫的 master 分支關聯起來，后面我們執行 push 或者 pull 都可以非常方便的進行操作了。
在拿到一個項目之后，你首先還是應該看一下當前倉庫現在有哪些分支，不要待會創建新分支發現名字重復之類的問題，那這個時候我們就可以使用 git branch 來查看一下相關的分支了。
git branch：查看本地所有分支信息
git branch -r：查看遠程倉庫所有分支
git branch -a：查看本地和遠程倉庫所有分支
一般來說如果分支太多的話，還是建議使用可視化工具來查看分支信息，比如 vscode 或者 source tree 等軟件等等。
當然 IDEA 也是可以的。
如果我們想以當前分支為基準，創建一個新的分支并切換過去，可以使用如下命令。
創建并切換到指定新分支：git checkout -b branch2
我們在某個分支更改了代碼之后，想要把它提交一下，那么你第一步要做的就是，執行 git add
git add [file1] [file2]: 添加一個或多個文件到暫存區
一般我們平時在使用的時候，用的比較多的應該還是：
git add .：把當前目錄下得所有文件改動都添加到暫存區
git add -A：把當前倉庫內所有文件改動都添加到暫存區
對筆者來說，用的最多的還是這個 git add -A 命令，因為大多數情況，我們都應該把所有變更都加到暫存區里，如果沒有，那大概率是忘了。
文件添加到暫存區之后，我們就可以執行下一步操作了。
git commit [file1] ... -m [message]：將暫存區的內容提交到本地 git 版本倉庫中
-m 表示的是當前提交的信息
-a 對于已經被納入 git 管理的文件（該文件你之前提交過 commit），那么這個命令就相當于幫你執行了上述 git add -A，你就不用再 add 一下了；對于未被 git 管理過的（也就是新增的文件），那么還是需要你先執行一下 git add -A，才能正確被 commit 到本地 git 庫。
通常情況下，我們用的比較多得應該是 git commit -m 'feat: do something'，設置當前提交的信息。當然，如果你沒有強訴求需要 git add 和 git commit 一定要分開，那你大可選擇 git commit -am，方便又快捷。
這個其實也挺有用的，比如我們項目中有個文件叫 .env，這個文件是一個私有的，不能被提交到遠程的，但是我們不小心提交到了本地倉庫中，這個時候我們把這個文件添加到 .gitignore 文件中，表示需要被 git 忽略提交，但是由于我們已經提交到本地倉庫了，所以如果不先從 git 倉庫刪除是沒用的。
如果直接右鍵刪除，那么這個文件的記錄還是會被保存到遠端倉庫，別人還是能看得到你這個信息，所以我們需要先從 git 倉庫中刪掉這個文件才行。
git rm .env：執行完這個命令就表示 .env 文件從 git 倉庫中刪除了，配合 .gitignore 就能保證以后所有的 .env 文件變更都不用擔心被提交到遠程倉庫。
git rm -r dist：如果我們要刪除的是一個目錄，那么加上 -r 參數就好了。
接下來我們想要把剛創建好得分支推送到遠端，一般來說我們可能會需要用到 git push，但我們這是個新分支，根本沒和遠端倉庫建立任何聯系，那么我們就需要加點參數，讓他們關聯上：
推送分支并建立關聯關系：git push --set-upstream origin branch2
完事之后我們可以再去遠程倉庫看一眼就會發現我們創建的新分支已經推上去了。接下來可能會有小伙伴要問了，那如果遠端倉庫已經有了這個分支名咋整？
這里就分兩種：
一種就是你本地的代碼和遠端代碼沒有沖突的情況下，并且你本地有新增提交，那么你可以仍然執行上述命令，這樣就會直接將當前本地分支合遠程分支關聯上，同時把你的改動提交上去。
另一種就是本地分支和遠端分支存在沖突，這個時候你執行上述命令就會出現提示沖突，那么接下來就需要你先把遠端當前分支的代碼拉下來，解決一下沖突了，就需要用到 git pull 命令了。
通常情況下，如果當前分支已經和遠端分支建立了聯系，那么我們想要合并一下遠端分支，只需要執行 git pull 就好了，不用帶其他參數，但如果和上面提到的 git push 時產生了沖突，還沒有建立聯系的時候，我們就需要指定需要拉取哪個分支的代碼下來進行合并了。
拉取指定遠端分支合并到本地當前分支：git pull origin branch2
這里的 origin 是我們對遠端倉庫的命名，想改也是可以的，不過一般都是用的 origin。
回到上面提到的沖突問題，我們可以直接使用 git pull 然后指定合并當前本地分支想要建立聯系的遠程分支，然后本地解決一下沖突，然后提交一下改動，再執行 git push --set-upstream origin branch2 命令就大功告成了。
了解完上面描述的 git pull，命令之后，其實這個命令也很好理解了，特定時候，可能我們只是想把遠端倉庫對應分支的變更拉到本地而已，并不想自動合并到我的工作區（你當前正在進行代碼變更的工作區），等晚些時候我寫完了某部分的代碼之后再考慮合并，那么你就可以先使用 git fetch。
fetch 完畢之后，我提交了自己當前工作去的變更到本地倉庫，然后想合并一下遠端分支的更改，這個時候執行一下 git merge origin/[當前分支名]（默認一般是用 origin 表示遠端的分支前綴）即可。
合并指定分支代碼到當前分支。一般來說，我們用的比較多的場景可能是，遠端倉庫 master 分支有變更了，同時這個時候我們準備提 MR 了，那么就需要先合一下 master 的代碼，有沖突就解決下沖突，那這個時候我們可以做以下操作：
切到 master 分支，git pull 拉一下最新代碼
切回開發分支，執行 git merge master 合并一下 master 代碼
同理，上面介紹的 git merge origin/xxx 也是一樣的用法。
顧名思義，就是日志的意思，執行這個命令之后，我們能看到當前分支的提交記錄信息，比如 commitId 和提交的時間描述等等，大概長下面這樣：
commit e55c4d273141edff401cbc6642fe21e14681c258 (HEAD -> branch2, origin/branch2) Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com> Date: Mon Aug 1 23:16:11 2022 +0800 Initial commit
這個時候可能有讀者會問了，這個都用來干啥的，簡單的用法呢就是看看有誰提交了啥，還有更重要的用法呢就是進行代碼版本的回滾，或者其他有意思的操作，且聽筆者為你微微道來。
git reset [--soft | --mixed | --hard] [HEAD]
HEAD 表示當前版本
HEAD^ 上一個版本
HEAD^^ 上上一個版本
HEAD^^^ 上上上一個版本
HEAD~n 回撤 n 個版本，這種也是更加方便的
以下解析均基于后接參數為 HEAD^，也就是git reset HEAD^。
--soft: 重置你最新一次提交版本，不會修改你的暫存區和工作區。
--mixed: 默認參數，用于重置暫存區的文件與上一次的提交(commit)保持一致，工作區文件內容保持不變。
--hard: 重置所有提交到上一個版本，并且修改你的工作區，會徹底回到上一個提交版本，在代碼中看不到當前提交的代碼，也就是你的工作區改動也被干掉了。
說了半天似乎不是很好理解，我們舉個栗子理解下：
比如：
我改動了我的 README 文件，在我們的工作區就產生了一次改動，但是這個時候還沒有提交到暫存區，在 vscode 里會顯示為工作區修改的標記
接著我們執行 git add，這個時候你查看暫存區，會發現這次改動被提交進去了，同時被 vscode 標記為已被提交至暫存區
然后再執行 git commit，這個時候就完成了一次提交
接下來我們想撤回這次提交，以上三種參數所體現的表現會是這樣的：
--soft：我們對 README 的更改狀態現在變成已被提交至暫存區，也就是上面 2 的步驟。
--mixed： 我們對 README 的更改變成還未被提交至暫存區，也就是上面 1 的步驟。
--hard：我們對 README 的所有更改全沒了，git log 中也找不到我們對 README 剛剛那次修改的痕跡。
默認情況下我們不加參數，就是 --mixed，也就是重置暫存區的文件到上一次提交的版本，文件內容不動。一般會在什么時候用到呢？
可能大部分情況下，比如 vscode 其實大家更習慣于使用可視化的撤銷能力，但是呢，這里我們其實也可以稍微了解下這其中的奧秘，其實也很簡單：
方式一：git reset
方式二：git reset HEAD
其實一二都是一樣，如果 reset 后面不跟東西就是默認 HEAD。
當你某個改動提交到本地倉庫之后，也就是 commit 之后，這個時候你想撤回來，再改點其他的，那么就可以直接使用 git reset HEAD^。這個時候你會驚奇的發現，你上一版的代碼改動，全部變成了未被提交到暫存區的狀態，這個時候你再改改代碼，然后再提交到暫存區，然后一起再 commit 就可滿足你的需求了。
除了這種基礎用法，我們還可以配合其他命令操作一下。
某一天你老板跟你說，昨天新加的功能不要了，給我切回之前的版本看看效果，那么這個時候，你可能就需要將工作區的代碼回滾到上一個 commit 版本了，操作也十分簡單：
git log 查看上一個 commit 記錄，并復制 commitId
git reset --hard commitId 直接回滾。
如果某一個你開發需求正開心呢，突然發現，自己以前改的某個東西怎么不見了，你想起來好像是某次合并，沒注意被其他提交沖掉了，你心一想，完了，寫了那么多，怎么辦？很簡單，回到有這份代碼的那個版本就好了（前提你提交過到本地倉庫）。
假設我們有這么兩個提交記錄，我們需要下面那個 365 開頭 commitId 的代碼：
commit e62b559633387ab3a5324ead416f09bf347d8e4a (HEAD -> master) Author: xiaohang.lin <xiaohang.lin@alibaba-inc.com> Date: Sun Aug 14 18:08:56 2022 +0800 merge commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD) Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com> Date: Sun Aug 14 15:57:34 2022 +0800 Update README.md
搶救第一步 git log 找到有你這個代碼的那個 commitId（也就是 36577ea21d79350845f104eee8ae3e740f19e038）
搶救第二步 git reset --hard commitId
第三步：Ctrl + c 你的目標代碼
這個時候你想把復制好的代碼寫回去，該怎么辦呢，你可能會再 git log 看一下我們 reset 之前的 commitId，你會發現，完了，之前的 commitId 都沒了，只有這個 365 了。
commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD) Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com> Date: Sun Aug 14 15:57:34 2022 +0800 Update README.md
不要慌，請記住一句話，只要你不刪你本地的 .git 倉庫，你都能找回以前所有的提交。
git log 看不到的話，我們就可以祭出我們的絕招了：git reflog
36577ea (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: reset: moving to 36577ea21d79350845f104eee8ae3e740f19e038
e62b559 HEAD@{1}: reset: moving to e62b559633387ab3a5324ead416f09bf347d8e4a這里我們可以看到兩行記錄，一個是我們執行 reset 到 365 的記錄，另一條不知道是啥，不重要，我們想回到我們剛剛 reset 之前的狀態也很簡單，直接復制它上一次的變動也就是這個 e62b559，然后執行 git reset --hard e62b559，然后你會驚奇的發現，你之前的代碼又回來了。
接下來把你以前版本的代碼，再 Ctrl + v 放進來就完成了。
介紹：用來查看你的所有操作記錄。
既然 git log 看不到我之前 commitId 了，那么就回到 reset 之前的狀態吧！
當然了，如果是針對 master 的操作，為了安全起見，一般還是建議使用 revert 命令，他也能實現和 reset 一樣的效果，只不過區別來說，reset 是向后的，而 revert 是向前的，怎么理解呢？簡單來說，把這個過程當做一次時光穿梭，reset 表示你犯了一個錯，他會帶你回到沒有犯錯之前，而 revert 會給你一個彌補方案，采用這個方案之后讓你得到的結果和沒犯錯之前一樣。
舉個栗子： 假設你改了 README 的描述，新增了一行文字，提交上去了，過一會你覺得這個寫了有問題，想要撤銷一下，但是又不想之前那個提交消失在當前歷史當中，那么你就可以選擇使用 git revert [commitId]，那么它就會產生一次新的提交，提交的內容就是幫你刪掉你上面新增的內容，相當于是一個互補的操作。
PS D:\Code\other\git-practice> git revert 3b18a20ad39eea5264b52f0878efcb4f836931ce On branch branch3 Your branch is ahead of 'origin/branch3' by 1 commit. (use "git push" to publish your local commits)
這個時候，它會提示你可以把新的改動 push 上去了。
其實你如果在 gitlab 進行 mr 之后，想要回滾這個 mr，一般它會給你一個 revert 的按鈕選項，讓你進行更安全的回滾操作。
其實對于我們工作中大部分場景下應該用不到這個功能，但是呢有的時候這個命令又能挽救你于水火之間，那就是當某個倒霉蛋忘記切分支，然后在 master 分支上改了代碼，并且提交到了本地倉庫中，這個時候使用git cherry-pick簡直就是神器了。
git cherry-pick：將執行分支的指定提交合并到當前分支。
一聽介紹就來精神了，雀氏有點東西，比如我在 master 分支提交了某個需求的代碼，同時還沒提交到遠程分支，那么你就可以先 git log 查看一下當前的提交，找到 master 分支正常提交之后的所有 commitId，然后復制出來，然后再切到你建好的開發分支，接著執行 git cherry-pick master commitId1 commitId2 commitId4。
完事之后記得清理一下作案現場，把你的 master 分支代碼恢復到正常的提交上去。
顧名思義，也就是打標簽的意思。一般可能會在你發布了某個版本，需要給當前版本打個標簽，你可以翻閱 vite 的官方 git 倉庫，查看它的 tag 信息，它這里就標注了各個版本發布時候的 tag 標簽。
它有兩種標簽形式，一種是輕量標簽，另一種是附注標簽。
創建方式：git tag v1.0.0
它有點像是對某個提交的引用，從表現上來看，它又有點像基于當前分支提交給你創建了一個不可變的分支，它是支持你直接 checkout 到這個分支上去，但是它和普通分支還是有著本質的區別的，如果你切換到了這個 tag "分支"，你去修改代碼同時產生了一次提交，亦或者是 reset 版本，這對于該 tag 本身不會有任何影響，而是為你生成了一個獨立的提交，但是卻在你的分支歷史中是找不到的，你只能通過 commitId 來切換到本次提交。
那如果你從其他分支通過 commitId 切換到這個改動上，它會提示你以下內容：
Note: switching to 'be276009'. changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch -
大致意思就是你可以選擇丟棄或者保留當前更改，如果需要保留的話直接使用下面的 git switch 命令創建一個新分支即可。
創建方式：git tag -a v1.0.1 -m "發布正式版 1.0.1"
引用官方文檔的描述：
而附注標簽是存儲在 Git 數據庫中的一個完整對象， 它們是可以被校驗的，其中包含打標簽者的名字、電子郵件地址、日期時間， 此外還有一個標簽信息，并且可以使用 GNU Privacy Guard （GPG）簽名并驗證。
從概念上看，輕量標簽更像是一個臨時的標簽，而附注標簽更加正式一點，能夠保留更多的信息。它創建的方式和輕量標簽區別主要是 -a 和 -m 參數，如果你的 -m 參數不傳，那么編輯器會讓你手動填寫。
打完標簽之后，我們可以使用 git show 命令來看看這兩種標簽最終體現的信息有哪些。
commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch2, tag: v1.0.2, tag: v1.0.1) Author: STDSuperman <2750556766@qq.com> Date: Tue Aug 16 22:54:36 2022 +0800 xx diff --git a/README.md b/README.md index 715766a..b4cdea6 100644 --- a/README.md +++ b/README.md @@ -1 +1,3 @@-# git-practice\ No newline at end of file +# git-practice + +test tag
tag v1.0.1 Tagger: STDSuperman <2750556766@qq.com> Date: Tue Aug 16 22:58:27 2022 +0800 發布正式版 1.0.0 commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch2, tag: v1.0.1) Author: STDSuperman <2750556766@qq.com> Date: Tue Aug 16 22:54:36 2022 +0800 xx diff --git a/README.md b/README.md index 715766a..b4cdea6 100644 --- a/README.md +++ b/README.md
從信息豐富度上來說，附注標簽能保留的信息會更多。
git push origin tagName
$> git push origin v1.0.1Enumerating objects: 6, done. Counting objects: 100% (6/6), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 448 bytes | 448.00 KiB/s, done. Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 To github.com:STDSuperman/git-practice.git * [new tag] v1.0.1 -> v1.0.1
當然，附注標簽和輕量標簽都是可以被推送到遠端的。
查看標簽：git tag
篩選標簽：git tag -l v1.0.1
刪除標簽：git tag -d v1.0.1
刪除遠程標簽：git push origin --delete v1.0.2
另一種刪除遠程方式（表示將“:”前面空值替換到遠程，也不失為一種方式）：git push origin :refs/tags/v1.0.1
讀到這里，這篇“Git使用方法有哪些”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
