git-subtree - クラウドでオンライン

プログラム：

NAME

git-subtree - サブツリーをまとめてマージし、リポジトリをサブツリーに分割します

SYNOPSIS

git サブツリー -P を追加
git サブツリー -P を追加
git サブツリー プル -P
git サブツリー -P を押す
git サブツリー マージ -P
git サブツリー 分割 -P 【オプション】 ]

DESCRIPTION

サブツリーを使用すると、サブプロジェクトをメイン プロジェクトのサブディレクトリに含めることができます。
オプションで、サブプロジェクトの全履歴を含めます。

たとえば、ライブラリのソース コードをサブディレクトリとして含めることができます。
アプリケーション。

サブツリーは、同じタスク用のサブモジュールと混同しないでください。 ようではない
サブモジュール、サブツリーは特別な構造を必要としません (.gitmodule ファイルや
gitlinks) をリポジトリに存在させ、リポジトリのエンドユーザーに強制しないでください。
何か特別なことをしたり、サブツリーがどのように機能するかを理解したりします。 サブツリーは単なるサブディレクトリです
任意の方法でプロジェクトにコミット、分岐、およびマージできます。
欲しいです。

また、サブツリー マージ戦略の使用と混同しないでください。 メイン
違いは、他のプロジェクトをサブディレクトリとしてマージする以外に、次のこともできることです。
プロジェクトからサブディレクトリの履歴全体を抽出し、それを
スタンドアロン プロジェクト。 サブツリーのマージ戦略とは異なり、前後に交互に行うことができます
これらXNUMXつの操作の間。 スタンドアロン ライブラリが更新された場合は、次のことができます。
変更をプロジェクトに自動的にマージします。 内部のライブラリを更新する場合
プロジェクト、変更を再び「分割」してライブラリにマージすることができます
プロジェクト。

たとえば、あるアプリケーション用に作成したライブラリが別の場所で役立つようになった場合、
履歴全体を抽出し、それを独自の git リポジトリとして公開できます。
アプリケーション プロジェクトの履歴を誤って混ぜてしまう可能性があります。

先端
コミットメッセージをきれいに保つために、人々が自分のコミットメッセージを分割することをお勧めします
サブツリーとメイン プロジェクトの間で可能な限りコミットします。 つまり、
ライブラリとメイン アプリケーションの両方に影響する変更を行い、XNUMX 回に分けてコミットします
個。 そうすれば、後でライブラリのコミットを分割するときに、それらの説明
まだ意味があります。 しかし、これがあなたにとって重要でない場合、それは重要ではありません 必要. ギット
サブツリーは、コミットのライブラリに関連しない部分を単純に除外します。
後でサブプロジェクトに分割します。

コマンド

加えます
を作成します指定されたからその内容をインポートすることにより、サブツリーまた
とリモート. 新しいコミットが自動的に作成され、
インポートされたプロジェクトの履歴を自分のものに。 と - 押しつぶす、単一のコミットのみをインポートします
履歴全体ではなく、サブプロジェクトから。

マージ
までの最近の変更をマージにサブツリー。 通常時と同様 git
マージ、これはあなた自身のローカル変更を削除しません。 それらの変更をマージするだけです
最新の. と - 押しつぶす、すべてを含むコミットを XNUMX つだけ作成します。
履歴全体にマージするのではなく、変更します。

あなたが使用している場合 - 押しつぶす、マージ方向は常に前方である必要はありません。 あなたはできる
たとえば、このコマンドを使用して、v2.5 から v2.4 に時間をさかのぼります。 マージする場合
競合が発生した場合は、通常の方法で解決できます。

プル
まさにそのように マージ、しかし平行線 git プル から指定された参照をフェッチするという点で
指定されたリモート リポジトリ。

プッシュ
ありません split (下記参照) 提供されてから git プッシュ プッシュする
リポジトリへの結果と参照。 これは、サブツリーをプッシュするために使用できます
リモートリポジトリのさまざまなブランチ。

split
の履歴から新しい合成プロジェクト履歴を抽出します。 サブツリー。 の
新しい履歴には、影響を受けたコミット (マージを含む) のみが含まれます、 と
これらの各コミットには、次の内容が含まれていますプロジェクトのルートで
サブディレクトリの代わりに。 したがって、新しく作成された履歴はエクスポートに適しています
別の git リポジトリとして。

分割が成功すると、単一のコミット ID が stdout に出力されます。 これ
新しく作成されたツリーの HEAD に対応しますが、これは操作できます
あなたは欲しい。

まったく同じ履歴の繰り返し分割は、同一であることが保証されます (つまり、
同じコミット ID を生成します)。 このため、新しいコミットを追加してから
再分割すると、新しいコミットは履歴の上にコミットとして添付されます
前回生成したので、 git マージ 友人は期待どおりに動作します。

使用する場合は注意してください - 押しつぶす マージするときは、通常、 --再参加
分割するとき。

OPTIONS

-q、-quiet
stderr で不要な出力メッセージを抑制します。

-d、-debug
stderr にさらに不要な出力メッセージを生成します。

-P 、 --prefix=
操作するサブツリーへのリポジトリ内のパスを指定します。 このオプション
すべてのコマンドで必須です。

-m , --メッセージ=
このオプションは、追加、マージ、およびプルに対してのみ有効です (不明)。 特定として
マージ コミットのコミット メッセージ。

OPTIONS FOR 追加、 マージ、 押す、 PULL

- 押しつぶす
このオプションは、add、merge、および pull コマンドに対してのみ有効です。

サブツリー プロジェクトの履歴全体をマージする代わりに、単一のプロジェクトのみを生成します。
マージしたいすべての相違点を含むコミットを行い、その新しいものをマージします
プロジェクトにコミットします。

このオプションを使用すると、ログの乱雑さを軽減するのに役立ちます。 すべての変更を見たいと思う人はめったにいません
これは、使用しているライブラリの v1.0 と v1.1 の間で発生しました。
中間バージョンは、アプリケーションに含まれていました。

使い方 - 押しつぶす また、同じサブプロジェクトが複数含まれている場合の問題を回避するのにも役立ちます
同じプロジェクトで何度か、または削除されてから再度追加されます。 そのような場合は、そうではありません
いずれにせよ歴史を組み合わせるのは理にかなっています。
history はどのサブツリーに属しますか。

さらに、 - 押しつぶす、異なるバージョン間で前後に切り替えることができます
厳密に転送するのではなく、サブツリーの。 git サブツリー マージ - 押しつぶす 常に調整します
そのコミットに到達した場合でも、正確に指定されたコミットに一致するサブツリー
以前に追加したいくつかの変更を元に戻す必要があります。

使用するかどうか - 押しつぶす、ローカル リポジトリで行った変更はそのまま残ります
後で分割して上流のサブプロジェクトに送信できます。

OPTIONS FOR SPLIT

--注釈=
このオプションは、分割コマンドに対してのみ有効です。

合成履歴を生成するときに、追加します各コミットのプレフィックスとして
メッセージ。 同じコミットメッセージで新しいコミットを作成しているので、おそらく
元のコミットとは異なるコンテンツ、これはそれらを区別するのに役立ち、
混乱を避ける。

分割するたびに、同じものを使用する必要があります、またはそうでなければあなたは持っていません
新しく再作成された履歴が古い履歴と同一であることを保証します。 それは
マージが正しく機能しないようにします。 とにかく git subtree はそれを機能させようとしますが、
--rejoin を使用する場合は特にそうですが、常に有効であるとは限りません。

-b 、 -- ブランチ =
このオプションは、分割コマンドに対してのみ有効です。

合成履歴を生成した後、という名前の新しいブランチを作成しますそれか
新しい歴史が含まれています。 これは、すぐに上流にプッシュするのに適しています。
まだ存在していてはなりません。

--ignore-join
このオプションは、分割コマンドに対してのみ有効です。

あなたが使用している場合 --再参加、gitサブツリーは、その履歴再構築を最適化しようとします
最後のコミット以降の新しいコミットのみを生成する --再参加. --無視-結合 これを無効にします
履歴全体の再生成を強制します。 大規模なプロジェクトでは、これは
長い時間がかかります。

--onto=
このオプションは、分割コマンドに対してのみ有効です。

サブツリーが最初に git サブツリー以外のものを使用してインポートされた場合、その
履歴は、git サブツリーが期待するものと一致しない場合があります。 その場合、指定できるのは
コミット ID サブプロジェクトの履歴の最初のリビジョンに対応する
プロジェクトにインポートされたものであり、git サブツリーはその履歴を構築しようとします
そこから。

使用した場合 git サブツリー 加えます、このオプションは必要ありません。

--再参加
このオプションは、分割コマンドに対してのみ有効です。

