27

現在、次のワークフローで git-svn を使用しています

git clone <SVN TRUNK URL> #done once

その後、私が機能に取り組むとき

git branch featureZ
git checkout featureZ
#make edits for featureZ
git commit

git checkout master
git svn rebase # fetch changes from server

git checkout featureZ #go back to branch
#git merge master 
git rebase master #get the changes from SVN->master onto the branch now. Optional if I want the branch to be current. (EDITED: Got from the answer given below)

#make edits for featureZ
git commit #featureZ completed

git checkout master
git merge featureZ #getting featureZ onto master. Prepare to send to SVN

git svn dcommit #push featureZ back to SVN

ここで、機能をマスターに git マージする際のいくつかの注意点があります。

コミット メッセージは「merged with featureZ」に置き換えられます。これはmerge fmt msgで修正できます。

ここで私の質問は、このワークフローで問題が発生する可能性があること、または対処する必要があることはありますか? git svn を使用する場合はマージを行うべきではないというgit-svn のマニュアルを読みました。私がワークフローで行っていることは、彼らが言及していることですか? もしそうなら、それはどのような問題を引き起こしますか？1 つのことは、SVN のメインラインを台無しにするようなことはしたくないということです。

4

4 に答える 4

27

SVN は非線形履歴を処理できません (単純にその表記がありません)。したがって、やりたいことは、マージではなくリベースです。これは、SVN との線形の履歴を保持するためです (これは、git-svn のマニュアル ページに示されています。

詳しく言うと、線形の歴史は些細なことです。それらは一直線に進みます (A から B から C から D)。一方、非線形の履歴は (A から B から C、B から D、次に C + D から E に移動できます。つまり、それらは分岐に分岐します)。

リベースすると、線形の履歴が得られます。リベースは、プライベートなローカルのみのブランチから行う必要があることに注意してください。たとえば、マスターと実験的な 2 つのブランチがあるとします。実験的なものをチェックアウトし、できれば -i フラグを付けて「git rebase master」を実行します。逆の方法で行うと、望ましくない副作用が生じる可能性があります。

次に、master をチェックアウトし、experimental ブランチからの変更をマージします。履歴は線形のままである必要があります。

于 2009-07-15T06:20:19.053 に答える
4

このマージオプションを確認する必要があります。

git checkout master
git merge --squash featureZ

ブランチ上のすべてのコミットをマスターブランチ上の単一のコミットに押しつぶします。ブランチで行われたことの要約で初期化されるログメッセージを編集する機会が得られます。

機能ブランチでの個々のコミットが記録されないという欠点があります。さらに、これは1回だけ実行する必要があり、ブランチは適切なマージとして登録されていないため、ブランチでこれ以上作業を行わないでください。その後のマージでは、望ましくない結果が生じる可能性があります。

于 2009-07-15T07:48:15.413 に答える
2

fake-code-monkey-rashid によって与えられた答えは正しいです。これは答えではなく、単純化したものです。

任意の git ブランチから svn rebase/dcommit できます。masterが持つ唯一の用途は、 featureZからの変更とマージする必要がある他のローカル変更がある場合です。

git branch featureZ
git checkout featureZ
#bunch of changes
git commit
git svn rebase
# solve any conflicts
git svn dcommit

きれいなマスターを維持したい場合は、git svn rebaseそれまたはgit merge featuresZ

于 2009-07-20T22:37:18.693 に答える
0

git-svn の代わりに、SubGitを使用できます。これは、Subversion と Git のリポジトリを自動的に同期するサーバー側のツールです。

任意の Git ワークフローと利用可能な Git クライアントを使用でき、追加のクライアント ツールは必要ありません。

あなたのシナリオを考慮してください：

git branch featureZ
git checkout featureZ
# make edits for featureZ
git commit
git checkout master

次のように進めることができます。

  1. フィーチャー ブランチ全体をプッシュします。

    git merge featureZ
git push origin refs/heads/*

  2. マスター/トランクの上に機能ブランチをリベースします。

    git rebase featureZ
git push

  3. フィーチャー ブランチからコミットをスカッシュします。

    git merge --squash featureZ
git commit
git push

変更をプッシュするとすぐに、SubGit フックが変更を Subversion リビジョンに変換します。

詳細:

  • SubGit は多くの点で git-svn よりも優れています — より優れたマージ追跡変換、EOL および MIME タイプのサポートなど。
  • SubGit には Subversion リポジトリへのローカル アクセスが必要です (カスタム フックを使用します)。
  • SubGit は、いくつかの無料オプション (オープンソースおよびアカデミック プロジェクト、小規模チーム) を備えた商用製品です。
于 2012-06-18T15:01:44.213 に答える