關於
分支和合併
讓 Git 真正與其他幾乎所有 SCM 脫穎而出的功能，是其分支模型。
Git 允許並鼓勵您擁有多個可以完全獨立於彼此的本機分支。建立、合併和刪除這些開發線只需幾秒鐘。
這表示您可以執行下列操作
- 無摩擦情境切換。建立一個分支來嘗試一個想法，提交幾次，切換回您分支的來源，套用一個修補程式，切換回您正在實驗的分支，並將其合併。
- 基於角色的程式碼規範。有一個分支始終只包含進入生產環境的內容，另一個分支您會將工作合併進去以進行測試，還有幾個較小的分支用於日常工作。
- 基於功能的工作流程。為您正在開發的每個新功能建立新的分支，以便您可以在它們之間無縫切換，然後在該功能合併到您的主線時刪除每個分支。
- 一次性實驗。建立一個分支來進行實驗，發現它無法運作，然後就刪除它，放棄工作，而且沒有其他人會看到它（即使您在此同時推送到其他分支）。
值得注意的是，當您推送到遠端儲存庫時，您不必推送所有分支。您可以選擇只分享其中一個分支、幾個分支或全部分支。這傾向於讓人們在嘗試新想法時不必擔心如何以及何時合併或與他人分享而感到自由。
有一些方法可以使用其他系統來完成其中一些工作，但所涉及的工作困難得多，而且容易出錯。Git 使這個過程變得難以置信的容易，而且當大多數開發人員學習它時，它會改變他們的工作方式。
小巧且快速
Git 很快速。使用 Git，幾乎所有操作都是在本地執行，這讓它在必須持續與某個地方的伺服器通訊的集中式系統上具有極大的速度優勢。
Git 是為了在 Linux 核心上工作而建構的，這表示它從第一天開始就必須有效地處理大型儲存庫。Git 是用 C 編寫的，減少了與較高階語言相關的執行時間開銷。速度和效能一直是 Git 從一開始的主要設計目標。
基準測試
讓我們看看常見的操作與 Subversion（一個類似於 CVS 或 Perforce 的常見集中式版本控制系統）相比如何。較小表示較快。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
為了進行測試，在同一個可用性區域中設定了大型 AWS 執行個體。Git 和 SVN 都安裝在兩台機器上，Ruby 儲存庫被複製到 Git 和 SVN 伺服器，而且在兩者上執行了常見的操作。
在某些情況下，命令並不完全匹配。在此，嘗試匹配最低公分母。例如，「提交」測試也包括 Git 推送的時間，儘管在 SVN 中無法將這兩個命令分開，但大多數時候您不會在提交後立即推送到伺服器。
所有這些時間均以秒為單位。
| 操作 | Git | SVN | ||
|---|---|---|---|---|
| 提交檔案 (A) | 新增、提交並推送 113 個已修改檔案 (2164+，2259-) | 0.64 | 2.60 | 4 倍 |
| 提交影像 (B) | 新增、提交並推送一千個 1 KB 影像 | 1.53 | 24.70 | 16 倍 |
| 差異目前 | 與上次提交比較 187 個已變更檔案 (1664+，4859-) | 0.25 | 1.09 | 4 倍 |
| 差異最近 | 與 4 次提交前比較 (269 已變更/3609+，6898-) | 0.25 | 3.99 | 16 倍 |
| 差異標籤 | 彼此比較兩個標籤 (v1.9.1.0/v1.9.3.0) | 1.17 | 83.57 | 71 倍 |
| 記錄 (50) | 最後 50 次提交的記錄 (19 KB 輸出) | 0.01 | 0.38 | 31 倍 |
| 記錄 (全部) | 所有提交的記錄 (26,056 次提交 – 9.4 MB 輸出) | 0.52 | 169.20 | 325 倍 |
| 記錄 (檔案) | 單一檔案歷程記錄 (array.c – 483 次修訂) | 0.60 | 82.84 | 138 倍 |
| 更新 | 提取提交 A 場景 (113 個檔案已變更，2164+，2259-) | 0.90 | 2.82 | 3 倍 |
| 責怪 | 單一檔案 (array.c) 的行註解 | 1.91 | 3.04 | 1 倍 |
請注意，這是 SVN 的最佳情況場景，也就是伺服器沒有負載，且與用戶端電腦之間的連線為千兆位元。如果連線速度較慢，這些時間幾乎都會對 SVN 造成更糟的影響，而許多 Git 時間則不受影響。
顯然，在許多這些常見的版本控制操作中，Git 比 SVN 快一到兩個數量級，即使在 SVN 的理想條件下也是如此。
Git 較慢的地方在於初始複製操作。在此，Git 會下載整個歷程，而不會只下載最新版本。如上表所示，對於只執行一次的操作來說，它並不會慢很多。
| 操作 | Git* | Git | SVN | |
|---|---|---|---|---|
| 複製 | Git 中的複製和淺層複製(*) 與 SVN 中的檢出 | 21.0 | 107.5 | 14.0 |
| 大小 (MB) | 複製/檢出後總客戶端資料和檔案的大小 (MB) | 181.0 | 132.0 |
值得注意的是，即使 Git 也擁有專案整個歷史中每個檔案的每個版本，但客戶端上的資料大小非常相似。這說明了它在客戶端壓縮和儲存資料的效率。
分散式
任何分散式 SCM 的其中一項最棒的功能，包括 Git，就是它具有分散式。這表示您並非「檢出」原始碼的目前提示，而是「複製」整個儲存庫。
多重備份
這表示即使您使用的是集中式工作流程，每個使用者基本上都擁有主伺服器的完整備份。每個副本都可以向上推送，以在發生故障或損毀時取代主伺服器。實際上，除非儲存庫只有一個副本，否則 Git 沒有單一故障點。
任何工作流程
由於 Git 的分散式本質和絕佳的分支系統，因此可以相對輕鬆地實作幾乎無窮無盡的工作流程。
Subversion 風格的工作流程
集中式工作流程非常常見，特別是從集中式系統轉換過來的人。自從您上次擷取後，如果有人已推送，Git 將不允許您推送，因此所有開發人員都推送至同一伺服器的集中式模型運作良好。
整合管理員工作流程
另一個常見的 Git 工作流程會涉及整合管理員，也就是負責提交到「已驗證」儲存庫的單一使用者。接著，許多開發人員會從該儲存庫複製，推送到他們自己的獨立儲存庫，並要求整合管理員將他們的變更拉入。這是開放原始碼或 GitHub 儲存庫常見的開發模式。
獨裁者與副手工作流程
對於更龐大的專案，類似 Linux 核心開發工作流程通常很有效。在此模式中，某些人員（「副手」）負責專案的特定子系統，並合併所有與該子系統相關的變更。另一位整合管理員（「獨裁者」）只能從他的副手中拉取變更，然後推送到「已驗證」儲存庫，接著所有人都會再次從中複製。
資料保證
Git 使用的資料模式可確保專案中每個位元的加密完整性。每個檔案和提交都會進行檢查和，並在簽出時透過其檢查和來擷取。除了「您輸入的精確位元」之外，不可能從 Git 中取得任何東西。
在不變更其後續所有項目的 ID 的情況下，也不可能變更 Git 儲存庫中的任何檔案、日期、提交訊息或任何其他資料。這表示如果您有提交 ID，您可以確信您的專案不僅與提交時完全相同，而且其歷程記錄中沒有任何變更。
大多數集中式版本控制系統預設不提供此類完整性。
暫存區
與其他系統不同，Git 有個稱為「暫存區」或「索引」的東西。這是個在完成提交前可以格式化和檢閱提交的暫存區域。
Git 與其他工具不同的一點是，它可以快速暫存一些檔案並提交它們，而無需提交工作目錄中所有其他已修改的檔案，或在提交期間在命令列中列出它們。
這允許您僅暫存已修改檔案的一部分。在您意識到忘記提交其中一個檔案之前，對檔案進行兩個邏輯上無關的修改的日子已經一去不復返了。現在，您只需暫存當前提交所需的變更，並暫存下一次提交的其他變更。此功能可根據需要擴展到檔案的許多不同變更。
當然，如果您不想要這種控制，Git 也讓您可以輕鬆忽略此功能——只需在提交命令中新增「-a」，即可將所有檔案的所有變更新增到暫存區。
免費且開放原始碼
Git 在 GNU 通用公共授權版本 2.0 下發布，這是一個 開放原始碼授權。Git 專案選擇使用 GPLv2 來保證您分享和變更免費軟體的自由——確保該軟體對所有使用者都是免費的。
GIT 商標政策
1 目的
Git 專案是軟體自由保護協會（「保護協會」）的成員專案。保護協會根據其非營利慈善使命，代表 Git 專案持有商標權利。
保護協會採用此政策，以保護商標（定義如下）並確保 Git 軟體的身分及其自由和開放原始碼的性質對所有人來說都很明確。透過使用此政策，Git 專案可以在確保商標受到美國商標法（美國註冊編號 4680534）保護的方式下，擴展 Git 軟體的使用。此政策旨在允許所有明確且適當的使用商標，同時禁止以可能讓使用者混淆軟體來源或暗示與 Git 專案有其他不存在關聯的方式使用商標。透過遵守此政策，您有助於向大眾宣傳自由使用和開發 Git 軟體。
在整個政策中，「商標」一詞是指下列事項
文字商標「Git」
顯示並可在 https://git.dev.org.tw/downloads/logos 下載的標誌和圖形商標
標語「愚蠢的內容追蹤器」
此政策僅涉及與 Git 專案相關的商標，不涉及與 Git 軟體相關的任何著作權。
2 使用商標的準則
2.1 首次提及時加上商標符號
首次顯著提及商標時，應立即加上註冊商標 (®) 或未註冊商標 (™) 符號。例如：「Git™」。
在不需要此類商標來保護與商標相關的智慧財產權的所有情況下，例如電子郵件、線上討論和學術論文，均可免除此項要求。我們鼓勵在可能的情況下使用適用的符號，但承認許多使用者會在非商業和非正式場合中省略這些符號。
當您需要在例如他人持有的商標清單中提到「Git」時，可以使用「Git 和 Git 標誌是 Software Freedom Conservancy, Inc. 的註冊商標或商標，Git Project 的公司所在地，在美國和/或其他國家/地區。」
2.2 未經書面許可使用標誌
您可以在未經事先書面許可的情況下使用標誌（受其他部分約束）
以實質上未修改的形式參考 Git 軟體。「實質上未修改」表示從 Git Project 提供的原始碼建置，可能包含次要修改，包括但不限於：預設啟用或停用特定功能、翻譯成其他語言、與特定作業系統發行版相容性所需的變更，或包含錯誤修正程式。
將 Git 軟體識別為軟體產品的特定元件。
實際上參考 Git Project 本身、其產品或其協定。
此外，您可以在未經書面許可的情況下在以下情況中使用標誌來參考 Git 軟體和 Git Project 以外的產品、服務或社群
- 在參考實質上未修改的 Git 軟體時，表示該軟體是 Git 的「衍生品」或「基於」Git。
- 在格式為「[產品名稱] for Git」中參考與 Git 軟體互通的第三方軟體產品和/或服務時，前提是此類使用方式符合本政策的其他部分。
我們不會對在這些情況下使用標誌的授權收取費用。但是，我們當然歡迎捐款。如果您有興趣捐款給 Git Project，請透過 Conservancy 拜訪 https://git.dev.org.tw/sfc。Conservancy 是美國 501(c)(3) 公益慈善機構。
2.3 標誌的禁止使用方式
您不得以下列方式使用標誌
以任何可能導致混淆 Git 計畫身分、其軟體來源或軟體授權的方式。
以任何表示您與 Git 計畫之間的關聯程度大於實際情況的方式。
以任何暗示 Git 已指定繼承者的方式（例如，不允許使用「Git++」）。
以任何表示 Git 偏好某個發行版、平台、產品等，但 Conservancy 明文表示例外的情況除外。
以任何其他淡化或侵犯 Conservancy 和 Git 計畫在商標中的商標權的方式。
指稱已由第三方修改到無法與未經大幅修改的 Git 軟體互通的 Git 軟體。
此外，未經 Conservancy 書面許可，您不得將任何商標用作新字詞中的音節或合成詞的一部分（例如，「Gitalicious」、「Gitpedia」）作為第三方產品或服務的商標。為避免疑義，即使第三方商標將商標用作音節或合成詞的一部分來指稱產品或服務使用 Git 程式碼，此規定仍適用。
2.4 本政策的限制
本政策不授予使用「軟體自由保護協會」、「保護協會」商標或使用第 1 節所列商標以外任何其他商標的權利。本政策不授權您代表保護協會行事、代表 Git 計畫或保護協會簽訂任何協議或以其他方式承擔任何責任。
2.5 在商品中使用商標
未經 Conservancy 明確書面許可，您不得製作和/或銷售帶有任何商標的商品。如果您有興趣製作和/或銷售帶有任何商標的商品，請將您的設計證明寄送至 [email protected]。
3 Conservancy 保留的權利
Conservancy 保留以下專屬權利
決定是否遵守此政策。
以符合其保護公眾任務的方式修改此政策。
對此政策授予例外，無論任何種類和任何理由，其他條款概不受影響。
4 個問題
此政策旨在確保標誌安全，以保護此軟體的聲譽，此聲譽是 Git 專案對自由和開放原始碼社群以及廣大公眾的貢獻所換來的。如果您在任何地方看到任何您認為違反此政策或與 Git 專案和 Conservancy 任務精神相違背的標誌使用方式，請透過 [email protected] 與我們聯絡，將其告知 Conservancy。
如果您對使用標誌有任何疑問，或者您認為您應該能夠將標誌用於此政策不允許的任何目的，並且希望獲得該使用許可，請透過寄送電子郵件至 [email protected] 或寫信至 Git Project c/o Software Freedom Conservancy，137 Montague St. Ste 380，Brooklyn，NY 11201-3548 與 Conservancy 聯絡。
