8

マスターからリポジトリの1つ内の「デプロイ」ブランチへのリベースに問題があります。

私のリポジトリは次のように設定されています。

master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master

一般的に私のワークフローは次のとおりです。

  1. マスターブランチで開発を行います...テスト、笑顔、コミットします。
  2. deployブランチをチェックアウト
  3. デプロイブランチで実行git rebase masterします-これは問題なく機能していました
  4. リモートにプッシュして実行しますcap deploy
  5. リラックス

私が今抱えている問題はgit rebase master、デプロイブランチで実行すると、3方向のマージ/手動マージが必要なエラーが発生することです（エラーメッセージは、投稿するのに十分なほど一般的ではないと思います）。Gitは、マージを実行してgit rebase --continueから終了するように指示しますが、これは機能しません。

私が見つけたのは、「実行中」の作業でgit rebase master --interactive、選択リストをクリーンアップし（5回ほど繰り返される「コミット」がありますが、このリストには異なる参照番号（同じメッセージ）があるため、そのうちの1つを選択します）。手動でマージを実行します。コミットごとにこれを実行したら、リベースを続行でき、すべてが幸せになります...

次回まで、リベースを実行する必要があります。

それで、誰かが何が幸せかもしれないか知っていますか？プロジェクトは実際には「秘密」ではないので、必要に応じてメッセージ、ログ、ブランチグラフなどを投稿できます。

ありがとう

4

3 に答える 3

2

作業をgit rebase --continue開始するには、競合するファイルを実際にマージする必要があります（ファイルを編集し、競合マーカー「＆lt; <<<<<<」、「=======」、「>>」の間から必要な部分を選択します。 >>>>>”）そしてgit addそれらをインデックスに追加します（インデックスはそれらが競合として記録される場所であり、ファイルを追加すると競合状態がクリアされます）。現在の差分をgit diff --cached、で確認し、git rebase --continue正しく表示されるかどうかを確認します。

リベースを試みる前に（または問題のあるものを中止した後）、git log -p master..deployリベースしようとしているコミットを確認してください。あなたがマスターに持っているものと矛盾しているのはこれらの1つです。

'pick'行を削除してドロップするコミットは、完全に同じでgit rebase -iはない可能性があります（コミットメッセージに同じ'subject'が含まれている場合でも）。それらの1つだけが存在するはずだと思うという事実は、デプロイブランチで何か怪しいことが起こっていることを示しています。これらの「重複した」コミットはデプロイの先端にありますか、それともそれらの後に他のコミットがありますか？たぶん、それらの「怪しげな」コミット（log -p上記）の内容を見ると、それらのソースに関する手がかりが得られます。

于 2009-10-27T09:54:35.053 に答える
2

発生しているように聞こえるのは、それらの「繰り返される」コミットのコミット履歴を変更して、異なるsha1を持つようにしたことです。各sha1は、コミットだけでなく、コミット履歴にも固有です。したがって、同じ履歴に2つの同一のsha1を含めること、または2つの異なる履歴に2つのsha1を含めることは不可能です（宇宙の存続期間中に発生する可能性は非常に低いです）。修正やインタラクティブなリベースなど、コミットで何かを変更した場合は、sha1を変更します。したがって、同じように見える可能性のある2つのコミットは、実際には異なる方法で処理されます。

おそらく、他のブランチからリベースしたり、ある種のインタラクティブなリベースを行ったり、コミットを修正したり、コードの同じ部分を変更したコードをさらにコミットし続けたりした後、次のリベースで競合が発生する可能性があります。リベース元のブランチとは異なるローカルブランチをブランチから削除し、既にプルインしてsha1を変更したコミットを含めてアップストリームをプルインし、コミットがブランチで再生されるとコードの状態が、現在ブランチにあるものとは異なる履歴から作成されたものであるため、コミットが期待されていたものから変更されたため、競合が発生します。うわー、それは長い文章でした...

選択リストを「クリーンアップ」しているとき...実行しているのは、リベースする前にこれらの繰り返されるコミットを削除する可能性が高いため、すでに適用されている変更を再適用しないため、競合が発生しなくなります。

ただし、リベース中に競合を解決したいだけの場合は、これが最善の策である可能性が高いため、必要なコミットを誤って削除しないでください。競合を解決すると、そのコミットの変更セットが、現在の履歴に適用できるようになります。このマージ競合解決をプッシュすると、すでにプッシュされているコミットを変更しない限り、問題が再び表示されることはありません。

マージの競合があるファイルを見つけるには、次のようにします。

git status

また

git ls-files -u

どのファイルに競合があるかがわかったら、mergetoolを設定している場合は、次のことができます。

git mergetool <file>

手動でマージする場合は、次のようにしてマージマーカーと行を見つけることができます。

grep -Hnr '^=\{7\}\|^<\{7\}\|^>\{7\}' *

リポジトリパスのトップレベルで編集します。手動で編集する場合は、マーカーを削除して、ファイルの最終バージョンを希望どおりに表示するようにしてください...gitはマーカーに対して特別なことは何もしません。手動で編集を終えたら、必ず行ってください

git add <file>

ファイルを追加してインデックスに追加し、マージされていないフラグを削除します。マージされていないすべてのファイルの解決が完了したら、

git rebase --continue

リベースを完了します。

于 2011-06-14T22:46:53.757 に答える
1

マージの場合にデプロイブランチのコンテンツを常に選択するために、「デプロイ固有の」ファイルの親ディレクトリに属性を定義できます。

マージマネージャーの例については、このSOの回答を参照してください。

他の戦略についても説明しましたが、重要な点は残っています。マージは、ファイルベースのマージではなく、常に「プロジェクト全体のマージ」と見なしてください。したがって、いくつかの「特別な」ファイルに関しては、プロジェクト全体のマージを改善するための属性があります。

于 2009-08-01T15:30:46.923 に答える