Git 筆記 - 程序員都要掌握的 Git

時間 2019-11-07

標籤 git 筆記程序員掌握欄目 Git 简体版

原文原文鏈接

前言

本文是參考廖雪峯老師的Git資料再加上我本身對Git的理解，記錄個人Git學習歷程，做下此文是爲之後學習，工做，開發中若是遇到問題能夠回過頭來參考參考。由於水平有限，不免會有出錯的地方，歡迎指正。前端

Git是什麼

官方話：Git是一個免費的開源分佈式版本控制系統，旨在快速高效地處理從小型到大型項目的全部事務。
引用廖雪峯老師的話，它能自動幫我記錄每次文件的改動，還可讓同事協做編輯，這樣就不用本身管理一堆相似的文件了，也不須要把文件傳來傳去。若是想查看某次改動，只須要在軟件裏瞄一眼就能夠。

爲何要學習Git

面試要被問。能夠應付面試。
不少公司開發都用Git來處理項目。如今不學，之後確定還要學。
在我看來Git是現現在全部程序員都要掌握的，之後與同事共同開發項目一定要用到的，熟練掌握Git命令，能夠提升開發的效率。。

安裝Git

Windows
直接在官網上去下載。下載完成後，隨便在某個文件下右鍵若是有Git Bash Here就安裝成功。安裝後，還要在命令行輸入

$git config --global user.name "你的名字"
$git config --global user.email "你的郵箱"
複製代碼

global表示全局，這臺機器全部的Git倉庫都會使用這個配置。容許單個倉庫使用其餘的名字和郵箱。node

Mac
評論區指出Mac也能夠像Windows同樣，按上面的步驟安裝。也能夠直接從AppStore安裝Xcode，Xcode集成了Git，不過默認沒有安裝，你須要運行Xcode，選擇菜單「Xcode」->「Preferences」，在彈出窗口中找到「Downloads」，選擇「Command Line Tools」，點「Install」就能夠完成安裝了。

倉庫

本地倉庫是對於遠程倉庫而言的。
本地倉庫 = 工做區 + 版本區
工做區即磁盤上的文件集合。
版本區(版本庫)即.git文件
版本庫 = 暫存區(stage) + 分支(master) + 指針Head
- 以我使用最頻繁的git命令爲例，即提交到github爲例。
- git init 本來本地倉庫只包含着工做區，這是最多見的工做狀態。此時，git init一下，表示在本地區域建立了一個.git文件,版本區創建。
- git add . 表示把工做區的全部文件所有提交到版本區裏面的暫存區
- 固然你也能夠經過 git add ./xxx/ 一條一條分批添加到暫存區。
- git commit -m "xxx" 把暫存區的全部文件提交到倉庫區，暫存區空空蕩蕩。
- git remote add origin https://github.com/name/name_cangku.git 把本地倉庫與遠程倉庫鏈接起來。
- git push -u origin master 把倉庫區的文件提交到遠程倉庫裏。
- 一旦提交後，若是你又沒有對工做區作任何修改，那麼工做區就是「乾淨」的。會有這樣的信息nothing to commit, working tree clean

提交到GitHub

之前不熟悉git命令的時候，我提交項目到github上都是直接在網頁上直接拉取文件提交上去的。有點羞恥。 git

git init .初始化，表示把這個文件變成Git能夠管理的倉庫。初始化後打開隱藏的文件能夠看到有一個.git文件。
git add . 後面的一個點表示把這個文件所有提交到暫存區。
git add ./readme.md/ 表示把這個文件下面的readme.md文件提交到暫存區。
git commit -m "你要評論一點什麼東西" git commit的意思是把暫存區的所有文件提交到本地倉庫。-m後接評論。
git remote add origin https://github.com/name/name_cangku.git表示把你本地的倉庫與GitHub上的遠程倉庫鏈接起來。只須要鏈接一次，之後提交的時候就能夠不用謝這條命令了。name是你的github名字，name_cangku是你的倉庫名。注意不要把後面的.git給漏掉了。由於我前面就是這麼走過來的，繞了不少彎路。至於如何在GitHub上新建倉庫，網上有不少教程，這裏再也不贅述了。
git push -u origin master 把本地倉庫提交到遠程倉庫。(最後一步)在你的遠程倉庫上刷新一下就能夠看到你提交的文件了。
最後提到的是，在git commit -m ""以前，能夠重複git add到暫存區。可是git commit會把你以前存放在暫存區的所有文件一次性所有提交到本地倉庫。

版本的回溯與前進

