問題タブ [cherry-pick]

マスターからコミットを選択して、現在の本番ブランチに入れようとしています。ただし、を実行するgit cherry-pick <SHA-hash>と、次のメッセージが表示されます。

注：リセットとリセット--hard HEAD ^を実行しようとしましたが、どちらも何も変更されていないようです。

なぜこれがうまくいかないのか混乱しています。

これを解決する方法についての洞察、アドバイス、またはアイデアは役に立ちます〜！

コミットを元に戻し、変更をGitの他のブランチにコミットする方法を理解しようとしましたか？でもそんなに難しいことではないと思います。（回答は使用branch -fしstashていますが、必要ないと思います。）

私は自分の開発ブランチで働いていました。ダーティな作業ディレクトリに2つの異なるコミットがありました。2つの異なるコミットですべての変更をコミットします。最後のコミットはWIP（つまり開発資料）です。stable最後から2番目が実行され、ブランチにコピーする必要があります。

私は次のようなものを想像します

しかし、私はそれではないと確信しています。

チェリーピッキングはそれと関係がありますか？

確かに：コミットを継続したいdev。そうではありませんmvが、cpそれです。

私はまだこれらすべてのGITオプションとコマンドに困惑しています。

コンテキストcrazy-idea：専用のサブディレクトリでいくつかのワイルドなことを行った実験的なブランチがありmadness/{src,docs}ます。プロットを作成するためのメモ、写真、ハッキーなスクリプトを含む大量のコミット。自分が何をしているのかを完全に理解したので、src/新しい関数を追加して既存の関数を変更することにより、実際のソースファイルを編集します。

混乱するとマスターの履歴が乱雑になるため、変更をマスターにマージするためにcrazy-idea新しいブランチが作成されました。Convinceは、ファイルを変更して、からコミットを選択することを提案します。good-ideasrc/src/crazy-ideagood-idea

今私の質問good-idea：それがマスターにマージされ、このイベントの後にいくつかのコミットがマスターで行われたことを考えると。crazy-idea私のアイデアの他の側面をさらに解明するために戻ったときsrc/、マスターにリベースするときに予想される問題はありますか？

別の方法は、そのままsrc/にしcrazy-ideaて、サブディレクトリのコピーを作成し、で直接コーディングしながらこの方法でメモを確認することgood-ideaです。

あなたたちは何がより賢いことを提案しますか？

編集まあ、予想通り、私は中に競合が発生しました

でcrazy-idea。将来的には、1つのブランチにのみ変更を導入し、それが多かれ少なかれ放棄されていることがわかっている場合にのみチェリーピッキングを使用します。

編集私は次のように私の状況を解決しました：の変更でN個のコミットがありましたsrc/。最後のsrc/変更されていないコミットに「foobar」というメッセージがあったとしましょう。リベースが失敗した後：

終わり。これは明らかに私が望んでいたほど簡単ではありませんが、それほど悪くはありません。コピーする代わりにこのルートに行くと思いますmadness/。

ここには、branch1 と branch2 という 2 つのブランチがあります。branch1 には多くの新機能が追加されており、branch2 は安定しています。今日は、branch1 から branch2 に 1 つの機能だけをマージしたいと思います。だから、私はただ走るgit cherry-pick <commit-for-feature1-in-branch1。<commit-for-featur1-in-branch1branch2 にマージされるという変更だけが必要だと思います。しかし、他の機能が含まれているため、さらに多くの変更があることがわかりました。

指定されたコミットだけの差分が取得されると思いましたよね？

参考までに、branch1 のコミットは他の開発ブランチからマージされましたが、これによりこの問題が発生する可能性はありますか?

私が何か悪いことをしましたか？

ありがとう。

Gerrit を使用して「git-flow」のようなワークフローを実装しようとしていますが、パズルの最後のピースを理解できないようです。

私の問題には2つの前提条件があります：

