大話 Git 使用

衆衆衆衆衆所周知,github 是一個好東西。本篇就來說說 Git 的那些指令,網上已經有很多文章,本篇就本不知名小博主在使用過程中用到的一些指令和問題來記錄和說明。如果對你有幫助歡迎點贊收藏,覺得寫的不好請跳至文末。


一個超簡明使用的提交模版:

git clone 倉庫地址    //進入下載好的本地倉庫文件夾下
git add .
git commit -m "備註提交的部分"
git push   //提交自己的修改
git pull  //如果不能push,需要先從遠程倉庫拉取到別人的修改

當然,你以爲 GitHub 就是這麼簡單的東西麼?曾經的我就是這麼以爲的,至少上面這幾個指令讓我成功的提交了幾次,直到我遇到了衝突……對於使用來說,我覺得最惱火的就是在提交的時候遇到衝突,這時候就需要我們瞭解各種 Git 指令,對應情況對症下指令了,下面是一些可能會常用到的指令,以列表的形式給出。

Git 的一些指令用法

關於文件

pwd 命令用於顯示當前目錄。

通過 git init 命令把這個目錄變成 Git 可以管理的倉庫,文件下就會有一個名爲 .git 的隱藏文件夾。如果你沒有看到 .git 目錄,那是因爲這個目錄默認是隱藏的,用 ls -ah 命令就可以看見。

使用標準的 UTF-8 編碼。

用命令 git add 告訴 Git,把文件添加到倉庫。

提交

git commit 命令,-m 後面輸入的是本次提交的說明,可以輸入任意內容,當然最好是有意義的,這樣你就能從歷史記錄裏方便地找到改動記錄。

commit 可以一次提交很多文件,所以你可以多次 add 不同的文件。

git status 命令可以讓我們時刻掌握倉庫當前的狀態。

git diff 命令看具體修改了什麼內容。

把修改提交到 git 版本庫:

提交修改和提交新文件是一樣的兩步,第一步是 git add(實際上就是把文件修改添加到暫存區)。

在執行第二步 git commit(實際上就是把暫存區的所有內容提交到當前分支)之前,我們再運行 git status 看看當前倉庫的狀態。

提交後,我們再用 git status 命令看看倉庫的當前狀態。

即:git add——>git status——>git commit——>git status

版本退回

git log 命令顯示從最近到最遠的提交日誌,加上 --pretty=oneline 參數顯示爲一行:

git log --pretty=oneline

在 Git 中,用 HEAD 表示當前版本,上一個版本就是 HEAD^,上上一個版本就是HEAD^^,當然往上 100 個版本寫 100 個 ^ 比較容易數不過來,所以寫成 HEAD~100

退回上一個版本 git reset --hard HEAD^

然後用 git log 再看看現在版本庫的狀態,用 git log 可以查看提交歷史,以便確定要回退到哪個版本。

找到操作文件那步的的 commit id(前面的十六進制數),用 git reset --hard commit_id 指定回到未來的某個版本(未關閉終端窗口的恢復操作)。

Git 提供了一個命令 git reflog 用來記錄你的每一次命令。

git reflog 查看命令歷史,以便確定要回到未來的哪個版本(關閉終端後再想恢復的操作)。

git cat-file 命令顯示版本庫對象的內容、類型及大小信息,cat 文件名:顯示文件內容。

第一次修改 -> git add -> 第二次修改 -> git add -> git commit每次修改,如果不 add 到暫存區,那就不會加入到 commit 中。

git checkout -- file 可以丟棄工作區的修改

文件自修改後還沒有被放到暫存區,現在,撤銷修改就回到和版本庫一模一樣的狀態。

文件已經添加到暫存區後,又作了修改,現在,撤銷修改就回到添加到暫存區後的狀態————讓這個文件回到最近一次 git commitgit add 時的狀態。

用命令 git reset HEAD file 可以把暫存區的修改撤銷掉(unstage),重新放回工作區。

當你改亂了工作區某個文件的內容,想直接丟棄工作區的修改時,用命令 git checkout -- file

當你不但改亂了工作區某個文件的內容,還添加到了暫存區時,想丟棄修改,分兩步,第一步用命令git reset HEAD file,就回到了上一點,第二步按上一步(git checkout -- file)操作。

從暫存區提交到了版本庫,還沒有把自己的本地版本庫推送到遠程,用退回上一個版本的操作(git reset --hard HEAD^)。

clipboard.png

刪除文件

