設定與配置
取得與建立專案
基本快照
分支與合併
分享與更新專案
檢查與比較
修補
除錯
電子郵件
外部系統
伺服器管理
指南
- gitattributes
- 命令列介面慣例
- 日常 Git
- 常見問題 (FAQ)
- 詞彙表
- 掛勾 (Hooks)
- gitignore
- gitmodules
- 修訂版本
- 子模組
- 教學
- 工作流程
- 所有指南...
管理
底層命令
- 2.41.1 → 2.47.0 無變更
-
2.41.0
06/01/23
- 2.38.1 → 2.40.3 無變更
-
2.38.0
10/02/22
- 2.36.1 → 2.37.7 無變更
-
2.36.0
04/18/22
- 2.34.1 → 2.35.8 無變更
-
2.34.0
11/15/21
- 2.33.2 → 2.33.8 無變更
-
2.33.1
10/12/21
- 2.29.1 → 2.33.0 無變更
-
2.29.0
10/19/20
- 2.25.1 → 2.28.1 無變更
-
2.25.0
01/13/20
- 2.18.1 → 2.24.4 無變更
-
2.18.0
06/21/18
- 2.9.5 → 2.17.6 無變更
-
2.8.6
07/30/17
- 2.1.4 → 2.7.6 無變更
-
2.0.5
12/17/14
概要
git bundle create [-q | --quiet | --progress] [--version=<version>] <file> <git-rev-list-args> git bundle verify [-q | --quiet] <file> git bundle list-heads <file> [<refname>…] git bundle unbundle [--progress] <file> [<refname>…]
說明
建立、解開和操作「bundle」檔案。Bundle 用於「離線」傳輸 Git 物件,而無需在網路連線的另一端有作用中的「伺服器」。
它們可用於建立儲存庫的增量和完整備份,並將一個儲存庫中的參考狀態傳遞到另一個儲存庫。
透過 ssh://
和 https://
等協定擷取或以其他方式「讀取」的 Git 命令也可以在 bundle 檔案上運作。可以從 bundle 使用 git-clone[1] 來複製新的儲存庫,使用 git-fetch[1] 從中擷取,並使用 git-ls-remote[1] 列出其中包含的參考。沒有相對應的「寫入」支援,即不支援 git push 到 bundle 中。
請參閱下方的「範例」章節,瞭解如何使用 bundle 的範例。
BUNDLE 格式
Bundle 是 .pack
檔案(請參閱 git-pack-objects[1]),其中包含標頭,指示 bundle 中包含哪些參考。
與壓縮封存格式本身一樣,bundle 可以是獨立的,也可以使用排除項來建立。請參閱下方的「物件先決條件」章節。
使用修訂排除項建立的 Bundle 是使用 git-pack-objects[1] 的 --thin
選項建立的「精簡壓縮檔」,並使用 git-index-pack[1] 的 --fix-thin
選項來解開。
使用修訂排除項時,無法建立「厚壓縮檔」的選項,使用者不應擔心差異。透過使用「精簡壓縮檔」,使用排除項建立的 bundle 大小會比較小。它們在底層是「精簡」的,這裡僅作為好奇心,以及作為其他文件的參考。
如需更多詳細資訊,請參閱 gitformat-bundle[5],以及 gitformat-pack[5] 中關於「精簡壓縮檔」的討論以取得更多詳細資訊。
選項
- create [選項] <檔案> <git-rev-list-args>
-
用於建立名為 檔案 的 bundle。這需要 <git-rev-list-args> 引數來定義 bundle 內容。選項 包含 git bundle create 子命令特定的選項。如果 檔案 是
-
,則 bundle 會寫入標準輸出。 - verify <檔案>
-
用於檢查 bundle 檔案是否有效,且是否能乾淨地套用至目前的儲存庫。這包括檢查 bundle 格式本身,以及檢查先決條件的 commit 是否存在,且是否完全連結在目前的儲存庫中。然後,git bundle 會列印遺失的 commit 清單(如果有的話)。最後,會列印關於額外功能的資訊,例如「物件篩選器」。如需更多資訊,請參閱 gitformat-bundle[5] 中的「功能」。如果成功,則結束代碼為零,但如果 bundle 檔案無效,則結束代碼為非零。如果 檔案 是
-
,則會從標準輸入讀取 bundle。 - list-heads <檔案>
-
列出 bundle 中定義的參考。如果後面跟著參考清單,則只會列印符合所提供參考的參考。如果 檔案 是
-
,則會從標準輸入讀取 bundle。 - unbundle <檔案>
-
將 bundle 中的物件傳遞至 git index-pack 以儲存在儲存庫中,然後列印所有已定義參考的名稱。如果提供參考清單,則只會列印符合清單中參考的參考。此命令實際上是底層命令,僅供 git fetch 呼叫。如果 檔案 是
-
,則會從標準輸入讀取 bundle。 - <git-rev-list-args>
-
一個引數清單,可接受 git rev-parse 和 git rev-list(並且包含具名參考,請參閱下方的「指定參考」),指定要傳輸的特定物件和參考。例如,
master~10..master
會將目前的 master 參考與自其第 10 個祖先 commit 以來新增的所有物件封裝在一起。可封裝的參考和物件數量沒有明確限制。 - [<參考名稱>…]
-
用於限制回報為可用參考的參考清單。這主要是供 git fetch 使用,它只會接收所要求的參考,而不一定會接收壓縮檔中的所有內容(在此情況下,git bundle 的作用類似於 git fetch-pack)。
- --progress
-
預設情況下,當進度狀態附加到終端時,會報告在標準錯誤串流上,除非指定 -q。即使標準錯誤串流未導向終端,此旗標也會強制顯示進度狀態。
- --version=<版本>
-
指定 bundle 版本。版本 2 是較舊的格式,只能與 SHA-1 儲存庫搭配使用;較新的版本 3 包含允許擴充的功能。預設值是基於所使用雜湊演算法的最舊支援格式。
- -q
- --quiet
-
此旗標會使命令不會在標準錯誤串流上報告其進度。
指定參考
修訂版本必須隨附參考名稱才能封裝在 bundle 中。
可以封裝多個參考,並且可以指定多個先決條件物件集。封裝的物件是不包含在先決條件聯集中。
git bundle create 命令會使用與 git rev-parse --abbrev-ref=loose
相同的規則為您解析參考名稱。每個先決條件都可以明確指定(例如 ^master~10
),或隱含指定(例如 master~10..master
、--since=10.days.ago master
)。
所有這些簡單案例都沒問題(假設我們有「master」和「next」分支)
$ git bundle create master.bundle master $ echo master | git bundle create master.bundle --stdin $ git bundle create master-and-next.bundle master next $ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
這些也沒問題(以及省略 --stdin
的相同範例)
$ git bundle create recent-master.bundle master~10..master $ git bundle create recent-updates.bundle master~10..master next~5..next
無法將修訂名稱或範圍的右側解析為參考,因此不會接受
$ git bundle create HEAD.bundle $(git rev-parse HEAD) fatal: Refusing to create empty bundle. $ git bundle create master-yesterday.bundle master~10..master~5 fatal: Refusing to create empty bundle.
物件先決條件
建立 bundle 時,可以建立獨立的 bundle,可以在沒有共同歷史的儲存庫中解開,並提供負修訂版本來排除歷史較早部分中需要的物件。
將 new
之類的修訂版本饋送至 git bundle create
,將會建立一個 bundle 檔案,其中包含從修訂版本 new
可存取的所有物件。該 bundle 可以在任何儲存庫中解開,以取得通往修訂版本 new
的完整歷史記錄
$ git bundle create full.bundle new
諸如 old..new
之類的修訂版本範圍,將會產生一個 bundle 檔案,該檔案將需要修訂版本 old
(以及從其可存取的所有物件)存在,才能「解開」bundle
$ git bundle create full.bundle old..new
一個自包含的套件,無需任何先決條件,可以提取到任何地方,甚至是空的儲存庫,或者從中克隆(即使用 new
,而不是 old..new
)。
為了謹慎起見,套件檔案包含目的地已經存在的物件是沒關係的,因為這些物件在目的地解壓縮時會被忽略。
如果您想要符合 git clone --mirror
的行為,其中會包含您的參考,例如 refs/remotes/*
,請使用 --all
。如果您想要提供與直接從來源儲存庫克隆時取得的相同參考集,請為 <git-rev-list-args>
使用 --branches --tags
。
git bundle verify 命令可用於檢查您的接收者儲存庫是否具有套件所需的先決條件提交。
範例
假設您想要將機器 A 上的儲存庫 R1 的歷史記錄傳輸到機器 B 上的另一個儲存庫 R2。由於某些原因,不允許 A 和 B 之間直接連接,但我們可以通過某種機制(CD、電子郵件等)將資料從 A 移動到 B。我們想要使用 R1 中 master 分支上所做的開發來更新 R2。
要引導此過程,您可以首先建立一個沒有任何先決條件的套件。您可以使用標籤來記住您上次處理到哪個提交,以便輕鬆地稍後使用增量套件更新另一個儲存庫。
machineA$ cd R1 machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master
然後,您將 file.bundle 傳輸到目標機器 B。由於此套件不需要提取任何現有物件,您可以在機器 B 上通過從中克隆來建立一個新的儲存庫。
machineB$ git clone -b master /home/me/tmp/file.bundle R2
這將在產生的儲存庫中定義一個名為 "origin" 的遠端,讓您可以從套件中提取和拉取。R2 中的 $GIT_DIR/config 檔案將會有類似這樣的條目:
[remote "origin"] url = /home/me/tmp/file.bundle fetch = refs/heads/*:refs/remotes/origin/*
要更新產生的 mine.git 儲存庫,您可以將儲存在 /home/me/tmp/file.bundle 的套件替換為增量更新後,再提取或拉取。
在原始儲存庫中進行更多工作後,您可以建立一個增量套件來更新另一個儲存庫
machineA$ cd R1 machineA$ git bundle create file.bundle lastR2bundle..master machineA$ git tag -f lastR2bundle master
然後,您將套件傳輸到另一台機器以替換 /home/me/tmp/file.bundle,並從中拉取。
machineB$ cd R2 machineB$ git pull
如果您知道目標接收者儲存庫應該具備哪些必要的物件,您可以使用該知識來指定先決條件,提供一個截止點來限制產生的套件中包含的修訂和物件。先前的範例使用了 lastR2bundle 標籤來達到此目的,但您可以使用您提供給 git-log[1] 命令的任何其他選項。以下是一些範例:
您可以使用兩者都存在的標籤
$ git bundle create mybundle v1.0.0..master
您可以使用基於時間的先決條件
$ git bundle create mybundle --since=10.days master
您可以使用提交的數量
$ git bundle create mybundle -10 master
您可以執行 git-bundle verify
來查看是否可以從使用先決條件建立的套件中提取
$ git bundle verify mybundle
這將列出您必須擁有哪些提交才能從套件中提取,如果沒有這些提交則會發生錯誤。
從接收者儲存庫的角度來看,套件就像是一個它從中提取或拉取的常規儲存庫。例如,您可以在提取時對參考進行映射
$ git fetch mybundle master:localRef
您也可以查看它提供了哪些參考
$ git ls-remote mybundle
檔案格式
請參閱 gitformat-bundle[5]。
GIT
屬於 git[1] 套件的一部分