https://learngitbranching.js.org/?locale=zh_CN在線練習git

1. Git

安裝好Git以后, 先檢查是否已經(jīng)綁定了用戶名和郵箱

git config --list

再檢查C:\Users\xxx.ssh 下是否存在 id_rsa.pub , 存在的話復制其內容到 GitHub 的 SSH KEY 中

沒有這一步, PUSH操作的時候會報錯:

Successfully created project 'test3' on GitHub, but initial push failed: git@github.com: Permission denied (publickey). Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

1.1 為什么要使用版本控制？

從個人角度：
在做項目時，如果一點點去改代碼會很亂，不利于我們的開發(fā)和進度。
使用版本控制可以讓每一個歷史版本都被記錄，可以回到某一個歷史狀態(tài)，接著在這個歷史狀態(tài)下進行修改。
通俗來講就是可以回退和撤銷操作。

從團隊合作角度：每一個都需要開發(fā)自己負責的功能，多個人在開發(fā)同一個項目時，必須使用版本控制協(xié)調好每個人對項目的更改

1.2 集中式版本控制

用戶從遠程倉庫獲取到的，只是最新版本的文件快照。

集中式的版本控制系統(tǒng)，所有的版本庫是放在中央服務器中的
也就是說我們每一次的修改上傳都是保存在中央服務器中的。
中央服務器就是個大倉庫，大家把產品都堆里面，每一次需要改進和完善的時候，需要去倉庫里面把文件給提出來，然后再操作。

集中式版本控制的缺點主要是

1. 需要聯(lián)網(wǎng)。無論是局域網(wǎng)還是互聯(lián)網(wǎng)，電腦必須要與中央倉庫聯(lián)網(wǎng)。
2. 僅中央倉庫掌握完整的項目檔案庫（即所有文件即對應的修訂版本），一旦中央倉庫宕機，整個項目組都會停工；一旦中央倉庫數(shù)據(jù)丟失，公司直接倒閉。

1.2.1 集中式版本控制的兩種模式

1.2.1.1 鎖定模式

在鎖定模式下，當開發(fā)者想要修改某檔案、簽出該檔案后，該檔案便會進入鎖定狀態(tài)，其他開發(fā)成員便無法加以修改，直到簽出者將該檔案簽回為止。
對于維持同步來說，這當然是一個十分保險的作法，因為永遠不會有兩個或以上的開發(fā)者同時修改同一個檔案。
只是這種方法造成了開發(fā)者對于檔案修改的互斥效應，大大降低了開發(fā)效率。

1.2.1.2 合并模式

在合并模式下，允許多位開發(fā)者同時針對同一檔案進行修改
但是，若當他們分別將檔案提交回倉庫時發(fā)生沖突，便會自動進行合并，而若自動合并失敗，再要求人工合并。

不過即使如此，最終目的還是要維持多個開發(fā)者間的同步。畢竟，版本控制的結果在集中式檔案庫中是唯一的，也是每位開發(fā)者都需與此結果保持一致的。

1.3 分布式版本控制

分布的含義是每臺計算機上都還有一個完整的版本庫。

也就是說，當用戶 Clone 遠程倉庫時，并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來，包括完整的歷史記錄

不同于集中式版本控制系統(tǒng)的“中央服務器”，分布式版本控制系統(tǒng)可以通過推送版本庫，實現(xiàn)不同的計算機之間的版本共享。
什么意思呢？就是說對于同一個文件A，如果兩個人同時對A文件進行了修改，最新的版本應該都保存在各自的計算機中，想要實現(xiàn)協(xié)同開發(fā)，只需要將各自的最新版本庫推送給對方，就可以得到最新的版本庫了。

但是這里面有個問題，就是一個團隊很大的情況下，大家都去修改，到底找誰同步版本庫，不亂套了嘛。而且，大的開發(fā)項目也不是簡單的兩臺計算機之間的版本互推就可以得到完整的版本庫的。
所以，分布式版本控制系統(tǒng)中通常也會有一臺充當“中央服務器”的計算機，大家都把版本推送到這臺計算機上，而需要同步的人只需同步這一臺固定的計算機就可以。

讀到這，可能覺得又繞回到集中式版本管理系統(tǒng)了。
實則不然，所謂的分布式管理中的“中央服務器”是用來“交換意見”，或者說充當中介作用的。每一臺計算機通過和這臺固定的中介交換意見以后，都會擁有完整的版本庫。

舉個不恰當?shù)睦?#xff0c;分布式中的“中央管理器”就是《鄉(xiāng)村愛情》中的大腳超市，劉能、趙四以及長貴都掌握了最新的緋聞，通過大腳超市的意見交換后，每個人都掌握了整個象牙山的緋聞。我們可以看到，在這樣的緋聞生態(tài)下，即便是王長貴掛了，象牙山的故事仍然可以繼續(xù)。但是如果長貴是集中式的“中央管理器”，每個人可以將自己知道的緋聞、秘密吐槽給他且不外傳，那么他的死將會直接導致《鄉(xiāng)村愛情》的終結。

