7

git-svn dcommit を実行したときに中央の svn リポジトリにチェックインされない、ローカルの git リポジトリで追跡するファイルが必要です。リポジトリで追跡されているファイルに対して、ローカルのみの長期にわたる変更を行うことがよくあります。コードのデバッグ用の場合もあります。追跡したいプロジェクト IDE ファイルもあります。普通の古い svn では、これらのファイルを「XYZ: チェックインしないでください」というラベルの付いた変更リストに入れ、実際にコミットする必要がある変更があるときに手動で問題に対処します。

理想的には、自分の変更を master ブランチにチェックインしたいのですが、それらの特定の変更が svn リポジトリに伝播するのを防ぐ何かを設定します。従来の方法で git と git-svn を使用しますが、特定のコミットはプッシュアップされません。明らかに、コミットするたびにこれを手動で行うことができますが、それは面倒です。

いくつかのことを検討し、破棄しました。これらのファイルを除外したくありません。dcommitted される変更を行う必要がある場合があるからです。また、これらのファイルは、IDE ファイルの場合のように、作成したローカルのみのブランチに表示されるようにしたいと考えています。ただし、これらの変更を単一のブランチに分離することはできません。IDE ファイルの場合と同様に、すべてのブランチに変更を加える必要があるからです。罪悪感やstgitのようなものが私が望むことをするように見えますが、私がまだ学んでいるgitの上に独自の複雑なレイヤーを追加するため、明らかではありません.

4

5 に答える 5

2

この問題に対する私の現在の解決策は、stacked git (stg) を使用し、これらのローカルの変更を個別のパッチとして維持することです。Subversion に dcommit する必要があるときは、

stg pop # naming the patches that should not be commited
stg commit # the rest of the patches to commit
git svn dcommit
stg push # naming the patches that are used locally

これらを個別のパッチとして維持することの良い点は、単体テストを変更してさまざまなデータベース バックエンドをテストするパッチを簡単に作成できることです。通常は Oracle に対してテストしますが、Derby に対してチェックしたい場合は、

stg push local-mods-derby
ant tests
stg pop

またはPostgreSQLに対してテストしたい場合は、実行します

stg push local-mods-test-postgresql
ant tests
stg pop

ここで、「local-mods-derby」と「local-mods-test-postgresql」はパッチ名です。

そのため、作業の個別のパッチを維持することは、stg を使用すると非常に簡単です。

于 2009-03-24T19:07:02.697 に答える
2

私は git に少し慣れていませんが、ローカルの git リポジトリで別のマスター ブランチと作業ブランチを使用することをお勧めします。

「非 SVN」ファイルを作業ブランチのみに追加します。通常、作業ブランチですべてのコード変更を行います。「非 SVN」ファイルが変更されたら、一意のコミットを使用してそれらを追加し、コミット メッセージのプレフィックス (つまり、「local:」または「private:」) を設定します。SVN にコミットする準備ができたら、次のようにします。

  1. SVN に追加するコミットのログを表示します。

    git co working
git cherry master

  2. 「プライベート」コミットを無視して、すべてのアップストリーム コミットをマスター ブランチに追加します。すべてのアップストリーム コミットがマスターになるまで、この手順を繰り返します。

    git co master
git cherry-pick <SHA1>

  3. コミットを SVN リポジトリにプッシュします。

    git svn rebase
git svn dcommit
于 2009-03-11T23:56:19.133 に答える
1

master ブランチで作業しないことを考えたことはありますか?

変更をローカルの git ブランチに保持する場合は、目的の変更のみを定期的にマージまたはチェリー ピックして、svn 追跡ブランチに入れることができます。追跡ブランチに切り替えて、dcommit を実行します。次に、ローカル ブランチに戻り、リベースします。

複数の分岐で変更が必要な場合は、すべて同じ分岐点に基づいてください。そのブランチをマスターとして保持し、リベースを介して変更します。次に、他のすべてのブランチについて、そのベース ブランチからリベースします。

于 2009-03-27T17:24:23.233 に答える
0

私はいくつかの調査を行い、それを実行できる可能性を考え出しました。同じディレクトリを指す2つのgitリポジトリです。環境変数GIT_DIRは、ローカルリポジトリディレクトリの名前を格納します。設定されていない場合、gitのデフォルトは.gitですが、何でもかまいません。

次にできることは、Subversionリポジトリにマップする1つのリポジトリを.gitに含めることです。それが一般的なケースです。次に、.localgitに別のリポジトリを作成できます。各リポジトリは、他のリポジトリによって管理されているファイルを無視するように構成する必要があります。それは簡単です！パターンを否定するため。

チェックインするローカル専用ファイルに変更を加えるときは、GIT_DIR環境変数を変更するか、-git-dirコマンドライン引数を使用します。除外/無視を適切に設定していれば、衝突について心配する必要はありません。これを最新の状態に保つには明らかにオーバーヘッドがありますが、ファイルがもう一方のリポジトリに追加されたときに、一方のリポジトリを除外してファイルを追加するラッパースクリプトを作成できます。また、そのオーバーヘッドは、複数のブランチの提案のようにすべてのコミットではなく、ファイルごとに1回だけ発生します。

簡単にしたい場合は、命名規則を使用できますが、ローカルのみのファイルの数はほぼ確実に1桁であるため、個々のファイルに対しても使用できます（そうでない場合は、何か間違ったことをしています） ）。

このアプローチで私が目にする1つの欠点は、SVNリポジトリ内のファイルと同じように、ローカル専用ファイルを分岐して隠し、リセットすることができないことです。ただし、これらに対する変更は、メインの編集に関して非同期である可能性が高いため、実際には重大な問題になるとは思いません。マルチリポジトリ対応の関数のラッパーを作成することもできます。また、ローカルのみのファイルを管理する場合は、より明確にする必要がありますが、git自体に複数のリポジトリが組み込まれている場合を除いて、ほとんどすべての状況でこれに対処する必要があります。

于 2009-03-16T20:42:10.587 に答える
0

そのためにスタッシュの使用を検討することをお勧めします。

git-stash - Stash the changes in a dirty working directory away

ただし、あなたが説明していることには力不足かもしれません。

于 2009-03-11T20:59:48.840 に答える