リモートオープンソースプロジェクト(たとえばGithub上)からローカルリポジトリをクローンしたとします。ブランチを追加するなどローカルリポジトリを変更します。メインリポジトリに選択的にサブミットする手法
以下の点を念頭に置いてください。あなたが行った変更のいくつかは、独自の目的のためであり、メインリポジトリには戻されません。その他のバグフィックスや機能の追加メインレポに寄付したい人
それに基づいて、2つの主要な分岐を想定しましょう:全ての変更のためのdev-proj、メインリポジトリに戻すサブセットのdev-comm。
一般的なケースでは、特定の変更がdev-commに入るかどうかを知ることができるので、それらをブランチに分離することができます。
しかし、変更が上流に寄与すべきかどうかによって分岐が指示されないようにする厄介なケースがあります。
例えば、Webアプリケーションのローカライゼーションの場合を考慮して、翻訳とビューの変更などを行います。ブランチを作成してプライベートにするつもりですが、作業中に元のコードに問題があることが分かります。そのため、このブランチで作業の一部として修正する必要があります。そしてこれらのWRTをi18nに変更して、分離してメインのレポにプッシュバックします。
私の質問は、この状況を処理する最善の方法を選んでいることです。私は心配しています。 コミットを細かくしようとすると気を散らしてしまいます。プライベートコミュニティの変更の塊、その後、私はそのための修正を適用しようとする必要があります。あるいは、いくつかの手作業の要素が含まれていても、より良いテクニックがあります。
編集:私はラフスケッチを明らかにするよ:pはローカルプロジェクトのためであり、cは、具体的には、コミュニティのために上流にプッシュされることを意図し、変更のためです:
Ep--Fc--Gp--Hc--Ipc(commit not granular!)--Jc topicA
/
A--B--C devProj
|
\ Q--R devComm
|
\ Fc--Hc--I2c--Jc topicAcomm
TOPICAに取り組んでいる間、私たちはどのパーツがコミュニティのためのものなのか心配したくはありません。しかし、最後に、devCommにマージして上流にプッシュできるtopicAcommのようなものを用意したいと考えています。
私の質問は、チェリーピッキングがこれを処理する方法であるかどうかです。これは、ドキュメント/チュートリアルをチェックすることによるもっともらしい方法です。あるいは、あとでコードに注釈を付けるなどのいくつかのトリックや、私が気づいていない他のトリックがあります。
偶発的な混乱したコミットが発生する可能性がある1つの問題に過ぎません。
情報ありがとうございます。これらのリソースを確認します。 –
これは、リベース - 対話型の典型的な使用例です。どうも。 –