提交一個文件，有時候咱們會提交不少次，在提交歷史中，這樣就產生了不一樣的版本。每次提交，Git會把他們串成一條時間線。如何回溯到咱們提交的上一個版本，用git reset --hard + 版本號便可。版本號能夠用git log來查看，每一次的版本都會產生不同的版本號。回溯以後，git log查看一下發現離咱們最近的那個版本已經不見了。可是我還想要前進到最近的版本應該如何？只要git reset --hard + 版本號就行。退一步來說，雖然咱們能夠經過git reset --hard + 版本號,靠記住版本號來能夠在不一樣的版本之間來回穿梭。可是,有時候把版本號弄丟了怎麼辦？git reflog幫你記錄了每一次的命令，這樣就能夠找到版本號了，這樣你又能夠經過git reset來版本穿梭了。程序員

撤銷

場景1：在工做區時，你修改了一個東西，你想撤銷修改，git checkout -- file。廖雪峯老師指出撤銷修改就回到和版本庫如出一轍的狀態，即用版本庫裏的版本替換工做區的版本。
場景2：你修改了一個內容，而且已經git add到暫存區了。想撤銷怎麼辦？回溯版本，git reset --hard + 版本號,再git checkout -- file,替換工做區的版本。
場景3：你修改了一個內容，而且已經git commit到了master。跟場景2同樣，版本回溯，再進行撤銷。

刪除

若是你git add一個文件到暫存區，而後在工做區又把文件刪除了，Git會知道你刪除了文件。若是你要把版本庫裏的文件刪除，git rm 而且git commit -m "xxx".
若是你誤刪了工做區的文件，怎麼辦？使用撤銷命令，git checkout --<file>就能夠。這再次證實了撤銷命令其實就是用版本庫裏的版本替換工做區的版本，不管工做區是修改仍是刪除，均可以「一鍵還原」。

分支

分支，就像平行宇宙，廖雪峯老師如是說。你建立了一個屬於你本身的分支，別人看不到，還繼續在原來的分支上正常工做，而你在本身的分支上幹活，想提交就提交，直到開發完畢後，再一次性合併到原來的分支上，這樣，既安全，又不影響別人工做。github

建立與合併分支

在沒有其餘分支插進來時，只有一個master主分支。每次你 git push -u origin master 提交就是增長一條時間軸，master也會跟着移動。

建立一個other的分支，經過other提交，雖然時間軸向前走了，可是主分支master還在原來的位置。

理論分析完，看一下命令怎麼寫。面試

建立分支other,切換到other分支。

git branch other
git checkout other
複製代碼

查看當前全部分支

git branch
複製代碼

* other
  master
複製代碼

當前的分支會有一個*安全

用other提交

git add ./xxx/
git commit -m "xxx"
複製代碼

other分支完成，切換回master

git checkout master
複製代碼

此時，master分支上並無other的文件，由於分支尚未合併。
合併分支

git merge other
複製代碼

合併完成以後，就能夠在master分支上查看到文件了。
刪除other分支。

git branch -d other
複製代碼

我由此想到，在之後工做中，應該是一個開放小組共同開發一個項目，組長會建立不少分支，每個分支能夠交給一我的去開發某一個功能，一個小組共同開發並且不會相互干擾。誰的功能完成了，能夠由組長合併一下完成了的分支。哦，完美！

解決合併分支問題

假若有這樣一種狀況，分支 other已經 commit了，可是此時指針指回 master時，而且 master沒有合併，而是 git add / commit 提交了。這樣，就產生了衝突，主分支 master文件內容與 other分支的內容不同。合併不起來！因此，

修改文件的內容，讓其保持一致。
git add git commit 提交。
分支合併了。
git log --graph 查看分支合併圖
git branch -d other 刪除分支，任務結束。

分支管理策略

git merge --no-ff other 禁用Fast forward模式，由於使用Fast forward模式，刪除分支後，分支歷史信息會丟失。

BUG分支

廖雪峯老師提到，工做中每一個bug均可以經過一個新的臨時分支來修復，修復後，合併分支，而後將臨時分支刪除。但若是你手上有分支在工做中，你的上級要你改另外的分支的BUG。你要把如今正在工做的分支保存下來，git stash,把當前工做現場「存儲」起來，等之後恢復後繼續工做。當你解決BUG後，git checkout other回到本身的分支。用git stash list查看你剛剛「存放」起來的工做去哪裏了。此時你要恢復工做：bash

git stash apply恢復卻不刪除stash內容，git stash drop刪除stash內容。
git stash pop恢復的同時把stash內容也刪了.
此時，用git stash list查看，看不到任何stash 內容。
總結：修復bug時，咱們會經過建立新的bug分支進行修復，而後合併，最後刪除；當手頭工做沒有完成時，先把工做現場git stash一下，而後去修復bug，修復後，再git stash pop，回到工做現場

