23

Gitリポジトリ間で共有されるコードのベストプラクティスを確認しようとしています。

これまでのところ、私は明らかに、それらが-ほぼ-法案に適合しているように見えるサブモジュールに出くわしました。私のプロジェクトは、単純な構造のPHPMVCフレームワークです。

  • /アプリ
  • core.php
  • /芯

appアプリケーション固有のコントローラー、モデル、ビューなどを含むフォルダーはどこにありますがcore、ログインコントローラーなどの一般的な用途のものが含まれています。core.phpファイル自体は、すべてのリクエストのグローバルハンドラーです。

そのため、このMVCフレームワークのすべてのデプロイメント間で共有されるコードはとcore.phpですcore。

coreGitサブモジュールに変換する方法はわかりますが、できませんcore.php。

これも可能ですか？フォルダー全体をサブモジュールにできるようにcore.php、フォルダー内にあるフレームワークを再構築する必要がありますか、それともより良い方法がありますか？core

4

3 に答える 3

9

シンボリック リンクを使用できる場合 (たとえば、Windows を使用していない場合)、次coreのcore.phpように設定できます。

# "base" repository layout:
core/
core.app

# each app repository layout:
base/
  core/
  core.php
core -> base/core/
core.php -> base/core.php
app/

各アプリ リポジトリでは、base/ディレクトリは「ベース」リポジトリを使用するサブモジュールか、「ベース」リポジトリのサブツリー マージのいずれかです。

どちらの方法でも、特定のアプリのコンテキストでベース コードへの変更を開始し、後でそれらの変更をメインのベース リポジトリに戻すことができます。サブモジュールを使用する場合、新しいベース コミットを参照するアプリ コミットを発行する前に、常に新しいベース コミットを発行するように注意する必要があります (各アプリは「フラット」であり、実質的に独自のコピーを持っているため、サブツリー マージを使用する場合、これは問題ではありません)。ベース）。

サブモジュールを使用しないことにした場合、サードパーティのgit subtreeコマンドは、サブツリーのマージを管理するための非常に優れた方法のようです。

サブツリー

git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'

# hook up base
git subtree add --prefix=base git@git.example.com:me/app_base.git master

mkdir app
# edit app/bar.php

# update base
git subtree pull --prefix=base git@git.example.com:me/app_base.git master

.
|-- .git/
|   |-- ...
|   `-- ...
|-- app/
|   `-- bar.php
|-- base/
|   |-- core/
|   |   `-- foo.php
|   `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php

サブモジュール

git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'

# hook up "base"
git submodule add git@git.example.com:me/app_base.git base
git commit -m'incorporate base'

mkdir app
# edit app/bar.php

# update base
(cd base && git fetch origin && git merge origin/master)
git add base
git commit -m'updated base'
.
|-- .git/
|   |-- ...
|   `-- ...
|-- .gitmodules
|-- app/
|   `-- bar.php
|-- base/
|   |-- .git/
|   |   |-- ...
|   |   `-- ...
|   |-- core/
|   |   `-- foo.php
|   `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php
于 2010-11-14T07:16:09.167 に答える
6

おそらく、core.phpとcoreを別々のリポジトリに保持し、それをリモートとして使用するのが最善です。次に、使用するプロジェクトにプルすることで管理できます。これを行うには、新しいプロジェクトを別のgitレポジトリとして開始し、次に「コア」レポジトリをサブツリーとしてプルします。

この章では、その方法を説明します。

更新されたリファレンス：http：//git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge 元のリファレンス：https ：//git-scm.com/book/en/v1/Git-Tools -サブツリー-マージ

これは、本の前のセクション（6.6）でアドバイスされているセットアップよりも少し優れています。

それを見ろ; 役に立つかもしれません。

于 2010-11-13T04:25:15.793 に答える
5

サブモジュールは、独自の .git ディレクトリを持つ git リポジトリであるため、ディレクトリに含める必要があります。それを簡単に回避する方法はないと思います。どうにかして自分のものをディレクトリにパッケージ化する必要があります-そして、core.phpがコアのものと一緒にある場合、それらがサブモジュールリポジトリに一緒にあることは完全に理にかなっています!

rmk's answerは、これをすべて 1 つのリポジトリで行うことを示唆しています。core と core.php を出発点として使用することは、別の合理的な方法です。予想されるワークフローに基づいて決定する必要があります。コア* コンテンツを、それを使用するプロジェクトとは別に変更する予定がある場合は、サブモジュールが適しています。その後、それを使用するさまざまなプロジェクトでサブモジュールを更新できます。特定のプロジェクトに合わせてコア* コンテンツを変更する場合は、ベースライン リポジトリが適しています。その後、ベースライン リポジトリからプルして更新を取得し、それらをプロジェクト リポジトリで行った変更とマージできます。

于 2010-11-13T04:18:04.817 に答える