分割後、新しく作成された合成履歴をメインにマージします
計画。 そうすれば、将来の分割では、履歴の一部のみを検索できます。
最新の --rejoin 以降に追加されました。

分割コミットが上流のサブプロジェクトにマージされてしまった場合、
最新のアップストリーム バージョンを取得します。これにより、git のマージ アルゴリズムがより多くの
競合をインテリジェントに回避します（これらの合成コミットがすでに一部であることを認識しているため）
アップストリームリポジトリの)。

残念ながら、このオプションを使用すると、 git ログ 新しいすべての余分なコピーを表示する
作成されたコミット (オリジナルと合成)。

すべてのマージを行う場合 - 押しつぶす、使用しないでください --再参加 あなたが分割するとき、なぜなら
とにかく、サブプロジェクトの履歴をプロジェクトの一部にしたくありません。

実施例 1. 追加 COMMAND

外部リポジトリを追加したいローカルリポジトリがあると仮定しましょう
ベンダー ライブラリへ。 この場合、サブディレクトリとして git-subtree リポジトリを追加します
既存の git-extensions リポジトリの ~/git-extensions/:

$ git subtree add --prefix=git-subtree --squash \
git://github.com/apenwarr/git-subtree.git マスター

マスター 有効なリモート参照である必要があり、別のブランチ名にすることができます

--squash フラグは省略できますが、そうするとコミットの数が増えます。
ローカル リポジトリに含まれています。

今では、 ~/git-extensions/git-subtree マスターからのコードを含むディレクトリ
git-extensions リポジトリの git://github.com/apenwarr/git-subtree.git のブランチ。

実施例 2. エキス A サブツリー 使用する 専念、 MERGE そして PULL

例として、git ソース コードのリポジトリを使用してみましょう。 まず、自分のコピーを入手してください
git.git リポジトリの:

$ git clone git://git.kernel.org/pub/scm/git/git.git test-git
$ cd テスト git

gitweb (コミット 1130ef3) は、コミット 0a8f4f0 の時点で git にマージされました。
個別に維持されなくなりました。 しかし、それが別々に維持されていたと想像してください。
それ以降の git の gitweb への変更を抽出し、アップストリームと共有します。 あなたは出来る
これを行う：

$ git subtree split --prefix=gitweb --annotate='(分割) ' \
0a8f4f0^.. --onto=1130ef3 --再参加 \
--branch gitweb-latest
$ gitk gitweb-最新
$ git プッシュ [メール保護]:whatever/gitweb.git gitweb-latest:master

（を使用しております 0a8f4f0^.. これは、「0a8f4f0 から現在までのすべての変更」を意味するためです。
0a8f4f0 自体を含むバージョン。")

gitweb が最初にマージされていた場合 git サブツリー 加えます (または以前の分割があった
--rejoin を指定してすでに行われている場合)、すべての分割を行うことができます。
奇妙なコミット ID を覚えておくには:

$ git subtree split --prefix=gitweb --annotate='(split) ' --rejoin \
--branch gitweb-latest2

また、上流のプロジェクトからの変更を同じように簡単にマージして戻すことができます。

$ git サブツリー プル --prefix=gitweb \
[メール保護]:whatever/gitweb.git マスター

または、 - 押しつぶす、実際には以前のバージョンの gitweb に巻き戻すことができます。

$ git subtree merge --prefix=gitweb --squash gitweb-latest~10

次に、いくつかの変更を加えます。

$ 日付 >gitweb/myfile
$ git add gitweb/myfile
$ git commit -m 'created myfile'

もう一度早送りします。

$ git subtree merge --prefix=gitweb --squash gitweb-latest

変更がそのまま残っていることに注意してください。

$ ls -l gitweb/myfile

そして、それを分割して、標準の gitweb と比較して変更を確認できます。

git log gitweb-latest..$(git サブツリー分割 --prefix=gitweb)

実施例 3. エキス A サブツリー 使用する ブランチ

多くのファイルとサブディレクトリを含むソース ディレクトリがあり、次のことを行いたいとします。
lib ディレクトリを独自の git プロジェクトに抽出します。 これを行う簡単な方法は次のとおりです。

まず、新しいリポジトリを好きな場所に作成します。

$
$ git init --bare

元のディレクトリに戻ります。

$ git subtree split --prefix=lib --annotate="(split)" -b split

次に、新しいブランチを新しい空のリポジトリにプッシュします。

$ git プッシュスプリット:マスター

onworks.net サービスを使用してオンラインで git-subtree を使用する