27

シナリオ: Gitでunixドットファイルを取得しようとしています。私は(少なくとも)cygwin環境といくつかの標準的なLinuxディストリビューション(ubuntuとopensuse)の間で作業する必要があり、たとえばcygwinにのみ固有のファイル/コード行があります。無駄なファイルをチェックアウトしたくない、またはドットファイル内の多くのケースを処理する必要がないため、環境ごとにブランチを作成しています。しかし、私が行う編集のほとんどはすべての環境に共通しているため、コミットを行うたびに、その変更をすべてのブランチに伝播する必要があります。

したがって、基本的に、いくつかのコミットを除いてほとんど同じであるいくつかのブランチがあり、ほとんどのコミットはすべてのブランチにある必要があります。

質問:もしあれば、これに推奨されるgitワークフローは何ですか?または、私のシナリオに(複数のブランチを使用せずに)より良いセットアップがありますか?

[チェリーピッキングを試しましたが、かなりの作業が必要です。ここで重複するすべてのコミットと、ブランチの同期を維持することは悪夢です。]

4

3 に答える 3

19

1 つのブランチで多くの一般的なファイルが進化し、環境ごとに固有の構成ファイルがいくつかある特定のケースでは、構成ファイルを Git に保存しません。まったく。

上記の構成ファイルのテンプレート、環境ごとの特定の値、およびテンプレート ファイル内の変数を正しい値 (現在のプラットフォームを検出する) に置き換えることができるスクリプトを保存します。

そうすれば、それらのファイルだけにブランチを作成する必要がなくなります。


この種のファイル (プラットフォーム固有のコンテンツを含む) を管理するもう 1 つの良い方法は、git 属性フィルター ドライバーを使用することです ( Pro Git bookも参照してください)。

フィルター ドライバーは、cleanコマンドとコマンドで構成されsmudge、いずれかを指定しないでおくことができます。コマンドが指定されている場合、コマンドはその標準入力から blob オブジェクトを受け取り、その標準出力を使用してワークツリー ファイルを更新します
。 同様に、このコマンドは、チェックイン時にワークツリー ファイルの内容を変換するために使用されます。checkoutsmudge
clean

そうすれば、スマッジによって参照されるスクリプト (Git で管理される) はすべての変数をプラットフォーム固有の値に置き換えることができますが、クリーンなスクリプトはその内容を変更されていない構成ファイルに復元します。

http://git-scm.com/figures/18333fig0702-tn.png

主な考え方はそのままです。その種の並行進化のためだけにブランチを作成することは避けてください。

于 2010-01-28T07:44:49.280 に答える
9

1 つのアプローチは、環境ごとにブランチを保持し、さらにすべての環境に共通の「マスター」ブランチを保持することです。master ブランチに変更を加えて別のシステムにプルしたい場合は、次のようにします。

git pull
git checkout local
git rebase master

これにより、「マスター」の現在の状態に対して「ローカル」(この特定の環境用) の現在の変更が書き換えられます。

手動で注意する必要があるのは、変更をコミットする場所です。システムに対してローカルである場合は、そのシステムの「ローカル」ブランチにコミットし、それ以外の場合は「マスター」にコミットして共通リポジトリにプッシュします。

もちろん、リベースによって競合が発生する可能性があり、手動で解決する必要があります。また、ローカル ブランチを共通リポジトリにプッシュすることを選択した場合は、(a) 各環境に一意の名前を選択し、(b) リベース後に非早送りプッシュを処理する必要があります。これらの問題は両方とも解決可能です。

于 2010-01-28T07:34:06.097 に答える
1

良い質問。あなたが言ったとしても:

...無駄なファイルをチェックアウトしたくないので...

プラットフォーム固有またはバリアント固有の項目をメイン コードと同じブランチに配置しますが、そのプラットフォーム/バリアント用の別のディレクトリに配置します。重要なのは、プラットフォーム固有のものをできるだけ小さな領域に分離することです (つまりifdef、メイン コードの s を避けます)。

例えば:

/
+--common
+--linux
+--cygwin
+--windows
+--mac

さまざまなクロスプラットフォーム プロジェクトは、このように組織化されています。たとえば、複数のプラットフォームをサポートするための Python のソース コード構造を確認してください。

この点でワークフローが簡素化されるため、ブランチを他のより興味深い目的に自由に使用できます。

于 2010-01-29T04:47:55.693 に答える