這篇文章主要介紹“Git的相關(guān)知識(shí)點(diǎn)有哪些”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Git的相關(guān)知識(shí)點(diǎn)有哪些”文章能幫助大家解決問題。
為寧明等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及寧明網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、寧明網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！
Git 跟其他版本控制系統(tǒng)***的優(yōu)勢(shì)就在于其高級(jí)的分支模型。
Git 允許而且 鼓勵(lì) 你在本地使用多個(gè)完全獨(dú)立的分支。這些分支的創(chuàng)建，合并和刪除幾乎都可以在幾秒內(nèi)完成。
這意味著你可以輕松的做如下操作：
無痛的上下文切換 創(chuàng)建分支試驗(yàn)一個(gè)想法，提交幾次，切回你原來分支的狀態(tài)，應(yīng)用一個(gè)改動(dòng) patch，切回你原來正在試驗(yàn)的狀態(tài)，將剛才應(yīng)用的 patch 合并過來。
基于角色的代碼支線 你可能會(huì)有一個(gè)分支僅僅包含那些只存在于生產(chǎn)環(huán)境上的代碼，另外有一個(gè)獨(dú)立的分支用以合并測(cè)試環(huán)境代碼，還有若干個(gè)更小一些的分支用于日常開發(fā)工作
基于特性的工作流 為每一個(gè)新的特性創(chuàng)建新的分支，你可以方便平滑的在這些分支之間無縫切換，當(dāng)這些特性的改動(dòng)完成的時(shí)候，你可以將其合并入主分支，并把特性分支刪掉。
任意試驗(yàn) 創(chuàng)建一個(gè)分支專門用來試驗(yàn)，當(dāng)覺得試驗(yàn)不理想的時(shí)候，直接刪除掉即可，放棄掉之前的試驗(yàn)內(nèi)容。這時(shí)候不會(huì)有任何其他人察覺到這個(gè)試驗(yàn)（甚至在這期間你還可以推送其他不相關(guān)的分支）
尤其是當(dāng)你推送至遠(yuǎn)程倉庫的時(shí)候，你不必推送所有分支，你可以選擇只推送少數(shù)你愿意分享的分支，當(dāng)然如果你愿意，也可以推送所有分支。這一點(diǎn)傾向于讓開發(fā)者在試驗(yàn)很多新的想法的時(shí)候免除發(fā)布自己的未成熟的試驗(yàn)計(jì)劃的顧慮。
當(dāng)然，也有一些其他的系統(tǒng)可以部分實(shí)現(xiàn)上述的功能和優(yōu)勢(shì)，只是具體的執(zhí)行會(huì)變的困難和容易出錯(cuò)。Git 讓這些工作變得難以置信的簡(jiǎn)單，它在開發(fā)者學(xué)習(xí)其使用的同時(shí)就改變了開發(fā)者的工作模式。
Git 很快。Git 基本上所有的操作都在本地執(zhí)行，這對(duì)于那些必須跟服務(wù)器通信的集中式系統(tǒng)是一個(gè)巨大的速度優(yōu)勢(shì)。
Git 一開始是為了管理 Linux Kernel 的源代碼設(shè)計(jì)的，這意味著他從***天誕生就擁有了處理大型倉庫的高效優(yōu)勢(shì)。Git 使用 C 語言編寫，減輕了使用更高級(jí)別編程語言的 Runtime 帶來的性能損耗。Git 最開始的兩個(gè)重要的設(shè)計(jì)目標(biāo)就是性能和速度。
讓我們看一下與 SVN （一個(gè)通用的集中式存儲(chǔ)版本控制系統(tǒng)，跟 CVS 和 Perforce 很像）相比下的常規(guī)操作的性能測(cè)試指標(biāo)。這里指標(biāo)是值越小，速度越快。
為了測(cè)試，我們?cè)趤嗰R遜的 AWS 的同樣的可用區(qū)上新建了兩個(gè) Large 類型的計(jì)算服務(wù)器實(shí)例。每一個(gè)計(jì)算實(shí)例上都安裝 Git 和 SVN。 我們把 Ruby 的源代碼倉庫拷貝到了 Git 和 SVN 的計(jì)算服務(wù)器示例上，兩者都執(zhí)行通用的操作。
在有些情況下，兩者的命令和實(shí)際效果并不能完全對(duì)應(yīng)起來。在這里，我們?cè)诔Ｓ玫牟僮髦羞x擇相似效果的匹配情況。例如，對(duì)于“提交”的測(cè)試，在 Git 中我們也是計(jì)算 Push 的時(shí)間的。然而在大多數(shù)情況下，你可能實(shí)際上并不會(huì)在提交后馬上就推送到服務(wù)器上，這在 SVN 上是不可分割的操作。
下面表格中所有的時(shí)間單位都是秒。
| 操作 | 描述 | Git | SVN | 性能倍數(shù) |
|---|---|---|---|---|
| 提交文件 (A) | Add, commit and push 113 modified files (2164+, 2259-) | 0.64 | 2.60 | 4x |
| 提交圖片 (B) | Add, commit and push 1000 1k images | 1.53 | 24.70 | 16x |
| 對(duì)比當(dāng)前變動(dòng) | Diff 187 changed files (1664+, 4859-) against last commit | 0.25 | 1.09 | 4x |
| 對(duì)比最近的變動(dòng) | Diff against 4 commits back (269 changed/3609+,6898-) | 0.25 | 3.99 | 16x |
| 對(duì)比標(biāo)簽 | Diff two tags against each other (v1.9.1.0/v1.9.3.0 ) | 1.17 | 83.57 | 71x |
| 提交歷史 (50) | Log of the last 50 commits (19k of output) | 0.01 | 0.38 | 31x |
| 提交歷史 (全部) | Log of all commits (26,056 commits – 9.4M of output) | 0.52 | 169.20 | 325x |
| 提交歷史 (文件) | Log of the history of a single file (array.c – 483 revs) | 0.60 | 82.84 | 138x |
| 更新 | Pull of Commit A scenario (113 files changed, 2164+, 2259-) | 0.90 | 2.82 | 3x |
| Blame | Line annotation of a single file (array.c) | 1.91 | 3.04 | 1x |
你需要注意的是，這已經(jīng)是 SVN ***的運(yùn)行場(chǎng)景了 — 一個(gè)沒有任何負(fù)載的服務(wù)器，客戶端和服務(wù)器之間的網(wǎng)絡(luò)帶寬達(dá)到 80MB/s。上文中的所有指標(biāo)在受網(wǎng)絡(luò)波動(dòng)，或者在一個(gè)更差的網(wǎng)絡(luò)環(huán)境下 SVN 的表現(xiàn)都更差，然而 Git 這邊幾乎所有的指標(biāo)都不受影響。
很明顯，在這些最常用的版本控制工具的操作中，甚至是在SVN 的理想使用環(huán)境下，**Git 在很多方面都大幅領(lǐng)先**。
一個(gè) Git 比 SVN 慢的地方是初始化 clone 倉庫。在這種情況下，Git 是在下載整個(gè)倉庫歷史而不是僅僅是***版本的代碼。上文中的表格所示，僅僅執(zhí)行一次的操作影響并不是很大。
| 操作 | 描述 | Git（Shallow Clone） | Git | SVN |
|---|---|---|---|---|
| Clone | Git Clone 以及 shallow clone(淺 clone) vs SVN checkout | 21.0 | 107.5 | 14.0 |
| 大小(M) | 客戶端在 clone/checkout 后的文件大小 (以 M 為單位) | 181.0 | 132.0 |
另外一個(gè)有趣的點(diǎn)是，Git 和 SVN 在 Clone 或者 Checkout 到本地后的文件大小幾乎差別不大，要知道對(duì)于 Git 來說，本地可是包含了整個(gè)項(xiàng)目歷史。這也展示了 Git 在文件壓縮和存儲(chǔ)上的超高效率。
Git 最棒的特性之一就是分布式。這意味著，你要 clone 整個(gè)倉庫而不是僅僅 checkout 分支的***頭部版本。
在日常的使用場(chǎng)景中 Git 往往有多個(gè)備份。這意味著就算在使用一個(gè)中央存儲(chǔ)式的工作流，每一個(gè)用戶都在本地有一個(gè)服務(wù)器上的完整備份。這里的任意一個(gè)版本都可以在服務(wù)器端數(shù)據(jù)損壞或者丟失的時(shí)候推送回服務(wù)器以挽救損失。事實(shí)上，只要你的倉庫不是只有一個(gè) copy，Git 就不會(huì)存在單點(diǎn)問題。
因?yàn)?Git 擁有分布式特性和極好的分支系統(tǒng)，你可以在此基礎(chǔ)上輕松實(shí)現(xiàn)大量的工作流模型。
Subversion（SVN） 風(fēng)格工作流
集中式存儲(chǔ)的工作流非常常見，特別是對(duì)于那些從傳統(tǒng)的集中式代碼版本管理系統(tǒng)轉(zhuǎn)過來使用 Git 的人。Git 一樣可以提供這種工作形式：每次 Push 必須要更新到遠(yuǎn)程倉庫的***版本。所以說大家還是像以前一樣使用集中式存儲(chǔ)的工作流往同一個(gè)服務(wù)器上 Push 代碼依然沒問題。
另外一個(gè)常見的 Git 工作流是整合工作流。主要的倉庫有一個(gè)單一的開發(fā)者維護(hù)（維護(hù)者）。其他若干開發(fā)者從這個(gè)倉庫 clone，然后推送到他們自己的完全獨(dú)立的倉庫里面，***請(qǐng)求維護(hù)者從主要倉庫 Pull 那些他們?cè)诟髯缘膫}庫里面的改動(dòng)。這種形式往往在 GitHub 上以開源的形式進(jìn)行協(xié)作。
對(duì)于一些更為復(fù)雜的項(xiàng)目來講，像 Linux 內(nèi)核這樣的開發(fā)工作流也是很有效的。在這個(gè)模型中，負(fù)責(zé)人（lieutenants）負(fù)責(zé)整個(gè)項(xiàng)目的一些特定的子系統(tǒng)，他們合并所有跟那個(gè)子系統(tǒng)關(guān)聯(lián)的變動(dòng)。另外一個(gè)維護(hù)者（dictator，字面理解：獨(dú)裁者）只能從他管轄的負(fù)責(zé)人這里獲取變更，并將這些變更推送到主要倉庫。然后所有人都從這個(gè)倉庫獲取更新。
Git 的數(shù)據(jù)模型確保了項(xiàng)目?jī)?nèi)的每一個(gè)字節(jié)，每一個(gè) bit 的一致性。提交的每一個(gè)文件都會(huì)使用校驗(yàn)和計(jì)算摘要，檢出的時(shí)候也使用這個(gè)摘要值。沒有任何可能會(huì)出現(xiàn)從倉庫中獲取的內(nèi)容跟你存儲(chǔ)的內(nèi)容有任何差異。
在不改變 ID（校驗(yàn)和）的情況下也不可能出現(xiàn)改變?nèi)魏挝募?，日期，提交說明或者任何其他在 Git 倉庫中的數(shù)據(jù)。這就意味著，如果你有一個(gè) commit ID，你不但可以確定這個(gè)版本的代碼跟他提交的時(shí)候是一模一樣的，而且這個(gè)版本之前的歷史也沒有發(fā)生任何改變。
大多數(shù)中央存儲(chǔ)的版本控制系統(tǒng)默認(rèn)不提供這樣的校驗(yàn)整合。
不像其他系統(tǒng)， Git 有一個(gè)概念叫做“暫存區(qū)域”或者“index”。這是一個(gè)在提交執(zhí)行之前的臨時(shí)的區(qū)域可以用來格式化和審閱改動(dòng)內(nèi)容的。
一個(gè) Git 優(yōu)于其他系統(tǒng)的功能是我們可以快速的暫存一些改動(dòng)的文件，在工作目錄中只提交部分改動(dòng)的文件，或者文件改動(dòng)的部分內(nèi)容，以及在提交的時(shí)候在命令行里列出改動(dòng)的文件列表。
暫存區(qū)域允許你僅僅暫存部分的文件改動(dòng)，在你意識(shí)到你忘了提交其中一個(gè)文件之前，對(duì)文件進(jìn)行兩個(gè)邏輯上不相關(guān)的修改的日子已經(jīng)一去不復(fù)返了。現(xiàn)在你可以僅僅暫存你當(dāng)前提交需要改動(dòng)的文件，其他的改動(dòng)在下次提交再暫存。這個(gè)特性可以擴(kuò)展到對(duì)文件進(jìn)行的任何更改。
當(dāng)然，Git 也允許你忽略掉暫存區(qū)域這個(gè)過程，你可以輕松的在 commit 命令后面添加 ‘-a’ 選項(xiàng)來直接將所有改動(dòng)提交。Git 會(huì)自動(dòng)幫你先暫存到暫存區(qū)域，再執(zhí)行提交。
關(guān)于“Git的相關(guān)知識(shí)點(diǎn)有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。
重慶分公司
重慶分公司
