git-subrepoプロジェクトは長い間存在していますが、それへの参照はほとんどありません。 git-subrepoの作成者はIngydötNetです。
プロジェクトのmasterブランチのコミットの履歴を見ると、2年前にプロジェクトが開発中に停止したように見えるかもしれません。 ただし、プロジェクトの作業は進行中であり、バージョン0.4.0が間もなくリリースされることを願っています。
このツールの重要な特性は、ユーザー側でサブプロジェクトのアップストリームリポジトリでコミットすることを決定するまでgit-subrepoをインストールする必要がないことです。 さらに、ユーザーは、標準のgit-clone(1)コマンドを使用してメインリポジトリをコピーするときに、完全に準備および構成されたソースツリーを受け取ります。
メインコンテナリポジトリのサブモジュール/サブツリー/サブプロジェクトをサポートする手段を選択する場合、開発者はまずこのメカニズムが提供する機能の範囲を決定し、次の質問に答えます。
- メインリポジトリにサブプロジェクトの完全な履歴を保持する必要があるか、十分な圧縮コミットが必要か。
- サブプロジェクトからサブツリーのアップストリームリポジトリに変更を配信する機能が必要かどうか。
- サブプロジェクトのアップストリームリポジトリの固定タグを接続する必要があるか、ブランチを接続することは可能ですか?
- サブプロジェクト自体と、不要になったこれらのサブプロジェクトの履歴の両方をさらに削除する必要があるかどうか。
- メインプロジェクトのリポジトリを複製した後、ユーザーがサブプロジェクトを手動で構成するために何らかのアクションを実行する必要があるかどうか。
- サブプロジェクトとサブプロジェクトの元となる特定のリビジョンを接続する履歴を分析する問題はどれほど面倒ですか。
- このツールまたはそのツールがソース構成管理ポリシーにどのように影響し、このツールがエンジニアの日常業務をどれほど複雑にするか。
もちろん、この質問のリストは正しい選択に必要な入力パラメーターの完全性を反映することはできませんが、既存のツールの予備的なレビューのためには、 それで十分です。
Git-subrepoのインストール
開発者側のgit-subrepoパッケージは 、ローカル、ホームディレクトリ、およびシステムレベルの両方にインストールできます。
最初のケースでは、 git-subrepoリポジトリを目的のディレクトリ、たとえば〜/ binに複製するだけで十分です 。
bash-4.4$ cd ~/bin bash-4.4$ git clone https://github.com/ingydotnet/git-subrepo.git
環境変数の設定
bash-4.4$ vim subrepo-env.sh
git-subrepo Makefileで定義されている変数を見ると:
# Install variables: PREFIX ?= /usr/local INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1
システムレベルでは、 git-subrepoが Gitのあるディレクトリにインストールされていることが簡単にわかります。
bash-4.4$ bash-4.4$ git --exec-path /usr/libexec/git-core bash-4.4$
したがって、 git-subrepoをインストールするコマンドは、たとえば次のようになります。
bash-4.4$ make PREFIX=/usr install
DESTDIR変数の存在により、追加の努力なしで(もちろん、クロス環境にない場合)Linuxディストリビューション用のパッケージを作成できます。これは、DevOpsエンジニアに役立ちます。
ルートとしてgit-subrepoをインストールします。
bash-4.4$ bash-4.4$ cd git-subrepo/ bash-4.4$ make PREFIX=/usr install install -C -d -m 0755 /usr/libexec/git-core/ install -C -m 0755 lib/git-subrepo /usr/libexec/git-core/ install -C -d -m 0755 /usr/libexec/git-core/git-subrepo.d/ install -C -m 0755 lib/git-subrepo.d/help-functions.bash lib/git-subrepo.d/bash+.bash /usr/libexec/git-core/git-subrepo.d/ install -C -d -m 0755 /usr/share/man/man1/ install -C -m 0644 man/man1/git-subrepo.1 /usr/share/man/man1/ bash-4.4$
git-subrepoの機能を分析するには、標準の運用シナリオを再現できる簡単なテスト環境が必要です。
テスト環境
3つのディレクトリowner 、 remote 、 userを作成し、そこに開発者とユーザーのアップストリームおよびローカルリポジトリのモデルを配置します。
bash-4.4$ vim _init.sh
ここに
所有者 | - | プロジェクト作成者の作業ディレクトリ。 |
遠い | - | メインプロジェクトplatform.gitおよびサブプロジェクトbuild-system.gitのアップストリームリポジトリがあるプロジェクトの作成者のサーバーを表すディレクトリ。 |
ユーザー | - | ユーザーまたは開発チームのメンバーの作業ディレクトリ |
プロジェクトの作成者とユーザーは、それぞれのマシンにアップストリームリポジトリのコピーを所有しています 。この例では、それぞれ所有 者ディレクトリとユーザーディレクトリにあります。
著者のタスクは、 builld-systemサブプロジェクトを含めることにより 、 プラットフォームのメインツリーに次の機能を含めることです。
- ビルドシステムサブプロジェクトをその構造に含めてメインリポジトリのクローンを作成します。バージョンやリビジョンの設定について心配する必要はありません。 つまり、 プラットフォームリポジトリの各ブランチは、 ビルドシステムリポジトリの特定のブランチの特定のリビジョンに対応する必要があり、ユーザーは追加のアクションなしで、 1つのgit-clone(1)操作でカスタマイズされたソースツリーを受け取る必要があります。
- メインと補助の両方で、変更をアップストリームプロジェクトリポジトリに配信します。
- もちろん、他のプロジェクト参加者またはユーザーが適切な権利を持っている場合は、それらの変更を受け取ります。
これらの要件を実装するために実装する必要がある著者のアクションを検討してください。
サブプロジェクト接続
新しいサブツリーを接続するには、 git subrepo cloneコマンドを使用します。このコマンドの目的は、 git-clone(1)コマンドに似ています。 コマンドの必須パラメーターは、リモートリポジトリのURLです。 サブプロジェクトとリモートリポジトリブランチが配置されるディレクトリを指定することもできます。 マスターブランチで作業するため、この例では、不必要なコマンドパラメーターを省略します。
したがって、プロジェクトの作成者は、自分の作業マシンで、 git subrepo clone ../../remote/build-system.git/ build-systemコマンドを使用してbuild-systemサブプロジェクトに接続できます。
bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ git subrepo clone ../../remote/build-system.git/ build-system Subrepo '../../remote/build-system.git' (master) cloned into 'build-system'. bash-4.4$
ローカルプラットフォームリポジトリで発生した変更を検討します。
bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ bash-4.4$ git subrepo status 1 subrepo: Git subrepo 'build-system': Remote URL: ../../remote/build-system.git Upstream Ref: b2f5079 Tracking Branch: master Pulled Commit: b2f5079 Pull Parent: b5e76a7 bash-4.4$
ビルドシステムサブプロジェクトの履歴はメインツリーに配信されません;コミットが1つだけスカッシュされており、これには背景情報が伴います。 この情報は、ファイル./build-system/.gitrepo/configのバージョン管理下にあります。
[subrepo] remote = ../../remote/build-system.git branch = master commit = b2f507918f2821cb7dd90c33223ed5cc3c9922a2 parent = b5e76a713f895565b06ee3ccfa29f19131ba06dd method = merge cmdver = 0.4.1
サブプロジェクトに関する情報は、たとえば、次のコマンドを使用してメインリポジトリに到着したアップストリームプロジェクトremote / build-system.gitのリビジョンを見つけるために、 git subrepo configコマンドを使用して取得できます。
bash-4.4$ bash-4.4$ git subrepo config build-system commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$
元のgit-subrepoパッケージでは、サブプロジェクトに関する情報は.gitrepo / configファイルではなく、 .gitrepoファイルに保存されることに注意してください 。 隠しサブディレクトリに情報を保存する場合は、 git-subrepo子リポジトリのgit-subrepo-0.3.2またはgit-subrepo-0.4.1 ブランチを選択できます 。
そのため、アップストリームリポジトリremote / build-system.gitのマスターブランチの最新バージョンを取得し、メインプラットフォームプロジェクトのbuild-systemサブディレクトリに配置しました。
これらの変更をアップストリームリポジトリremote / platform.gitに配信するには、作成者はgit pushコマンドを実行する必要があります。
bash-4.4$ bash-4.4$ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 849 bytes | 849.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git <font color="#8b0000">b5e76a7..6b831e4</font> master -> master bash-4.4$
git subrepoコマンドの詳細については、 ReadMe.podファイルまたはコマンドラインから入手できます。
bash-4.4$ git subrepo help <command>
例えば:
bash-4.4$ git subrepo help clone
ここで、ユーザーから発生するすべてを考慮します。
ユーザーによるコードの取得
現時点では、ユーザーがアップストリームリポジトリplatform.gitの更新をまだ受け取っていない場合、ユーザーのコピーには1つのREADMEファイルが含まれています。
bash-4.4$ bash-4.4$ cd user/platform/ bash-4.4$ ls README bash-4.4$
1行を含む:
bash-4.4$ bash-4.4$ cat README [master] platform 1.0.0 bash-4.4$
アップストリームリポジトリに変更を加えた後
bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. From /home/prog/0.4.1/remote/platform b5e76a7..6b831e4 master -> origin/master Updating <font color="#8b0000">b5e76a7..6b831e4</font> Fast-forward build-system/.gitrepo/config | 12 ++++++++++++ build-system/README | 3 +++ 2 files changed, 15 insertions(+) create mode 100644 build-system/.gitrepo/config create mode 100644 build-system/README bash-4.4$
ユーザーは、プロジェクトの作成者が決定したリビジョンのビルドシステムサブプロジェクトのコードを自由に使用できます。 ユーザーは、 configコマンドを使用して、いつでも現在のリビジョンを更新できます。
bash-4.4$ bash-4.4$ git subrepo config build-system/ commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$
ユーザーが追加の設定を行う必要がなく、プロジェクトの作成者が現在のバージョンのプラットフォームが動作するために必要なビルドシステムリビジョンを正確に提供したという事実に頼ることができます。
これはまさにプロジェクトの作者が求めていたものです。
アップストリームプロジェクトへの変更の配信
ここで、ユーザーがプロジェクトのメンバーであり、アップストリームリポジトリremote / platform.gitだけでなく、 remote / build-system.gitサブプロジェクトのアップストリームリポジトリにも変更を配信できるとします。
次に、ユーザーが変更を加えた場合:
bash-4.4$ bash-4.4$ cd build-system/ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.1 bash-4.4$ bash-4.4$ git commit -a -m "update BS version to 1.0.1" [master d30b001] update BS version to 1.0.1 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ cd .. bash-4.4$ git log commit d30b001286b08708f5c30c1f5346a90e4339f969 (HEAD -> master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 . . . bash-4.4$
彼は次のようにそれらを上流のリポジトリに置くことができます:
bash-4.4$ bash-4.4$ git subrepo push build-system/ Subrepo 'build-system' pushed to '../../remote/build-system.git' (master). bash-4.4$
ここで注意することが重要です...サブプロジェクトの構成ファイル.gitrepo / configはバージョン管理下に格納されているため、ユーザーはサブプロジェクトのステータス変更をメインプロジェクトremote / platform.gitのアップストリームリポジトリに送信する必要があります 。
つまり、ユーザーはローカルリポジトリのステータスを確認することを忘れてはならず、 git-push(1)コマンドを時間内に実行する必要があります。
bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ git push Enumerating objects: 14, done. Counting objects: 100% (14/14), done. Delta compression using up to 4 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (9/9), 992 bytes | 992.00 KiB/s, done. Total 9 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git d00be9f..deccb66 master -> master bash-4.4$
そうしないと、次にアップストリームリポジトリを変更したときに、マージの競合が発生します。
もちろん、ここでは珍しいことは何もありませんが、 git subrepo push ...コマンドを実行した後、メインリポジトリのローカルコピーの状態を簡単に忘れてしまいます。
アップストリームリポジトリを使用した直接作業
次に、上流のリポジトリremote / build-system.gitで何が起こったのかを考えてください
bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/prog/0.4.1/remote/build-system b2f5079..d229920 master -> origin/master Updating b2f5079..d229920 Fast-forward README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ git log commit d229920c7de34405bc7b8d47f36d420987687908 (HEAD -> master, origin/master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 commit b2f507918f2821cb7dd90c33223ed5cc3c9922a2 Author: user <___@_____> Date: Tue Oct 30 10:05:30 2018 +0300 init build-system master 1.0.0 bash-4.4$
つまり、プロジェクトの作成者は、プロジェクト参加者による変更を受け取りました。
もちろん、作成者はビルドシステムプロジェクトのアップストリームリポジトリを直接変更できます。
bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.2 bash-4.4$ git commit -a -m "update build-system version to 1.0.2" [master 8255f59] update build-system version to 1.0.2 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/build-system.git d229920..8255f59 master -> master bash-4.4$
そして、すべての参加者とメインプロジェクトのユーザーは、 git subrepo pullコマンドを使用してこれらの変更を受け取ることができます。
bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ bash-4.4$ git subrepo pull build-system/ Subrepo 'build-system' pulled from '../../remote/build-system.git' (master). bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ git push Enumerating objects: 11, done. Counting objects: 100% (11/11), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 670 bytes | 670.00 KiB/s, done. Total 6 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git 6b831e4..b6f4a7b master -> master bash-4.4$
結論
開発者がメインプロジェクトにサブプロジェクトの履歴を保存する必要がなく、コードを配信するときに、固定タグではなくブランチを操作する場合、 git-subrepoは日常の作業を整理するのに非常に適しています。
条件付きで、 git-subrepoの欠点の1つは、 git subrepoクローン操作がサブプロジェクトブランチに関連してのみ可能であるという事実です。 つまり、ユーザーは固定タグまたは特定のリビジョン、つまりタイプのコマンドを参照してサブプロジェクトに接続できません
bash-4.4$ git subrepo clone ../../remote/build-system.git build-system -t 1.0.1 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system 7f5d1113eb0bc6
無効です。
文学: