2

リモートのオープンソースプロジェクト（Githubなど）からローカルリポジトリのクローンを作成したとします。ローカルリポジトリにブランチを追加するなどの変更を加えます。

次の目標を念頭に置いてください。行った変更の一部は独自の目的であり、メインリポジトリには反映されません。バグ修正や機能の追加など、他の変更はコミュニティにとって重要です。メインリポジトリに貢献したい。

したがって、それに基づいて、2つの主要なブランチを想定しましょう。すべての変更に対するdev-projと、メインリポジトリに提供されるサブセットを持つdev-commです。

一般的なケースでは、特定の変更セットがdev-commに入るかどうかがわかるので、それらをブランチに分離できます。

ただし、変更をアップストリームに提供する必要があるかどうかによってブランチを決定したくない場合があります。

たとえば、Webアプリケーションのローカリゼーション（翻訳やビューの変更など）の場合を考えてみましょう。そのためのブランチを作成し、それを非公開にするつもりですが、作業中に元のコードにi18nの問題があることがわかったので、このブランチでの作業の一部としてそれらを修正します。そして、これらは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つにすぎません。

4

2 に答える 2

1

元の git ブランチ管理からいくつかのアイデアを得ることができます。詳細は「gitworkflows マニュアル ページ」でも説明されています。

個々のチェリー ピッキングに頼るのではなく、パブリック ブランチにマージするためにトピック ブランチの履歴を並べ替えたいと思います (これは後で問題になる可能性があります。「git で特定のコミットをマージする方法」を参照してください)。

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

自動並べ替えのトリックの 1 つはgit rebase --interactive --autosquash、コミットを並べ替えてグループ化することです (「GIT チェックインのトリミング/GIT 履歴の圧縮」を参照してください)。

于 2012-04-15T13:03:57.930 に答える
1

「git rebase --onto ...」を見てください。あなたの例では、それを 2 つのステップと考えてください。1) 'i18n' の変更を 'rebase' で独自のブランチに分離し、2) そのブランチを dev-proj にマージします。「git help rebase」から、例の 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-proj) にマージし、topicB (dev-comm) に戻すことができます。

于 2012-04-15T03:03:55.510 に答える