問題タブ [git-merge]

次のリポジトリ レイアウトがあります。

• マスター ブランチ (本番)
• 統合
• 働く

私が達成したいのは、作業ブランチからさまざまなコミットを厳選し、それを統合ブランチにマージすることです。私はgitにかなり慣れていないので、リポジトリを台無しにせずにこれを正確に行う方法（マージではなく、1回の操作でコミット範囲をチェリーピッキングする）を理解できません。これに関する指針や考えはありますか？ありがとう！

パッチなどを適用することで手動で同期された git-svn ブランチのペアがあります。git-merge使用されていません。ブランチは同期しています。つまりgit diff A B、出力はまったくありません。

git-svn と SVN の関連付けを失うことなくgit merge、将来が今日の HEAD をマージベースとして使用するように、git に 2 つのブランチがマージされたと見なすにはどうすればよいですか?

私が試したこと

1. git checkout A; git merge B

   これにより、SVN 分岐点がマージ ベースとして選択され、手動で行われた長年にわたる重複したクロス マージの解決が試みられます。

(このリストは増えると予想されます)

マスターブランチの機能をきれいにマージするために使用したいと思いますgit rebase（コミット数を減らすか、少なくとも変更ログの先頭で）。リポジトリで作業しているのは私だけであることに注意してください。

Gitワークフローとリベースとマージの質問を読んだ後、私はかなりいいと思いました。ミカのように、さまざまな場所（ノートブック、自宅、別のPCなど）から変更をリベースgit rebaseしたいのです。 ..）git push

したがって、ここに2つの解決策があります（双方向の醜いマージに対する）：

1. を使用git push -fしてプッシュしてから他のマシンをプルしますが、他のマシンで最新バージョンをクリーンに取得するにはどうすればよいですか？
2. マージを使用してマスターの変更を機能ブランチにマージし、git push / pullし、成熟したら、単一のリベースを実行します（1つ以上のコミットでクリーンに）

（2）以下のようになります：

どの解決策がうまくいくと思いますか？私はこれまでどちらも試していません（主にログが乱雑になることを恐れて）。

これは現在、私たちのプロジェクトの 1 つで gitk がどのように見えるかです:

https://dl.dropbox.com/u/2582508/gitk.png

これは、リモート ブランチで単一の「git マージ」が実行された後に発生したようです。理由や何が起こっているのかはわかりません。ここで何が起こったのか分かりますか？

さらに重要なことは、それを修正するための最良の方法は何ですか? これらのマージ コミットは空ですが、「git rebase -i」を実行すると、通常、マージ コミットは表示されないようです。

最も重要なことは、履歴を他のクローンと互換性がないようにしないことです。つまり、履歴をプル/プッシュ/マージできるようにする必要があります。それは可能ですか？

マスター ブランチ内で、git merge some-other-branchローカルで実行しましたが、オリジン マスターに変更をプッシュすることはありませんでした。統合するつもりはなかったので、元に戻したいと思います。git statusマージ後に実行すると、次のメッセージが表示されました。

見つけたいくつかの指示に基づいて、実行してみました

しかし今、私はこのメッセージを受け取っていますgit status:

私のブランチが何回もコミットされたくないのです。どうすればその時点に戻ることができますか?

2つのブランチを持つgitリポジトリがあります。リポジトリのクローンを作成すると、マスターブランチしか表示されません。私は両方の支店を最新の状態にしています。問題は、マージと分岐を完全に理解していないことです。くそー！

私の例はここで見ることができます：

http://github.com/rimian/rimian/network

誰かがこれを通常に戻す方法を教えてもらえますか？

Git Community BookのBasic Branching and Mergingセクションを読みました。

だから私はそれに従って、1 つのブランチを作成します: experimental.

その後私は：

1. 実験的ブランチに切り替える (git checkout 実験的)
2. たくさんの変更を加える
3. コミットします (git commit -a)
4. master ブランチに切り替える (git checkout master)
5. いくつかの変更を加えてそこにコミットします
6. 実験的 (git checkout 実験的) に戻す
7. マスターの変更を実験的にマージします (git merge master)