單槍匹馬的工作流

團隊協(xié)作的工作流

其中, pull request 與 pull 區(qū)別很大
pull request : 請求遠程倉庫拉取本人的 commt
pull : 將遠程倉庫同步更新到本地

1.4 Git管理本地倉庫

1.4.1

以下所談三個區(qū)，文件并不只是簡單地在三個區(qū)轉移，而是以復制副本的方式轉移

使用 Git 管理的項目，擁有三個區(qū)域，分別是

• 工作區(qū)、
• 暫存區(qū)、
• Git 倉庫

對應地，Git 中的文件有三種狀態(tài)

• modified 已修改 ：若工作區(qū)的文件被修改了，但還沒有放到暫存區(qū)，就是 modified 狀態(tài)。
• staged 已暫存 ：若被修改的文件已經(jīng)從工作區(qū)到了暫存區(qū)，就是 staged 狀態(tài)，因此我們也可以說，文件處于暫存區(qū) = 文件是 staged 狀態(tài)。此外，Git 會為 staged 狀態(tài)的文件打上標記，以使其包含在下次 commit 的列表中
• committed 已提交 ：表示文件已經(jīng) “復制一份” 到了本地 Git 倉庫中

1.4.2 演示

初始化倉庫(?)

現(xiàn)在F盤里創(chuàng)建一個文件夾demoProject,文件夾中建一個index.html。

① 在項目目錄中，通過鼠標右鍵打開 CMD

② 執(zhí)行 git init 命令將當前的目錄轉化為 Git 倉庫

git init 命令會創(chuàng)建一個名為 .git 的隱藏目錄，這個 .git 目錄就是當前項目的 Git 倉庫，里面包含了初始的必要文件，這些文件是 Git 倉庫的必要組成部分

檢查文件的狀態(tài)(??)

使用 git status 輸出的狀態(tài)
git status -s 輸出簡要狀態(tài)

？？代表圖1的Untracked 狀態(tài)，該文件處于工作區(qū)

跟蹤新文件(???)

#使用命令 git add 開始跟蹤 index.html 文件
git add index.html# 如果文件過多，你項跟蹤目錄下所有文件
git add *.*

之后再運行 git status 命令，會看到 index.html 文件在 Changes to be committed 這行的下面，說明已被跟蹤，并處于暫存區(qū)，staged 狀態(tài)：

提交更新(????)

現(xiàn)在暫存區(qū)中有一個 index.html 文件等待被提交到 Git 倉庫中進行保存。
執(zhí)行 git commit 命令進行提交,其中 -m 選項用來附帶備注

commit 之后的文件就處于本地 Git 倉庫中了，commited狀態(tài)

git commit -m "這是一個備注，剛剛新建了index.html 文件"

修改并更新(?????)

目前，index.html 文件已經(jīng)被 Git 跟蹤，并且工作區(qū)和 Git 倉庫中的 index.html 文件內容保持一致。

當我們修改了工作區(qū)中 index.html 的內容之后，再次運行 git status 命令，會看到如下的內容：

文件 index.html 出現(xiàn)在 Changes not staged for commit 這行下面

運行 git status -s 命令，會看到如下的內容：M 代表著 Modified，即修改過的、沒有放入暫存區(qū)的文件

總而言之，現(xiàn)在文件處于工具區(qū)，但是 modified 狀態(tài)，等待add到暫存區(qū)

接下來，我們可以相繼 add 和 commit，以將修改后的文件保存到本地 Git 倉庫

1.4.3 add 命令

add是個多功能的命令，主要有如下 3 個功效：

① 可以用它開始跟蹤新文件，并放到暫存區(qū)

② 把已跟蹤的、且已修改的文件放到暫存區(qū)

③ 把有沖突的文件標記為已解決狀態(tài)

此外，當存在多個文件需要添加到暫存區(qū)時是，采用

git add . 

git commit 默認會將暫存區(qū)所有文件一并 commit

1.4.4 commit

Git 標準的工作流程是工作區(qū) → 暫存區(qū) → Git 倉庫，但有時候這么做略顯繁瑣，此時可以跳過暫存區(qū)，直接將工作區(qū)中的修改提交到 Git 倉庫，這時候 Git 工作的流程簡化為了工作區(qū) → Git 倉庫

Git 提供了一個跳過使用暫存區(qū)域的方式， 只要在提交的時候，給 git commit 加上 -a 選項，Git 就會自動把所有已經(jīng)跟蹤過的文件暫存起來一并提交，從而跳過 git add 步驟：

git commit -a -m "日志信息"

1.4.6 status

git status 命令無法直接顯示已提交（committed）文件的狀態(tài)，它主要關注的是當前工作目錄和暫存區(qū)（index/staging area）中文件的狀態(tài)。當你執(zhí)行 git status 時，它會告訴您以下信息：

未暫存的改動（即已修改但未添加到暫存區(qū)的文件）
已暫存的改動（即已添加到暫存區(qū)等待下次提交的文件）
未跟蹤的文件（即不在版本控制下的新文件）

