2012-04-15 4 views
2

リモートオープンソースプロジェクト(たとえば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つの問題に過ぎません。

答えて

1

original git branches managementからいくつかのアイデアを得ることができます。詳しくは "gitworkflows Manual Page"を参照してください。

私はむしろ、個々のチェリーピッキングに頼るのではなく、公共のブランチにマージを行うために、あなたのトピックブランチの歴史を並べ替えるでしょう(問題を後で証明することができた:「How to merge a specific commit in git」を参照)

rebaseがあれば、チームは自分のトピックブランチを新たに注文されたトピックブランチにリセットする必要がありますが、コミュニティ(はるかに大きなグループ)に何かをリセットするように依頼するよりも管理しやすくなります。

自動並べ替えのための1つのトリックは、並べ替えとグループ(「Trimming GIT Checkins/Squashing GIT History」を参照してくださいコミット思われるgit rebase --interactive --autosquashです。

+0

情報ありがとうございます。これらのリソースを確認します。 –

+0

これは、リベース - 対話型の典型的な使用例です。どうも。 –

1

「git rebase -onto ...」を見てください。あなたの例では、2つのステップと考える:1)あなたの 'i18n'変更を 'rebase'で自分のブランチに分離し、2)dev-projでそのブランチをマージする。 'gitのヘルプリベース' から、例の1:

If we have the following situation: 

             H---I---J topicB 
             /
         E---F---G topicA 
         /
    A---B---C---D master 

    then the command 

     git rebase --onto master topicA topicB 

    would result in: 

         H'--I'--J' topicB 
        /
         | E---F---G topicA 
         |/ 
    A---B---C---D master 

次にこのことから、あなたが戻っtopicB(DEV-COMM)のマスター(DEV-PROJ)にtopicBをマージすることができます。

+0

申し訳ありませんが、質問が混在してTOPICAなどのトピックブランチを持っていることについて、いくつかの民間プロジェクトのために意図されているコミットし、いくつかさtopicAに取り組んでいるうちに、プライベートとコミュニティのどちらの変更が心配されているのか心配したくはありませんが、どういうわけかそれらに注釈を付け、後でそれらを別々のブランチにフィルタリングしたいのです。 –

+0

私の記述されたアプローチは、コミットが連続している場合、または2つの連続したグループの場合にのみ機能します。あなたはそれを一つ一つ選ぶ必要があります。 ABCDEFGHIJを持つブランチを連続したコミット(例えばABCD EFG HIJ)を持つ3つのブランチ(master:topicA:topicBのようなもの)に変換してからrebase -ontoに変換するのは簡単です。 – GoZoner

+0

インタラクティブなリベースでは、コミットを並べ替えることができます(http://gitready.com/advanced/2009/03/20/reorder-commits-with-rebase.html)。ブランチの先端に並んだすべての 'c'コミットを取得し、commブランチにリベースします。その後、追加の「編集」+「コミット」を使用して「細かい」コードを取り除きます。 – GoZoner

関連する問題