8. いくつかの競合がありますが、それらを解決した後、「git add myfile」を実行しました

9. そして今、私は立ち往生しています、私はマスターに戻ることができません

私がする時

そして私はしました：

進行中のリベースはありませんか?

そして私はしました：

master ブランチに戻るにはどうすればよいですか?

Vimdiffを読み、 Vimdiffとの違いを表示することに加えて、「vimdiff multiple」、「vimdiff git」、「vimdiff コマンド」などを使用してさまざまな Google 検索を行い ました。

do または diffg を使用すると、「差分モードに 2 つ以上のバッファがあります。どちらを使用すればよいかわかりません」というエラーが表示されます。

diffg v:fname_in を使用すると、「v:fname_in に一致するバッファがありません」というメッセージが表示されます。

vimdiff のドキュメントから:

:[range]diffg[et] [bufspec]
現在のバッファを変更して、別のバッファとの違いを元に戻します。[bufspec] が指定されている場合、そのバッファーが使用されます。[bufspec] が現在のバッファを参照している場合、何も起こりません。それ以外の場合、これは diff モードで別のバッファーが 1 つある場合にのみ機能します。

もっと：

'diffexpr' が空でない場合、Vim は上記の形式で差分ファイルを取得するために評価します。これらの変数は、使用されるファイル名に設定されます。

v:fname_in 元のファイル
v:fname_new 同じファイルの新しいバージョン
v:fname_out 結果の差分ファイル

そのため、bufspec の名前を取得する必要がありますが、デフォルトの変数 (fname_in、fname_new、および fname_out) が設定されていません。

ターミナルを介してLinuxボックスでコマンドgit mergetoolを実行しました。

[編集] より多くの疑問を生んだ部分的な解決策。バッファの下部にある「ファイル名」を使用しました。ファイルが存在しないというエラーが時々発生するため、半分の答えにすぎません。「存在しない」のは一貫してファイルのリモートバージョンだと思います。これは git とインデックス作成に関係があると思われます。

git-mergetool で vimdiff を使用しているときに、一貫して bufspec 値を取得するにはどうすればよいですか?

継続的インテグレーションにはTeamCityを使用し、ソース管理にはGitを使用します。一般的に、それはかなりうまく機能します-便利で、現代的で、テストが失敗したときの迅速なフィードバックを私たちに提供します。

Gitマージの詳細に関連する奇妙な動作があります。ケースの手順は次のとおりです。

1. 最初の開発者はマスターリポジトリからプルします。
2. 2番目の開発者はマスターリポジトリからプルします。
3. 最初の開発者はローカルでコミットAを作成します。
4. 2番目の開発者はコミットBをローカルで作成します。
5. 2番目の開発者はコミットBをプッシュします。
6. 最初の開発者はコミットAをプッシュしたいのですが、最初にコミットBをプルする必要があるためできません。
7. 最初の開発者はリモートリポジトリからプルします。
8. 最初の開発者はコミットAをプッシュし、マージブランチコミットを生成します。

マスターリポジトリでのコミットの履歴は次のとおりです。

• B2番目の開発者
• 最初の開発者
• ブランチの最初の開発者をマージします。

ここで、SecondDeveloperがコミットBで失敗したテストを修正したと仮定します。

TeamCityが行うことは次のとおりです。

1. コミットBが到着-TeamCityは、すべてのテストに合格してビルド＃1を作成します

2. コミットAが到着-TeamCityはビルド＃2（コミットBなし）のテストバーを赤にします！

3. TeamCityは、保留中の「Merge Branch」コミットには変更（新しいファイル）は含まれていないと考えていましたが、実際にはコミットBのマージが含まれているため、TeamCityはここで新しいビルドを作成してテストをグリーンにしたくありません。

ここに2つの問題があります：1。この場合、2番目のコミット（コミットA）に戻るテストに失敗しました。2。TeamCityは、新しいビルドを作成してテストをグリーンに戻したくありません。

誰かがこの問題の両方を修正する方法を知っていますか？

私はいくつかの合理的な一般的なアプローチを検討します。