rm 文件名:刪除該文件。

git status 查看哪些文件被刪除。

刪錯了,用 git checkout 文件名:用版本庫裏的版本替換工作區的版本,無論工作區是修改還是刪除,都可以“一鍵還原”。

git rm 文件名:從版本庫刪除該文件,並 git commit,之後不能再還原了。

命令 git rm 用於刪除一個文件,如果一個文件已經被提交到版本庫,誤刪可恢復,但只能恢復文件到最新版本,你會丟失最近一次提交後你修改的內容。

關於遠程庫

添加遠程庫:在 github 上建立好後,在終端用命令:

git remote add origin git@你的倉庫 

在本地關聯的就是你的遠程庫,添加後,遠程庫的名字就是 origin,這是 Git 默認的叫法,也可以改成別的,但是 origin 這個名字一看就知道是遠程庫。

git push -u origin master 把本地庫的所有內容推送到遠程庫上,用git push命令,實際上是把當前分支 master 推送到遠程。由於遠程庫是空的,我們第一次推送 master 分支時,加上了 -u 參數,Git 不但會把本地的 master 分支內容推送的遠程新的 master 分支,還會把本地的 master 分支和遠程的 master 分支關聯起來,在以後的推送或者拉取時就可以簡化命令。

從現在起,只要本地作了提交,就可以通過命令:

git push origin master

用命令 git clone 克隆一個本地庫:

git clone git@你要克隆的倉庫

Git 支持多種協議,包括 https,但通過 ssh 支持的原生 git 協議速度最快