刪除分支

git branch -d + 分支有可能會刪除失敗，由於Git會保護沒有被合併的分支。
git branch -D + 分支 強行刪除，丟棄沒被合併的分支。

多人協做

git remote 查看遠程庫的信息，會顯示origin，遠程倉庫默認名稱爲origin
git remote -v顯示更詳細的信息
git push -u origin master推送master分支到origin遠程倉庫。
git push -u origin other 推送other到origin遠程倉庫。

抓取分支

產生上圖的衝突時，

git pull 把最新的提交從遠程倉庫中抓取下來，在本地合併，解決衝突。在進行git pull
若是git pull 也失敗了，還要指定分支之間的連接，這一步Git會提醒你怎麼作。而後再git pull。

廖雪峯老師的總結：多人協做的工做模式一般是這樣：app
- 首先，能夠試圖用git push origin <branch-name>推送本身的修改；分佈式
- 若是推送失敗，則由於遠程分支比你的本地更新，須要先用git pull試圖合併；
- 若是合併有衝突，則解決衝突，並在本地提交；
- 沒有衝突或者解決掉衝突後，再用git push origin <branch-name> 推送就能成功！
- 若是git pull提示no tracking information，則說明本地分支和遠程分支的連接關係沒有建立，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
Rebase
git rebase 把分叉的提交歷史「整理」成一條直線，看上去更直觀.缺點是本地的分叉提交已經被修改過了。
最後在進行git push -u origin master
rebase的目的是使得咱們在查看歷史提交的變化時更容易，由於分叉的提交須要三方對比。

標籤管理

好比一個APP要上線，一般在版本庫中打一個標籤(tag), 這樣，就肯定了打標籤的版本。未來不管何時，取某個標籤的版本，就是把那個打標籤的時刻的歷史版本取出來。因此，標籤也是版本庫的一個快照。
Git的標籤雖然是版本庫的快照，但其實它就是指向某個commit的指針。
tag其實就是一個讓人容易記住的有意義的名字，它跟某個commit綁在一塊兒。好比tag v2.1就是把歷史上的一個版本的東西叫作v2.1

建立標籤

步驟：

git branch查看當前分支,git checkout master切換到master分支。
git tag <name> 打標籤，默認爲HEAD。好比git tag v1.0
默認標籤是打在最新提交的commit上的。若是想要打標籤在之前的commit上，要git log找到歷史提交的commit id.
若是一個commt id是du2n2d9,執行git tag v1.0 du2n2d9就把這個版本打上了v1.0的標籤了。
git tag 查看全部標籤，能夠知道歷史版本的tag
標籤不是按時間順序列出，而是按字母排序的。
git show <tagname> 查看標籤信息。
git tag -a <標籤名> -m "<說明>",建立帶說明的標籤。 -a指定標籤名，-m指定說明文字。用show能夠查看說明。

操做標籤

git tag -d v1.0 刪除標籤。由於建立的標籤都只存儲在本地，不會自動推送到遠程。因此，打錯的標籤能夠在本地安全刪除。
git push origin <tagname> 推送某個標籤到遠程
git push origin --tags 一次性推送所有還沒有推送到遠程的本地標籤
若是標籤推送到遠程。git tag -d v1.0 先刪除本地標籤v1.0。git push origin :refs/tags/v1.0刪除遠程標籤v1.0

自定義Git

git config --global color.ui true讓Git顯示顏色，會讓命令輸出看起來更醒目
忽略特殊文件建立一個.gitignore文件，把須要忽略的文件名填進去。Git就會自動忽略這些文件。我也在學習中遇到過這樣的問題，好比node_modules文件就能夠忽略。
忽略文件原則：忽略操做系統自動生成的文件，好比縮略圖等；忽略編譯生成的中間文件、可執行文件等，也就是若是一個文件是經過另外一個文件自動生成的，那自動生成的文件就不必放進版本庫，好比Java編譯產生的.class文件；忽略你本身的帶有敏感信息的配置文件，好比存放口令的配置文件。
強制提交已忽略的的文件。git add -f <file>
git check-ignore -v <file>檢查爲何Git會忽略該文件。
給Git命令配別名,這個有點騷，就是你之後想輸入git rebase時,你給它一個「外號」，就叫它git nb。之後你能夠經過git nb來代替git rebase。具體怎麼轉換能夠去廖雪峯老師的網站看。由於水平有限，我以爲先把正常的Git命令搞清楚來就很不錯了。