? 思考是行動(dòng)的種子?！?愛默生
三層筆記法實(shí)踐步驟：構(gòu)思筆記 → 封存筆記 → 行動(dòng)筆記
行動(dòng)筆記
鼠標(biāo)放置在正文左側(cè)，點(diǎn)擊 “+” 工具欄中的“高亮塊”，高亮你的學(xué)習(xí)感悟
【輸出】將構(gòu)思筆記層中提煉出的需要執(zhí)行的內(nèi)容或最為核心的內(nèi)容上移至行動(dòng)筆記層，每次打開筆記文檔時(shí)都能直指要點(diǎn)。
構(gòu)思筆記
【收集】在構(gòu)思筆記層中寫下即時(shí)想法或大綱，亦或是會(huì)議記錄或你對(duì)學(xué)習(xí)資料的注解
Git入門指南
簡(jiǎn)介
Git是一個(gè)分布式版本控制系統(tǒng)，用于追蹤文件的變更。它允許多個(gè)用戶在不同的系統(tǒng)上協(xié)作工作。
基本概念
版本控制系統(tǒng)（VCS）
一種軟件，用于管理文件的版本和歷史記錄。
分布式版本控制系統(tǒng)（DVCS）
與集中式VCS不同，DVCS（如Git）允許多份完整的代碼庫(kù)副本存在于不同的計(jì)算機(jī)上。
集中式版本控制系統(tǒng)（CVCS）
-
優(yōu)點(diǎn)：簡(jiǎn)單直觀，易于管理和權(quán)限控制。
-
缺點(diǎn)：?jiǎn)吸c(diǎn)故障風(fēng)險(xiǎn)，依賴網(wǎng)絡(luò)連接，備份和恢復(fù)較難。
分布式版本控制系統(tǒng)（DVCS）
-
優(yōu)點(diǎn)：本地操作快速，更靈活的分支管理，更強(qiáng)的抗災(zāi)能力。
-
缺點(diǎn)：學(xué)習(xí)曲線較陡，占用更多資源，可能導(dǎo)致項(xiàng)目過(guò)度分散。
總結(jié)：CVCS適合簡(jiǎn)單、集中管理的場(chǎng)景，而DVCS適用于需要高度靈活性和離線工作能力的復(fù)雜項(xiàng)目。
倉(cāng)庫(kù)（Repository）
存儲(chǔ)代碼的地方，包括所有版本的歷史記錄。
提交（Commit）
一次更改的記錄，包括更改的內(nèi)容和說(shuō)明。
分支（Branch）
代碼的獨(dú)立線路，允許在不影響主線（master）的情況下開發(fā)新功能。
合并（Merge）
將一個(gè)分支的更改合并到另一個(gè)分支上。
常用命令
git init
初始化一個(gè)新的Git倉(cāng)庫(kù)。
git clone [url]
克隆一個(gè)遠(yuǎn)程倉(cāng)庫(kù)到本地。
git add [file]
添加文件到暫存區(qū)。
這是個(gè)多功能命令：可以用它開始跟蹤新文件，或者把已跟蹤的文件放到暫存區(qū)，還能用于合并時(shí)把有沖突的文件標(biāo)記為已解決狀態(tài)等。 將這個(gè)命令理解為“精確地將內(nèi)容添加到下一次提交中”而不是“將一個(gè)文件添加到項(xiàng)目中”要更加合適
git commit -m "[commit message]"
提交更改到倉(cāng)庫(kù)，帶有提交信息。
git branch [branch-name]
創(chuàng)建一個(gè)新的分支。
git checkout [branch-name]
切換到指定分支。
git merge [branch]
合并指定分支到當(dāng)前分支。
git pull
從遠(yuǎn)程倉(cāng)庫(kù)拉取最新更改。
git push
推送本地更改到遠(yuǎn)程倉(cāng)庫(kù)。
工作流程
基本工作流
-
克隆倉(cāng)庫(kù)：獲取遠(yuǎn)程倉(cāng)庫(kù)的副本。
-
創(chuàng)建分支：為新功能或修復(fù)創(chuàng)建一個(gè)新分支。
-
進(jìn)行更改：在本地分支上工作并提交更改。
-
合并分支：完成后，將更改合并回主分支。
團(tuán)隊(duì)合作流程
-
Fork倉(cāng)庫(kù)：創(chuàng)建倉(cāng)庫(kù)的個(gè)人副本。
-
克隆Fork：將Fork倉(cāng)庫(kù)克隆到本地。
-
設(shè)置上游倉(cāng)庫(kù)：連接到原始倉(cāng)庫(kù)以獲取更新。
-
同步更改：定期從上游倉(cāng)庫(kù)拉取更新。
-
推送更改：將提交推送到你的Fork。
-
發(fā)起合并請(qǐng)求（Pull Request）：請(qǐng)求將你的更改合并到原始倉(cāng)庫(kù)。
特性分支工作流
-
為每個(gè)新特性創(chuàng)建分支：保持主分支的穩(wěn)定性。
-
獨(dú)立開發(fā)：在特性分支上進(jìn)行開發(fā)和測(cè)試。
-
代碼審查：在合并前進(jìn)行代碼審查。
-
合并到主分支：開發(fā)完成后，合并到主分支。
最佳實(shí)踐
-
頻繁提交：經(jīng)常提交可以減少丟失工作的風(fēng)險(xiǎn)。
-
清晰的提交信息：寫明確的提交信息有助于理解歷史更改。
-
保持分支同步：定期與主分支同步以避免合并沖突。
-
代碼審查：通過(guò)代碼審查保持代碼質(zhì)量。
結(jié)論
Git是一個(gè)強(qiáng)大的工具，適用于從個(gè)人項(xiàng)目到大型團(tuán)隊(duì)合作。理解其基本概念、常用命令和工作流程對(duì)于有效地使用Git至關(guān)重要。
封存筆記
【整理】隨著“即時(shí)”筆記越來(lái)越多，你可以將構(gòu)思筆記層中多余或不重要的內(nèi)容移動(dòng)到封存筆記層，使構(gòu)思筆記層保留精華內(nèi)容，而封存筆記層可以作為補(bǔ)充信息查看
版本控制系統(tǒng)（VCS）
是一種軟件工具，用于幫助軟件團(tuán)隊(duì)管理項(xiàng)目代碼的變更歷史。主要功能包括：
-
跟蹤變更：記錄文件隨時(shí)間的變化，允許用戶查看過(guò)去的版本。
-
協(xié)同工作：支持多人在同一項(xiàng)目上工作，幫助管理不同人員的貢獻(xiàn)和修改。
-
分支和合并：允許用戶在不影響主項(xiàng)目（主分支）的情況下，獨(dú)立開發(fā)新功能或修復(fù)問(wèn)題（分支），之后可以將這些更改合并回主項(xiàng)目中。
-
錯(cuò)誤定位和修復(fù)：如果引入了錯(cuò)誤，可以快速回溯到引入錯(cuò)誤之前的狀態(tài)。
-
減少?zèng)_突：在多人協(xié)作時(shí)，幫助解決代碼修改的沖突。
集中式版本控制vs分布式版本控制系統(tǒng)
集中式版本控制系統(tǒng)（CVCS）
優(yōu)點(diǎn)
-
簡(jiǎn)單直觀：對(duì)于新手來(lái)說(shuō)，集中式系統(tǒng)通常更易于理解和使用。
-
集中管理：所有文件和歷史記錄存儲(chǔ)在一個(gè)中央服務(wù)器上，便于管理員進(jìn)行管理和控制。
-
易于管理權(quán)限：中央服務(wù)器可以輕松地控制對(duì)代碼庫(kù)的訪問(wèn)權(quán)限。
缺點(diǎn)
-
單點(diǎn)故障：如果中央服務(wù)器發(fā)生故障，整個(gè)系統(tǒng)可能會(huì)癱瘓，直至服務(wù)器恢復(fù)。
-
對(duì)網(wǎng)絡(luò)依賴：團(tuán)隊(duì)成員必須連網(wǎng)才能提交更新或獲取最新版本，限制了離線工作能力。
-
備份和恢復(fù)難度：如果中央服務(wù)器的數(shù)據(jù)丟失且沒有備份，可能導(dǎo)致整個(gè)項(xiàng)目的歷史記錄丟失。
分布式版本控制系統(tǒng)（DVCS）
優(yōu)點(diǎn)
-
本地操作：大多數(shù)操作（如提交、分支、合并）都在本地進(jìn)行，速度快且不依賴網(wǎng)絡(luò)連接。
-
更好的分支處理：分布式系統(tǒng)通常提供更高效和靈活的分支和合并機(jī)制。
-
抗災(zāi)備份：每個(gè)團(tuán)隊(duì)成員都擁有代碼庫(kù)的完整副本，大大減少了數(shù)據(jù)丟失的風(fēng)險(xiǎn)。
缺點(diǎn)
-
初始學(xué)習(xí)曲線較高：相對(duì)于集中式系統(tǒng)，DVCS通常更復(fù)雜，初學(xué)者可能需要更多時(shí)間來(lái)適應(yīng)。
-
資源占用：由于每個(gè)副本都包含完整的歷史記錄，可能占用更多的磁盤空間。
-
可能導(dǎo)致過(guò)度分散：分布式系統(tǒng)中的分支可能過(guò)于分散，需要有效的協(xié)作和溝通策略來(lái)保持項(xiàng)目的整體性。
獲取 Git 項(xiàng)目倉(cāng)庫(kù)主要有兩種方式：
-
將現(xiàn)有目錄轉(zhuǎn)換為 Git 倉(cāng)庫(kù)：
-
進(jìn)入項(xiàng)目目錄（例如，在 Linux 上使用
$ cd /home/user/my_project）。 -
執(zhí)行
$ git init初始化 Git 倉(cāng)庫(kù)，創(chuàng)建.git子目錄，其中包含必要的倉(cāng)庫(kù)文件。 -
使用
git add和git commit命令開始追蹤文件并進(jìn)行初始提交，如$ git add *.c和$ git commit -m 'initial project version'。
-
-
克隆現(xiàn)有的 Git 倉(cāng)庫(kù)：
-
使用
git clone命令獲取現(xiàn)有倉(cāng)庫(kù)的拷貝，例如$ git clone https://github.com/libgit2/libgit2。 -
這會(huì)在當(dāng)前目錄下創(chuàng)建一個(gè)新目錄（如
libgit2），包含.git文件夾和遠(yuǎn)程倉(cāng)庫(kù)的所有數(shù)據(jù)。 -
可以通過(guò)額外參數(shù)自定義本地倉(cāng)庫(kù)名，如
$ git clone https://github.com/libgit2/libgit2 mylibgit。 -
Git 支持多種數(shù)據(jù)傳輸協(xié)議，包括 HTTPS (https://)、Git (git://) 和 SSH (user@server:path/to/repo.git)。
-
練習(xí)總結(jié)
2.2.1檢查當(dāng)前文件狀態(tài)
使用 git status 查看文件狀態(tài)。
-
若倉(cāng)庫(kù)剛克隆完成，通常顯示工作目錄干凈，無(wú)未跟蹤文件。
-
顯示當(dāng)前分支與遠(yuǎn)程分支同步情況。
Git 狀態(tài)輸出:
On branch main：你當(dāng)前在名為
main的分支上。Git 倉(cāng)庫(kù)中可以有多個(gè)分支，而main通常是默認(rèn)的主分支。Your branch is up to date with 'origin/main'.：這意味著你的本地
main分支與遠(yuǎn)程倉(cāng)庫(kù)（通常稱為origin）中的main分支是同步的。換句話說(shuō)，你本地的main分支包含了遠(yuǎn)程main分支上的所有最新更改。nothing to commit, working tree clean：這表明你的工作目錄是干凈的，即你的工作目錄中沒有未跟蹤（untracked）的文件，也沒有已跟蹤（tracked）但未提交（uncommitted）的更改。簡(jiǎn)而言之，你的工作目錄與 Git 的頭指針
HEAD一致，沒有任何更改待提交。綜上所述，這個(gè) Git 狀態(tài)信息告訴你，你當(dāng)前在
main分支上，你的本地倉(cāng)庫(kù)與遠(yuǎn)程倉(cāng)庫(kù)完全同步，并且你的工作目錄中沒有任何未提交或未跟蹤的更改。
創(chuàng)建新文件后的狀態(tài)變化
-
創(chuàng)建新文件（如
README），git status會(huì)顯示該文件為未跟蹤狀態(tài)。 -
未跟蹤文件意味著 Git 在之前的快照中沒有這些文件。
Git 狀態(tài)輸出:
On branch main: 你當(dāng)前在
main分支。Your branch is up to date with 'origin/main'.: 你的本地
main分支與遠(yuǎn)程倉(cāng)庫(kù)origin的main分支同步。Untracked files: 顯示
README文件未被 Git 跟蹤。這意味著該文件是新的或之前未被添加到 Git 倉(cāng)庫(kù)中。(use "git add <file>..." to include in what will be committed): 這是一個(gè)提示，說(shuō)明你可以使用
git add <file>命令來(lái)開始跟蹤這些文件。nothing added to commit but untracked files present (use "git add" to track): 盡管沒有文件被添加到提交（commit）中，但存在未跟蹤的文件。如果你想將這些文件包含在下一個(gè)提交中，需要先使用
git add命令將其添加到暫存區(qū)（staging area）。簡(jiǎn)而言之，你創(chuàng)建或修改了
README文件，但 Git 還沒有開始跟蹤這個(gè)文件。如果你想要將其更改包含在下一個(gè)提交中，你需要先用git add README將其加入暫存區(qū)，然后再進(jìn)行提交。
2.2.2 跟蹤新文件
使用 git add 開始跟蹤文件（如 git add README）。
警告內(nèi)容: 當(dāng)你運(yùn)行
$ git add README時(shí)，出現(xiàn)了一個(gè)警告，指出在工作副本的README文件中，行結(jié)束符 LF（Line Feed，用于 UNIX/Linux 系統(tǒng)）將在 Git 下一次處理該文件時(shí)被 CRLF（Carriage Return Line Feed，用于 Windows 系統(tǒng)）替換。原因: 這通常是由于 Git 的
core.autocrlf配置引起的。在 Windows 系統(tǒng)上，Git 默認(rèn)會(huì)將存儲(chǔ)在倉(cāng)庫(kù)中的 LF 轉(zhuǎn)換為 CRLF，當(dāng)文件被提交或檢出時(shí)，進(jìn)行這種轉(zhuǎn)換。這是為了確保跨平臺(tái)的文件一致性，防止在不同操作系統(tǒng)之間切換時(shí)出現(xiàn)問(wèn)題。處理: 如果你希望保留原始的 LF 行結(jié)束符，可以通過(guò)更改 Git 配置來(lái)禁用這種自動(dòng)轉(zhuǎn)換，使用命令
git config --global core.autocrlf input。
文件被添加到暫存區(qū)后，git status 顯示文件處于待提交狀態(tài)。
Git 狀態(tài)信息:
當(dāng)前分支: 你在
main分支上，且與遠(yuǎn)程origin/main分支同步。更改待提交:
README文件被標(biāo)記為新文件，并已添加到暫存區(qū)（staging area），準(zhǔn)備進(jìn)行下一次提交。如何取消暫存: 如果你想取消暫存
README文件，可以使用git restore --staged <file>命令。這些信息表明，你已經(jīng)成功將新文件
README添加到了 Git 的暫存區(qū)，并準(zhǔn)備好進(jìn)行提交。
總結(jié)
-
已暫存狀態(tài)（Staged State）:
-
當(dāng)文件顯示在 "Changes to be committed" 下時(shí)，這意味著這些文件已經(jīng)被暫存。
-
暫存文件是準(zhǔn)備被記錄在下一個(gè)提交（commit）中的文件。也就是說(shuō)，這些文件的當(dāng)前狀態(tài)（你最后一次使用
git add時(shí)的狀態(tài)）將被包含在接下來(lái)的提交中。
-
-
git add的作用:-
git add命令用于開始跟蹤新文件或?qū)⒁迅牡奈募浦習(xí)捍鎱^(qū)。 -
這個(gè)命令不僅用于添加單個(gè)文件，還可以用于添加目錄。當(dāng)用于目錄時(shí)，Git 會(huì)遞歸地將該目錄下的所有更改加入暫存區(qū)。
-
git add是一種預(yù)提交（pre-commit）步驟，它告訴 Git 你想在下一個(gè)提交中包含哪些更改。
-
-
提交過(guò)程（Committing Process）:
-
執(zhí)行
git commit命令會(huì)將暫存區(qū)域中的更改記錄到 Git 歷史中。 -
只有在暫存區(qū)域中的更改才會(huì)被提交。如果你在
git add后對(duì)文件進(jìn)行了更多的更改，這些新更改不會(huì)包含在即將進(jìn)行的提交中，除非你再次執(zhí)行git add。
-
-
使用
git init和git add:-
git init用于初始化一個(gè)新的 Git 倉(cāng)庫(kù)。 -
在一個(gè)新倉(cāng)庫(kù)中，使用
git add開始跟蹤文件是一個(gè)常見的首步操作。
-
2.2.3 暫存已修改的文件
修改已跟蹤文件（如 CONTRIBUTING.md），git status 顯示修改未暫存。
-
使用
git add暫存修改。 -
若修改文件后再次修改，需要重新運(yùn)行
git add。
狀態(tài)簡(jiǎn)覽
-
git status -s或git status --short提供簡(jiǎn)潔的狀態(tài)輸出。 -
未跟蹤文件前有
??，已暫存文件前有A，修改過(guò)的文件前有M。 -
左欄顯示暫存區(qū)狀態(tài)，右欄顯示工作區(qū)狀態(tài)。
2.2.4 忽略文件
.gitignore 文件在 Git 倉(cāng)庫(kù)中用于指定應(yīng)該忽略的文件和目錄，以避免將它們加入到版本控制中。這通常包括編譯生成的文件、日志文件或編輯器臨時(shí)文件等。
.gitignore 文件的基本規(guī)則
-
忽略特定文件類型：使用模式如
*.[oa]來(lái)忽略所有.o和.a結(jié)尾的文件。 -
忽略臨時(shí)文件：使用
*~忽略編輯器生成的臨時(shí)文件。 -
忽略特定目錄：例如，使用
log/,tmp/,pid/忽略這些目錄及其內(nèi)容。 -
空行和注釋：以
#開頭的行作為注釋，被 Git 忽略。 -
使用 glob 模式：支持簡(jiǎn)化的正則表達(dá)式來(lái)匹配文件路徑。
高級(jí) .gitignore 配置
-
防止遞歸：以
/開頭的模式防止遞歸匹配。 -
指定目錄：以
/結(jié)尾的模式指定目錄。 -
取反匹配：使用
!對(duì)特定模式取反，例如!lib.a。
.gitignore 文件的實(shí)際應(yīng)用
-
可以創(chuàng)建針對(duì)項(xiàng)目和語(yǔ)言特定的
.gitignore文件。 -
GitHub 提供了一個(gè)廣泛的
.gitignore模板庫(kù)：github/gitignore。 -
.gitignore文件可以在倉(cāng)庫(kù)的根目錄中使用，也可以在子目錄中使用，僅應(yīng)用于該目錄。
注意事項(xiàng)
-
子目錄中的
.gitignore文件僅影響其所在目錄。 -
對(duì)于復(fù)雜的項(xiàng)目，可能存在多個(gè)
.gitignore文件。 -
詳細(xì)的
.gitignore配置可以通過(guò)man gitignore查看。 -
更多細(xì)節(jié)可參考
man gitignore或 GitHub 的 .gitignore 文件列表。
通過(guò)適當(dāng)配置 .gitignore 文件，可以確保倉(cāng)庫(kù)中不包含不必要的文件，從而使倉(cāng)庫(kù)保持清潔和組織有序。
2.2.5 查看已暫存和未暫存的修改
使用 git status 檢查文件狀態(tài)
你通?？赡軙?huì)用它來(lái)回答這兩個(gè)問(wèn)題：當(dāng)前做的哪些更新尚未暫存？ 有哪些更新已暫存并準(zhǔn)備好下次提交？
-
git status顯示哪些文件已暫存，哪些未暫存。 -
列出的文件名指示文件是否準(zhǔn)備提交（已暫存）或有更改但未暫存。
使用 git diff 查看具體修改
-
git diff顯示未暫存文件的具體更改。 -
顯示工作目錄中的當(dāng)前文件與暫存區(qū)快照之間的差異。
查看已暫存的更改
-
使用
git diff --staged查看已暫存文件的更改（--staged和--cached是同義詞）。 -
比較已暫存文件與最后一次提交的文件差異。
處理多次修改的文件
-
對(duì)已暫存文件再次修改后，
git status會(huì)顯示該文件在暫存區(qū)和工作目錄中的狀態(tài)。 -
git diff顯示最近的更改（自上次暫存以來(lái)的更改）。 -
git diff --cached顯示已暫存的更改。
2.2.6 提交更新
現(xiàn)在的暫存區(qū)已經(jīng)準(zhǔn)備就緒，可以提交了。 在此之前，請(qǐng)務(wù)必確認(rèn)還有什么已修改或新建的文件還沒有 git add 過(guò)， 否則提交的時(shí)候不會(huì)記錄這些尚未暫存的變化。 這些已修改但未暫存的文件只會(huì)保留在本地磁盤。 所以，每次準(zhǔn)備提交前，先用 git status 看下，你所需要的文件是不是都已暫存起來(lái)了， 然后再運(yùn)行提交命令 git commit：
準(zhǔn)備提交
-
確認(rèn)所需文件已經(jīng)暫存。
-
使用
git commit啟動(dòng)文本編輯器以輸入提交信息。
提交信息的格式
-
編輯器中的默認(rèn)信息包含
git status的輸出和注釋行。 -
提交時(shí)，Git 會(huì)忽略注釋行。
快速提交
-
可以使用
git commit -m直接在命令行中提供提交信息。 -
提交后，Git 提供關(guān)于新提交的信息，如所在分支、SHA-1 校驗(yàn)和、變更概述。
提交的影響
-
提交記錄的是暫存區(qū)的快照。
-
未暫存的更改不會(huì)包含在提交中，但保留在工作目錄。
確保所有必要的更改都已暫存是進(jìn)行提交之前的一個(gè)關(guān)鍵步驟。以下是這個(gè)過(guò)程的詳細(xì)說(shuō)明：
-
檢查當(dāng)前狀態(tài)：
-
使用
git status命令來(lái)查看當(dāng)前的工作狀態(tài)。 -
這個(gè)命令會(huì)顯示所有已跟蹤的文件中自上次提交以來(lái)的更改，包括已暫存（staged）和未暫存（unstaged）的更改。
-
-
暫存更改：
-
如果發(fā)現(xiàn)有需要提交的文件還沒暫存，使用
git add [file]命令將這些文件添加到暫存區(qū)。 -
對(duì)于新建的文件或已修改的文件都需要執(zhí)行這個(gè)操作。
-
-
重新檢查狀態(tài)：
-
再次運(yùn)行
git status確保所有需要的更改都已暫存。 -
確認(rèn)沒有遺漏的文件或更改。
-
-
進(jìn)行提交：
-
所有必要的更改一旦暫存，就可以使用
git commit命令來(lái)提交這些更改。 -
在提交時(shí)，通常會(huì)打開文本編輯器讓你輸入提交信息。可以使用
git commit -m "commit message"來(lái)提供簡(jiǎn)短的提交信息。
-
通過(guò)這個(gè)流程，你可以確保所有重要的更改都被記錄在版本歷史中。這也有助于維護(hù)項(xiàng)目的清晰歷史記錄和促進(jìn)有效的團(tuán)隊(duì)協(xié)作。記住，任何未暫存的更改都不會(huì)包含在提交中，這些更改將保留在你的本地工作目錄中。
2.2.7 跳過(guò)使用暫存區(qū)域
-
使用
git commit -a可以跳過(guò)git add步驟，直接提交所有已跟蹤文件的更改。 -
這個(gè)命令會(huì)自動(dòng)暫存所有已跟蹤文件的修改，然后提交。
-
注意：該命令不會(huì)暫存新文件（未被跟蹤的文件）。
2.2.8 移除文件
-
使用
git rm可以從暫存區(qū)和工作目錄中刪除文件。 -
如果只是從工作目錄中刪除文件，不使用
git rm，Git 會(huì)將這些文件標(biāo)記為已刪除但未暫存。 -
強(qiáng)制刪除選項(xiàng)
-f用于刪除已修改或已暫存的文件。 -
使用
git rm --cached從 Git 中刪除文件，但在本地保留文件。
2.2.9 移動(dòng)文件
-
Git 使用
git mv命令來(lái)重命名文件。 -
實(shí)際上，
git mv相當(dāng)于運(yùn)行了mv（移動(dòng)或重命名文件），git rm（刪除舊文件名），和git add（添加新文件名）。 -
Git 并不顯式跟蹤文件移動(dòng)操作，但會(huì)智能地推斷出文件已重命名。
相關(guān)學(xué)習(xí)資源
在這里給大家推薦幾個(gè)學(xué)習(xí)Git的資源，希望可以幫助大家在未來(lái)對(duì)Git有著更深的了解。
-
Git Book
-
廖雪峰Git教程
-
Git權(quán)威指南
-
freenode
-
Github-cheat-sheet
-
動(dòng)手學(xué)Git文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-807897.html
-
learn git branching，動(dòng)手實(shí)踐類文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-807897.html
到了這里，關(guān)于Datawhale學(xué)習(xí)git-第一節(jié)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
