問題タブ [git-merge]

そのため、ファイルの 1 つにパッチを作成していたところ、存在しないはずのコードがいくつかありました (この悪意のあるコードによって引き起こされた Web ページのエラーと相まって)。コードは数か月前にパッチで追加され、約 1 か月前にそのコミットを元に戻すことで削除されました。だから本当にあってはならない。

どこから来たのかを突き止めるために、いくつかの方法を試しました。

1. git Blame: 奇妙なことに、コードを追加した元のコミットのコミット タグとメッセージが表示されました。まるで元に戻すことがなかったかのように。
2. git log -- filename: 元に戻すことを含め、そこにあると予想されるすべてのコミットを表示しましたが、その後、再表示する必要があることを示唆するものは何もありませんでした。
3. 手動チェック パッチ (バイセクト): コードは復帰直後のコミットで再表示されましたが、そのパッチをチェックアウトすると、そのログはまったく異なり、復帰はありませんでした。

この最後の観察から、問題のパッチは失敗したマージであると結論付けましたが、コミット メッセージにはマージについての言及はなく、私たちのチームは通常、git が生成したマージ メッセージを保持しています。

それで、そのように見えますか？競合の解決中に間違った選択をして、コードが再導入されましたか? もしそうなら、この種のものを見つけるためのより速い方法はありますか? たとえば、git の非難は、コードが私の元のパッチから来たと述べています。しかし、元に戻した後、パッチ X で再導入されたことを直接教えてもらう方法はありますか? マージ中にコードが影響を受けたことがわからない場合、git はどのようにして各コードがどこから来たのかを追跡しますか? マージの競合中に誰かがそのコードをいじったことを私に伝えることができますか? 私は、マージ自体が責任を負うべきだと考えていました。

から新しいブランチmasterが作成されます。これを と呼びますtest。

master他のブランチにコミットまたは作成し、後で にマージする開発者が何人かいますmaster。

の作業に数日かかっており、内部のコミットで継続的に更新しtestたいとします。testmaster

git pull origin masterからやりますtest。

質問 1:これは正しいアプローチですか? 他の開発者は、私が作業したのと同じファイルで簡単に作業できたはずです。

作業testが完了し、 にマージする準備が整いましたmaster。私が考えることができる2つの方法は次のとおりです。

A:

B:

--rebase私の理解では、リベースは変更を取得し、masterその上にスタックするため、他の人が行った変更を上書きする可能性があるため、使用していません。

質問 2:これら 2 つの方法のうち、正しいのはどれですか? そこの違いは何ですか？

これらすべての目標は、testブランチで起こっていることを最新の状態に保ち、master後でそれらをマージしてmaster、タイムラインをできるだけ直線的に保つことです。

私のチームは、「topic1」と呼ぶgitの共有トピックブランチに取り組んでいます。私はtopic1で作られたブランチでいくつかのコードのリファクタリングに取り組んでいました。これを「リファクタリング」と呼びます。定期的にtopic1をリファクタリングにマージして変更を最新の状態に保つことができますが、リファクタリングがまだ進行中であるため、リファクタリングをtopic1にマージし直していません。

最近マスターから作成された「topic2」と呼ぶ別のトピックブランチがあります。私がやりたいのは、「リファクタリング」で行った変更のみを、「topic2_refactor」と呼ぶtopic2で作成された新しいブランチにマージすることです。（つまり、リファクタリングによってのみアクセス可能で、topic1によってはアクセスできないコミットの変更。）

私はこれらの変化だけを見る方法を知っています：

だから私がやりたいのはこのようなものです-しかしこの構文は正しくありません：

そしてこれ：

またはこれ：

（上記は、後でリファクタリングブランチにマージされたマスターで発生したいくつかの変更のために、必要のないマージの競合を引き起こしているようです。）

これを実行し、後で「リファクタリング」ブランチの履歴で解決された不要なマージの競合を回避するためのクリーンな方法があることを期待していました。これは、git rebase、git filter-branchなどを使用して可能でしょうか？

git pull競合に終わったを実行しました。競合を解決し、すべて問題ありません（mergetoolも使用しました）。

解決済みのファイルをコミットするとgit commit file.php -m "message"、次のエラーが表示されます。