• Gerrit は 1 つのブランチへのマージのみを実行します
• マージ コミットを Gerrit にプッシュすることは許可しません。マージは、変更が承認された後に Gerrit が行う必要があります。

解決したいことは以下です。この git の状況を考えてみましょう:

1 つのコミットを持つ master ブランチと、複数の追加コミットを持つ master からフォークされた開発ブランチがあります。しばらくすると、develop ブランチが master にマージされ、次の製品リリースが作成されます。開発者は、develop からのトピック ブランチと厳密なリベースを使用して作業します。彼らのコミットは、プッシュする前に常に最新のアップストリーム開発の上にリベースされます。これにより、履歴が線形になり、早送りコミットのみが行われます。

ここで、誰かが master からホットフィックス ブランチを作成し、master にマージしたとします。

このコミットはマスター ブランチにのみマージされるようになりましたが、開発者は変更にバグ修正を組み込むために開発ブランチでこのコミットを必要とします。通常、マスター ブランチをマージして開発ブランチを開発しますが、私の前提条件を考慮すると、ローカル マージ コミットが作成されるため、これは不可能です。

私の質問は、開発者による新しい変更にバグ修正が含まれるように、マスター ブランチからローカルの開発ブランチに新しいコミットを組み込むにはどうすればよいですか? 理想的には、スクリプトを変更して、最初にバグ修正の変更をローカルの開発ブランチに適用し (マージしますが、マージ コミットは行いません)、次に開発者のコ​​ミットとプッシュをリベースします。このようにして、バグ修正は新しい変更に自動的に追加され、別のコミットではなく、新しいコミットの一部として表示されます。

私は可能な解決策について考えてきました：

• 開発ブランチへのコミットをチェリーピッキングします。次回開発がマスターとマージされると、これは常に重複したコミットになると思います。これを回避する方法はありますか？
• ここで説明されているようにリベース: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/。これは、開発ブランチが公開されているため、おそらく問題を引き起こしますか?

私の質問が明確であることを願っています。さらに明確にする必要がある場合はお知らせください。私は自分のワークフローにかなり厳格であることを知っていますが、Gerrit と組み合わせると理想的です。それができない場合は、おそらくマージコミットを許可します...

私はPythonプロジェクトを持っていて、今日それをgithubに置くことにしました。私はそれで初心者です。いくつかのチュートリアルがあります。私がやりたいことを除いて、すべてうまくいきます：

私はその日にラップトップでコーディングしていて、家に帰ってもコンピューターで作業を続けています。今のところ、ラップトップでリポジトリを作成し、それをgithubにプッシュします。コンピューターで家に帰ったとき、レポジトリのクローンを作成して、コードの作業を続けました。しかし、もう一度githubにプッシュすると、ラップトップにもう一度「ダウンロード」して翌日作業を続ける方法がわからない場合を除いて、すべて正常に動作します。

私が見つけたのは「チェリーピック」を作ることだけです。それが正しいかどうか、そしてこの状況でどのように処理するかはわかりません。

私は Subversion から Mercurial に移行しています。ここでは、svnmerge.py を使用して、既にマージされた変更、またはマージがブロックされた変更を追跡することに慣れています。

hg プル/プッシュ/マージ/グラフトで同様のことを実行できるようにしたいので、特定の変更をマージしたくないことがわかっている場合は、それを検討からブロックして、その後のチェリーピッキング、マージ、など、よりファイアアンドフォーゲットな事件に。私はたくさんのグーグルをしましたが、これを行う方法を見つけていません。

また、まだ移植されていない変更のリストを表示する方法もないようです。

私はよく他の開発者の後を片付けたり、彼らのマージを手伝ったりしているので、この種のことを実行できることは非常に役に立ちます。つまり、マージしたくない変更をマークしてから、残りを一括マージします。

git には master/ と 1.7/ の 2 つのブランチがあります。チェリーピックを使用して、master/ から 1.7/ にいくつかの修正をバックポートします。(一部の変更のみが必要なため、マージは使用していません。):