創建 dev 分支,然後切換到 dev 分支,git checkout -b dev (git checkout 命令加上 -b 參數表示創建並切換,相當於以下兩條命令:

$ git branch dev 
$ git checkout dev

git branch 命令查看當前分支,git branch 命令會列出所有分支,當前分支前面會標一個 * 號。

Dev 分支的工作完成,我們就可以切換回 master 分支:git checkout master
dev 分支的工作成果合併到 master 分支上:git merge devgit merge 命令用於合併指定分支到當前分支。

git branch -d dev 刪除 dev 分支。

Bug 分支

Git 中,由於分支是如此的強大,所以,每個 bug 都可以通過一個新的臨時分支來修復,修復後,合併分支,然後將臨時分支刪除。

Git 提供了一個 stash 功能,可以把當前工作現場“儲藏”起來,等以後恢復現場後繼續工作(如當前正在 dev 上進行的工作還沒有提交)。

git status 查看工作區,就是乾淨的(除非有沒有被 Git 管理的文件)。

因此可以放心地創建分支來修復 bug

首先確定要在哪個分支上修復 bug,假定需要在 master 分支上修復,就從 master 創建臨時分支:

git checkout master/git checkout -b 分支名

現在修復 bug 然後提交。

修復完成後,切換到 master 分支,並完成合並,最後刪除臨時分支。

接着回到 dev 分支幹活。

git stash list 命令看工作現場。

工作現場還在,Gitstash 內容存在某個地方了,但是需要恢復一下,有兩個辦法:
git stash apply 恢復,但是恢復後,stash 內容並不刪除,需要用 git stash drop 來刪除。

git stash pop,恢復的同時把 stash 內容也刪了。

再用 git stash list 查看就看不到任何 stash 內容,可以多次 stash,恢復的時候,先用 git stash list 查看,然後恢復指定的 stash,用命令:git stash apply stash@{0}

修復 bug 時通過創建新的 bug 分支進行修復然後合併最後刪除,當手頭工作沒有完成時,先把工作現場 git stash 一下,然後去修復 bug 修復後再 git stash pop,回到工作現場。

每添加一個新功能,最好新建一個 feature 分支,在上面開發,完成後合併,最後刪除該 feature 分支。

開發一個新 feature,最好新建一個分支,如果要丟棄一個沒有被合併過的分支,可以通過 git branch -D <name> 強行刪除。

當你從遠程倉庫克隆時,實際上 Git 自動把本地的 master 分支和遠程的 master 分支對應起來了,並且遠程倉庫的默認名稱是 origin

要查看遠程庫的信息,用 git remote

git remote -v 顯示更詳細的信息。

推送分支,就是把該分支上的所有本地提交推送到遠程庫 git push

master 分支是主分支,因此要時刻與遠程同步。

Dev 分支是開發分支,團隊所有成員都需要在上面工作,所以也需要與遠程同步。

Bug 分支只用於在本地修復 bug,沒必要推到遠程。

Feature 分支是否推到遠程,取決於你是否和你的小夥伴合作在上面開發。

本地新建的分支如果不推送到遠程,對其他人就是不可見的。

從本地推送分支,使用 git push origin branch-name,如果推送失敗,先用 git pull 抓取遠程的新提交。

在本地創建和遠程分支對應的分支,使用:

git checkout -b branch-name origin/branch-name

本地和遠程分支的名稱最好一致。

建立本地分支和遠程分支的關聯,使用:

 git branch --set-upstream branch-name origin/branch-name

標籤

敲命令 git tag <name> 可以打一個新標籤。

用命令 git tag 查看所有標籤。

默認標籤打在最新提交的 commit 上,否則找到歷史提交的 commit id,然後用命令 git tag <name> <commit id> 打上標籤。

找歷史提交的 commit id,用命令 git log --pretty=oneline —abbrev-commit

標籤不是按時間順序列出,而是按字母排序的,用 git show <tagname> 查看標籤信息。

創建帶有說明的標籤,用 -a 指定標籤名,-m 指定說明文字,用命令 git show <tagname> 可以看到說明文字。

通過 -s 用私鑰簽名一個標籤,簽名採用 PGP 簽名。

創建的標籤都只存儲在本地,不會自動推送到遠程,打錯的標籤可以在本地安全刪除 git tag -d <name>

推送某個標籤到遠程,使用命令 git push origin <tagname>

一次性推送全部尚未推送到遠程的本地標籤 git push origin —tags

如果標籤已經推送到遠程,要刪除遠程標籤先從本地刪除再從遠程刪除,刪除命令也是 push

命令 git push origin :refs/tags/<tagname> 可以刪除一個遠程標籤

關於 Github

GitHub 上,可以任意 Fork 開源倉庫。

自己擁有 Fork 後的倉庫的讀寫權限。

可以推送 pull request 給官方倉庫來貢獻代碼。

添加一個新的遠程倉庫,在本地庫上使用命令 git remote add <遠程庫名字> <SSH地址>,再用 git remote -v 查看遠程庫信息。

git 給遠程庫起的默認名稱是 origin,如果有多個遠程庫,我們需要用不同的名稱來標識不同的遠程庫:

git push <遠程庫名> master

敲一行命令告訴 Gitst 就表示 status:git config --global alias.st status--global 參數是全局參數,也就是這些命令在這臺電腦的所有 Git 倉庫下都有用,加上 --global 是針對當前用戶起作用的,如果不加則只針對當前的倉庫起作用。

配置一個 git last,讓其顯示最後一次提交信息 git config --global alias.last 'log -1',用 git last 就能顯示最近一次的提交。

每個倉庫的 Git 配置文件都放在 .git/config 文件中:cat .git/config

當前用戶的 Git 配置文件放在用戶主目錄下的一個隱藏文件 .gitconfig 中:cat .gitconfig

配置別名也可以直接修改這個文件,如果改錯了,可以刪掉文件重新通過命令配置。

搭建 Git 服務器作爲私有倉庫使用。

Git push —-force可以在沒有pull的情況下直接“暴力”push

總結

查看分支:git branch

創建分支:git branch <name>

切換分支:git checkout <name>

創建+切換分支:git checkout -b <name>

合併某分支到當前分支:git merge <name>

刪除分支:git branch -d <name>

在兩個分支上同時修改一個文件會發生衝突,當 Git 無法自動合併分支時,就必須首先解決衝突。解決衝突後,再提交,合併完成,用 git log —graph 命令可以看到分支合併圖。

git merge --no-ff -m"again and again" dev,用git log看看分支歷史,合併後的歷史有分支,能看出來曾經做過合併,而 fast forward 合併就看不出來曾經做過合併。

在實際開發中,按照幾個基本原則進行分支管理:

  • Master 分支應該是非常穩定的,也就是僅用來發布新版本,平時不能在上面幹活。
  • dev 分支上幹活,也就是說,dev 分支是不穩定的,到某個時候,比如 1.0 版 本發佈時,再把 dev
    分支合併到 master 上,在 master 分支發佈 1.0 版本。
  • 你和你的小夥伴們每個人都在 dev 分支上幹活,每個人都有自己的分支,時不時地往 dev 分支上合併就可以了。

剩下的關於 Git 的學習,最有效的方法可能就是實踐了,現在就開始建立你的 Github 賬號吧。


不足之處,歡迎指正。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章