11

私は github ソーシャルコーディングにかなり慣れていないため、github ガイドラインに従うのに苦労しています。何が起こったのか、何を達成しようとしているのかを説明しようと思います。より経験豊富な git ウィザードが、そこに到達するために必要なアーケード コマンドを理解するのに役立つことを願っています。

どうしたの

  1. 私は2012 年 7 月に MassTransit をフォークしました。当時のマスターブランチはバージョンv2.1.1で、最後のコミットは 2012 年 3 月 29 日でした。
  2. github のアドバイスに従い、トピック ブランチでいくつかの変更のコーディングを開始しました。
  3. いくつかのコミットの後、機能が完成したときに、トピック ブランチをクローンのローカルマスターにマージし、それを github にプッシュしました。
  4. 2012 年 3 月 29 日以来、MassTransit は開発ブランチで開発されていました。v2.6.0 を構成するこれらの変更はすべて、最近マスターにマージされました。

やりたいこと

アップストリーム/マスターにマージされたすべての変更を取得したいと思います。できれば、数百のファイルの 1 つの大規模なコミットではなく、それぞれのコミットとして。以前の アップストリーム/マスター(2012 年 3 月 29 日付け) で開発を行っていたため、3 月 29 日の最後のアップストリーム/マスターの変更と 8 月 8 日の最初のコミットの間にいくつかのコミットを効果的に「挿入」する必要があると思います。その上に、後で起こったことを追加します。それ、どうやったら出来るの？

(また、その過程でコミット/フォークを破棄したくありません;-)

私が試したこと

git checkout master
git remote add upstream git://github.com/phatboyg/MassTransit.git
git rebase upstream/master
git push

git pushしかし、私のローカル ヒントがオリジンより 10 コミット遅れていると不平を言って、それは私にはできませんでした (おそらく、トピック ブランチで作成し、後でorigin/masterにマージされたコミットですか?)。

おすすめは？

お勧めに噛まれてしまったようです。例えば。おそらく、別のブランチを作成する方がよいでしょう。local-master、それを自分のマスターとして扱います。その後、マスターは上流/マスターと連絡を取り合うためだけにそこにあり、私は時々オリジン/マスターを上流/マスターにリベースし、オリジン/ローカルマスターとマージします...

皆さんはどのようにフォークを管理していますか?

その他の質問

ブランチの履歴、どのブランチが別のブランチといつマージされたかなどを視覚化する方法を見つけることができませんでした。Github for Windows は、現在選択されているブランチのフラットな履歴のみを表示します (ここでは悲しい顔です)。Web サイトには、ネットワークの視覚化がいくつかあります (ここに MassTransitの視覚化があります) が、これは TortoiseHg のグラフよりもはるかに情報量が少ないと感じます。明らかな何かが欠けていますか？他の人は、何がいつ、何とマージされたか覚えていますか?

編集（8月31日）

何が起こったのかを説明するために、貧乏人の視覚化を共有しています.

  1. C1がupstream/masterで最新だったときにフォークしました。
  2. 次に、 origin/feature-1を開発しました。
  3. 機能が完成したら、それをorigin/masterとマージしました。
  4. アップストリーム/メガ機能が完了すると、アップストリーム/マスターとマージされ、事実上、 C2とC3がアップストリーム/マスターにコピーされました。(あるいは、アップストリーム/マスターがアップストリーム/メガ機能にリベースされたのでしょうか?)
  5. C2、C3、およびC4をorigin/masterにコピーしたいと思います。
4

2 に答える 2

6

originフォークにリモートをセットアップするか、セットアップすることを想定していますupstream。

upstream次に、すべてのブランチがローカルに保持されるように、のフェッチを行います。次に、レポを比較して、分岐日またはその近くに共通のコミットがあるかどうかを確認できます。

ここgitk --allで視覚化が役立ちます。リベースを行っても、古いコミット シリーズはまだそこにあるので、名前を付けることができることを忘れないでください。

[編集] 冗長な説明。

明らかに、マージ コミットは「邪魔をしている」ため、リポジトリを再び同期できるように、マッサージを取り除く必要があります。

  1. 現在の頭にブランチを作成して、temp何も失われないようにします。
  2. resetmaster ブランチは、あなたとアップストリームの間の最後の共通コミットに戻ります。
  3. reset機能ブランチをマージの直前に。
  4. checkoutコミットをマージして、期待どおりに作業ツリーを取得し、
  5. 機能ブランチに切り替えます (何もチェックアウトせずに!)
  6. commitfeatureブランチの作業ツリーを修正しました（つまり、マージはありません）。

これで、にはクリーンなライン、masterにはクリーンだが古いライン、 にfeatureはマージ後の展開がありtempます。Happy の場合、これを強制的に にプッシュできるはずですorigin。

  1. pull上流から - それ（つまりmaster、など）はすべて早送りする必要があります。
  2. rebaseそれらは、 (必要に応じて)tempからのマージ後の開発を行います。feature
  3. rebase featureマスターでよく知っている最後のコミットまで（比較的簡単なはずです）。
  4. rebase feature(再び) マスターの最新のコミットに移動し、修正します (簡単な場合は最後のステップと組み合わせてください;-)。

これにより、最終的にマスターの先頭で機能開発のクリーンなラインが得られ、競合することなくアップストリームにプルするのに適したものになります。

于 2012-08-30T22:43:03.213 に答える
2

ここにいくつかのアイデアがあります。

チェリーピック方法:

git checkout master
git cherry-pick C2..C4

新しいブランチ リベース メソッド:

git checkout upstream/master
git branch new-master
git rebase master
# new-master should now look like what you want, once you confirm this
git branch -m master old-master
git branch -m new-master master

リベース --onto メソッド (必要なコミットの範囲を選択できます):

git checkout master
git rebase --onto master C2 C4 # puts you into a detached HEAD
git branch new-master
# rename branch as above if it is correct
于 2012-08-31T10:29:46.410 に答える