その後、1.7/ を master/ にマージして戻します。これは、1.7/ に加えられたすべての変更 (cherry-picks テーマ自体を除く) をメインラインにマージして戻すためです。

私の問題は、これが(元は master/ からの) チェリーピックを master/ に再度コミットすることです:

私の実際のリポジトリでは、マージの競合さえ引き起こしました。

私の質問は、これを回避できますか (そうであれば、どのように) ですか?

この動作を再現するコマンドの完全なリスト:

私は別の組織のリポジトリのフォークを持っています。私はレポの最新のタグにいますが、これはヘッドではありません。そのタグから、上流にプッシュされることのないブランチを作成しました。そのため、私はブランチを非公開と考えています。

私は自分のプライベート ブランチにコミットし、そのコードを本番環境で使用しています。アップストリーム リポジトリに新しいタグが作成されたときに、その変更をプルできるようにしたいと考えています。

ただし、コミットを常に最後のタグの上にきちんとスタックしておきたいと思います。私のコミットは履歴のはるか昔にさかのぼってしまい、リポジトリで特定のツールを使用するときに簡単に作業できるように、それらを一番上に表示したいので、マージしたくありません。

つまり、アップストリームの変更をリポジトリに持ち込んだときに任意のポイントに移植できる「フローティング」ブランチが必要です。

[編集] ただし、履歴を書き換える操作であるため、リベースを使用できるとは思いません。ご覧のとおり、私は開発用と本番用の 2 つのマシンでリポジトリを使用しています。開発マシンでコミットを行い、github にプッシュしてから、本番環境にプルします。これらはすべて、私が最初にフォークしたアップストリーム リポジトリの変更とは何の関係もありません。

移植、チェリーピッキング、またはその他のツールが適しているかどうかは完全にはわかりません。ただし、どのツールであっても、歴史を書き換えるべきではないと私は考えています。私の読書から、プッシュ時にレポ履歴を書き換えることはできないことがわかります。したがって、履歴を書き換えずにブランチを移植するコマンドを使用する必要があるかどうかはわかりません。

Mercurial を使用していた場合、バージョン管理された mq のようなものを検討するかもしれません。git の類似のソリューションがあるかどうか、または git により適した別のツールがあるかどうかはわかりません。

[編集]

ここで得た回答を評価した後、最終的にチェリー ピッキングが正しい答えであると判断しました。すべての場合において、リベースは履歴を削除します。これは共有リポジトリであるため、少なくとも私が読んだすべてのソースによると、履歴の削除は受け入れられません。

ただし、チェリーピッキングは、コミットを元の場所から削除せずに作業ツリーにコピーします。そのため、最新のタグの上に変更のコピーを植えて、きれいな山にまとめることができます。

記録のために、hg を使用して git リポジトリのクローンを作成できる hg-git 拡張機能を使用して、Mercurial でもこれを実行しようとしました。これにはプラスとマイナスがありました。一番のマイナスは、使い終わったら押せなくなったことです。hg-git はその時点まで問題なく動作し、その後、hg 1.9 ではプッシュしないことが通知されます。控えめに言っても、偽物です。もう 1 つの欠点は、大量の変更セットの複製とプルが非常に遅いことです。ただし、mq と TortoiseHg のマージ競合解決ツールは、git cherry-pick と Smartgit のマージ競合解決よりも大幅に改善されています。hg-git が機能していればよかったのに。

最終的に、「フローティング」という表現は、変更ブランチを移動するのではなく、コピーすることになるため、私の変更ブランチの適切な説明ではなかったと思います。おそらく説明が不十分で申し訳ありませんが、オプションが何であるかを正確に把握していました。助けてくれてありがとう。

GITマスターに簡単な質問があります。

GITのマニュアルページで私はこれを持っています

私の疑問は、別のブランチへのコミットをチェリーピックすると、このコミットは他のブランチに移動されるか、コピーされますか（両方のブランチに適用されます）？