以前に同じ問題があり-a、コミットで使用すると完全に機能しました。すべての変更をコミットしたくないので、これは完璧な方法ではないと思います。個別のコメントでファイルを個別にコミットしたい。どうやってやるの？マージ後にユーザーがファイルを個別にコミットすることを git が許可しないのはなぜですか? この問題に対する満足のいく答えは見つかりませんでした。

いくつかの「共通の祖先」が利用可能なシナリオでマージを実行しているため、Git は「git merge recursive」戦略を実行します。

そのため、マージを実行して新しい祖先を作成し、それが今度は私が取り組んでいる寄稿者の CA として使用されます。

OK、問題は次のとおりです。「先祖」がGitによって内部的に実行される「再帰マージ」に由来する競合のあるファイルがあるため、KDiff3を使用してgit mergetoolで競合を修正しようとすると、次のように表示されます。

これは正常ですか？私の例は少し「単純すぎる」(ファイルに 1 行しかないため、現実的ではない) ですが... この共通の先祖を持つことは役に立ちますか?

ありがとう！！

ホットフィックスブランチをマスターにマージしています。単純なgit merge hotfix-2.09マージを早送り'merge branch "hotfix-2.09"'すると、ログにコミットが記録されます。ホットフィックス01-08はこれを行いませんでした。このマージで何か問題が発生したのでしょうか、それともマスターの状態が何らかの形で変化したのでしょうか。

編集これは実際には早送りではありませんが、そのように動作していると思います。

いくつかのベストプラクティスに興味があります。

プロジェクトにサブモジュールとして含めたいgitリポジトリがあります。また、このレポに貢献し、プルリクエストを提供したいと思います。リポジトリをフォークしました。フォークをサブモジュールとしてプロジェクトに追加したいと思います。

フォークに新しいslimブランチを作成し、元のリポジトリマスターブランチからいくつかのものを削除しました。たとえば、サンプルファイル、デモなどです。特に、このslimブランチをサブモジュールに使用して、余分なものを排除したいと思います。

私はこの分岐とサブモジュール戦略を成功裏に実行しました。しかし、私は今、プルリクエストとプロジェクトへの貢献について疑問に思っています。

理想的には、プロジェクトの一部としてサブモジュールを編集し、コミットをサブモジュールslimブランチにプッシュしたいと思います。slim次に、ブランチの変更をマージしmasterて、プルリクエストを実行できるようにします。

slimただし、ブランチでの最初の削除コミットをマスターにマージして戻したくありません。いくつかの削除コミットを台無しにすることなく、プロジェクトに貢献できるいくつかの方法は何ですか？

マージ先のサブディレクトリがかなり深くネストされている git のサブツリー マージ ステートジーを使用しようとしています - 現在は 4 レベルの深さです。

ここの指示に従って、モジュール リポジトリをリモートとして追加し、git read-tree を実行してリモート コードをローカル リポジトリのサブディレクトリに取得し、それらの変更をコミットしました。

私の問題は、リモートからメイン プロジェクトのマスター ブランチに変更をプルしてマージしようとしたときに発生します。上記のページのステップ 5 は、-s サブツリー スイッチを使用した git pull を提案しています。これは、サブディレクトリの深さが 1、2、または 3 レベルで、4 レベルでない場合に正しく機能します。

これは、2 レベルの深さのサブディレクトリにマージした結果です。sites/all/ の README ファイルが正しく更新されていることがわかります。私のリモート リポジトリでは、README はルートにあります。

ここで、サブディレクトリは 3 レベルの深さです: sites/all/modules/. これも問題なく機能し、変更をプルしてファイルを更新します。

しかし今、私のコードは 4 レベルの深さのサブディレクトリにあります: sites/all/modules/my_module/. Git は REMOTE_REPO から変更を取得しているように見えますが、ファイルは更新されず、代わりに既に最新であると通知されます。

すぐにもう一度実行すると、変更が取り込まれたり、ファイルが更新されたりしません。

この時点で git ログを表示すると、リモート リポジトリとマージからの変更が表示されますが、チェックアウト内のファイルは更新されていません。

これはバグですか、それとも何か間違っていますか?

更新: Chris Johnsen は、エラーをスローする次のオプションを提供しました。