對于已經(jīng)提交過的文件，如果它們沒有新的未提交改動，git status 將不會報告它們的存在，因為它默認假設那些文件在最新提交的狀態(tài)下是干凈的。

1.4.5 rm

移除文件
從 Git 倉庫中移除文件的方式有兩種：

① 從 Git 倉庫和工作區(qū)中同時移除對應的文件

② 只從 Git 倉庫中移除指定的文件，但保留工作區(qū)中對應的文件

#從 Git 倉庫和工作區(qū)中同時移除 index.js 文件
git rm -f index.js#只從 Git 倉庫中移除 index.css，但保留工作區(qū)中的 index.css 文件
git rm --cached index.css

D 代表已刪除

1.4.6 忽略文件

忽略文件
一般我們總會有些文件無需納入 Git 的管理，也不希望它們總出現(xiàn)在未跟蹤文件列表。 在這種情況下，我們可以創(chuàng)建一個名為 .gitignore 的配置文件，列出要忽略的文件的匹配模式。

文件 .gitignore 的格式規(guī)范如下：

① 以 # 開頭的是注釋

② 以 / 結尾的是目錄

③ 以 / 開頭防止遞歸

④ 以 ! 開頭表示取反

⑤ 可以使用 glob 模式進行文件和文件夾的匹配（glob 指簡化了的正則表達式）

星號 * 匹配零個或多個任意字符
[abc] 匹配任何一個列在方括號中的字符 （此案例匹配一個 a 或匹配一個 b 或匹配一個 c）
問號 ? 只匹配一個任意字符
兩個星號 ** 表示匹配任意中間目錄（比如 a/**/z 可以匹配 a/z 、 a/b/z 或 a/b/c/z 等）
在方括號中使用短劃線分隔兩個字符， 表示所有在這兩個字符范圍內的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的數(shù)字）

1.4. 版本號

每一次Commit對應一個 40 位長的版本號，在對更改內容使用 SHA -1 加密算法后得到的。
這樣，根據(jù)版本號，可以避免內容被篡改。

其次, 根據(jù)版本號的前兩位，在.git/objects 文件夾中，可以找到本次 Commit 的記錄。

1.4. 回退到指定的版本

確切地說，是回退到指定的版本號標識的版本。

因此，必須先要找到指定版本對應的版本號，將其提供給 Git

# 在一行上展示所有的提交歷史，以獲取指定版本的版本號
git log --pretty=oneline# 使用 git reset --hard 命令，根據(jù)指定的提交 ID 回退到指定版本
git reset --hard <CommitID># 在舊版本中使用 git reflog --pretty=oneline 命令，查看命令操作的歷史
git reflog --pretty=onelone# 再次根據(jù)最新的提交 ID，跳轉到最新的版本
git reset --hard <CommitID>

2 .IDEA 集成使用 GitHub（Git同時管理本地倉庫和遠程倉庫）

首先在 IDEA 的設置中綁定 GitHub 的賬號

先創(chuàng)建一個 test1.txt 文件，內容為 aaa.

最上一欄 VCS， SHARE ON GitHub，然后選擇要發(fā)送到遠程倉庫的文件即可。然后去 GitHub，發(fā)現(xiàn)已經(jīng)幫我們創(chuàng)建了一個同名倉庫, 且該倉庫下有一個 test1.txt文件, 文件內容為aaa

2.1 本地文件發(fā)生改變, 同步修改到本地倉庫和遠程倉庫

存在一種情況, 當自己完成代碼的編寫后, 需要將本地的代碼 PUSH 到遠程倉庫中

將文本內容修改為 bbb --> 右鍵文件，GIT，Commit File，填寫必要的備注信息后，可以選擇 Commit （應用更改到本地倉庫）/Commit and Push（應用更改到本地倉庫，且推送到遠程倉庫）

之后, 可以在GH中看到 test1.txt 內容已經(jīng)變?yōu)閎bb

2.2 遠程倉庫發(fā)生改變, 同步修改到本地倉庫

存在一種情況 : 同事將修改過的代碼(ccc) PUSH 到遠程倉庫中, 這樣就和我們本地代碼(bbb)不一致了. 在繼續(xù)工作前, 我們要先 Pull 拉取最新的代碼到本地

為了模擬這種情況, 我們手動在 GH 中, 將文本改為 ccc , 并且 Commit, 這樣 , 遠程倉庫中就是ccc了

右鍵項目, Git --> Pull ,然后選擇需要更新的分支

拉取成功后應當能看到本地文本被修改為了 ccc , 即獲取到了最新的代碼

2.3 完整獲取整個遠程倉庫

存在一種情況 : 第一次接觸該項目, 可能需要將整個項目完整下載到本地, 才能進一步開發(fā)

在 IDEA 中使用 clone 即可, clone會直接創(chuàng)建一個新項目

3.

點擊 Commit ，可以查詢歷史 Commit 記錄。

點擊，可以纖細查看 Commit 信息

3.1 文件操作