22

先週、週末に町を出る前に、地元の支店に多くの変更を加えました。今朝、会社の Svn リポジトリにこれらの変更をすべてコミットしたかったのですが、1 つのファイルでマージの競合が発生しました。

コミット中のマージの競合: ファイルまたはディレクトリ 'build.properties.sample' が古くなっている可能性があります: バージョン リソースがトランザクション内のリソースに対応していません。要求されたバージョン リソースが古くなっている (更新する必要がある) か、要求されたバージョン リソースがトランザクション ルートよりも新しい (コミットを再開する) かのいずれかです。

なぜこれが発生するのか正確にはわかりませんが、dcommit を試みる前にgit svn rebaseを実行しました。それは私のコミットを「上書き」しました。そこから回復するために、git reset --hard HEAD@{1}を実行しました。現在、作業コピーは期待どおりの場所にあるようですが、マージの競合を回避する方法がわかりません。私が見つけることができる解決すべき競合は実際にはありません。

任意の考えをいただければ幸いです。

編集:私がローカルで作業していることを指定したかっただけです。svn/trunk (リモート ブランチ) を参照するトランク用のローカル ブランチがあります。私の作業はすべてローカル トランクで行われました。

$ git branch
  maint-1.0.x
  master
  * trunk
$ git branch -r
  svn/maintenance/my-project-1.0.0
  svn/trunk

同様に、git logは現在、Svn ID を使用した最後のコミット以降、私のローカル トランクで 10 件のコミットを示しています。

うまくいけば、いくつかの質問に答えます。

再度、感謝します。

4

6 に答える 6

39

ローカル ブランチを作成し、その作業を完了している必要があります。戻ったら、マスターを更新し、ローカル ブランチにリベースし、マスターにマージしてから dcommit します。

そのため、変更をコピーしてバックアップしてみます。

has svn 同期ポイントからローカル ブランチを作成し、そこに変更をマージします。次に、マスター ブランチの変更を取り消し、フェッチし、ブランチにリベースし、ローカル ブランチからマージし、競合を修正してから dcommit します。

$ git checkout -b backup    # create a local backup branch with all your work
$ git checkout master   
$ git checkout -b backup2   # 2nd copy just to be safe
$ git checkout master
$ git reset --hard <this is the revision of the last svn-id> # clean up master to make the svn merge easier
$ git svn fetch    # this should update to the current version on the svn server
$ git rebase master backup  # may get a conflict here, fix and commit
... # after conflict is fixed and commited
$ git checkout master 
$ git merge backup --ff  # merge in your local commits
$ git svn dcommit        # push back to the svn

ここで追加情報を入手できます

あなたが興味を持っているかもしれない別の答え。

git-svn ワークフローの記事

論文

于 2009-03-10T06:00:20.460 に答える
12

VonC と sfassen の並外れた忍耐力に感謝して、解決策はうまくいきました。方法や理由はわかりませんが、最初のリベースがうまくいかなかったのかもしれません。それを修正するために、私は再びリベースしました。私のローカル トランク ブランチから:

$ git co -b backup  # backup the commits to my local trunk
$ git co trunk      # return to the local trunk
$ git svn rebase    # rebase the trunk from the Svn server
$ git br -d backup  # delete the backup branch

もちろん、重要なのは今回のリベースが機能したことです。最初にやったときにうまくいかなかった理由はわかりませんが、時計を巻き戻すことはできないので、詳しくは説明しません。

みんなの提案と初心者への忍耐に感謝します。

于 2009-03-10T13:30:51.347 に答える
5

sfossenの優れた答えを完成させるために、ここにいくつかの詳細があります：

を使用git-svnすると、デフォルトでmasterという名前のローカルブランチを取得します。あなたはそれに何の作業もするべきではありません、それをsvnトランクブランチで最新に保つだけです：

  • git svn fetchローカルトランクブランチのsvnトランクブランチから履歴を取得するには：これらの変更は作業ディレクトリに適用されません
  • git checkout master トランクブランチをオンにする（別のブランチにいる場合のみ）
  • git rebase trunkマスターをトランクと同期します。

ただし、すべての変更は別のローカルブランチで行う必要があります（これを呼び出しますlocal-devel）。

  • git branch local-devel
  • git checkout local-devel

緊急の修正が必要な場合：

  • git checkout master：master（）のswith、
  • git svn fetch&& git rebase trunksvnトランクで更新する
  • git branch fastfix && git checkout fastfix、分岐します
  • バグを修正し、コンパイルし、テストし、
  • git commit -a：ローカルコミット、
  • git svn dcommit変更を遠方のsvnリポジトリに更新します
  • git checkout master && git rebase trunk：マスターを再度更新する
  • git branch -D fastfix：修正プログラムブランチを削除します
  • git checkout local-devel && git rebase master：開発に戻り、マスターで行われた更新された履歴を開発ブランチで再生します

svn diff最初は少し面倒ですが、後で適用するファイルよりもはるかに快適です。

于 2009-03-10T06:41:12.143 に答える
4

私も似たような状況でした。私はgit svn dcommit悪いネットワーク接続を介して行っていましたが、ある時点で失敗しました。この問題は、Subversion リポジトリに既に新しいコミットがあったにもかかわらず、ローカルの git-svn のカウンターパートがコミットがまだ SVN にないと見なされていたことが原因であることがわかりました。ここでの他の回答からの解決策は役に立ちませんでしたが、これは役に立ちました:

git svn reset -r <last_svn_commit_git_was_aware_of>
git svn fetch
git svn rebase

この後、最終的にgit svn dcommitエラーなしで実行できました。

于 2010-06-12T18:56:49.930 に答える
3

私はコメントするつもりでしたが、これはもっと目立つに値すると思いました...

git svn rebaseコミットを書き直すことになっています。説明とコメントから、リベースした後、古いコミットを強制的に元に戻したという印象を受けました。コミットは、競合しない新しいバージョンに置き換える必要があります。

reflog を掘り下げる必要がないように、git svn dcommit. dcommit が成功したら、タグを削除します。タグが失敗した場合は、 のgit reset --hard後にgit merge <tag>. リベースを再実行して履歴を元に戻し、タグを付け直して再度コミットします。

于 2009-03-10T15:52:02.490 に答える
3

私が読んだいくつかの場所では、git svn を使用して別のブランチを使用するのは悪い習慣です。svn に期待どおりに表示されない git コミットに関する何か。

http://progit.org/book/ch8-1.htmlからの次の回答は、最もクリーンな方法のようです。

git svn rebase
git svn dcommit

上記の最も一般的なオプションも試しましたが、常にうまくいくとは限りませんでした.

于 2011-07-07T21:10:00.950 に答える