8

私はプロジェクトに取り組んでおり、中央の git リポジトリを持っています。このプロジェクトは、いくつかのフォークのベースラインとなるスケルトンです。

プロジェクトの中央をオリジンとして追跡し、スケルトンのマスターを追跡する上流という名前の別のブランチとしてスケルトンのマスターを追跡して、スケルトンへの変更をチェリーピックするように、フォークのローカル作業リポジトリを構成することは可能ですか?

ワークフローを次のようにしたいと思います。

スケルトンの作成 >> フォーク スケルトン >> スケルトンはフォーク 2 から変更をプルします >> フォーク 1 はスケルトンから変更をプルします

私が説明したことを行うためのより良いプロセスはありますか?

4

2 に答える 2

9

GitHub の「Fork a Repo」ページの「 Step 3: Configure remotes 」を読んでください (GitHub について言及していないことは承知していますが、それでも関連性があります)。

  • originローカルクローンがプル/プッシュできるフォークのリモートアドレスです
  • upstream元のレポのリモートアドレスですSkeleton（ で追加できますgit remote add upstream https://..../Skeleton.git）

したがって、上流はブランチではありません。

ただし、 git branchを使用して、アップストリーム リポジトリからのリモート トラッキング ブランチ マスターをアップストリーム ブランチに持つローカル ブランチを定義できます。

git branch --set-upstream upstream_master upstream/master

ただし、特に新しいコミットを作成しない場合は、ローカル ブランチは必要ありません。から必要なものをチェリー ピッキングしupstream/masterた後、マスターを直接比較できます。git fetch upstreamupstream/master

于 2012-06-13T10:22:43.763 に答える
1

According to your description, you should rebase the forks on the skeleton whenever it changes, using

$ git rebase upstream

This will transform the situation as follows

initially:
1 - 2 - 3 <- upstream
        \- 4 <- fork

upstream changes:
1 - 2 - 3 - 5 - 6 <- upstream
        \- 4 <- fork

after rebase:
1 - 2 - 3 - 5 - 6 <- upstream
                \- 4 <- fork

In other words, your fork will look like as if it were forked from the most recent version of the skeletton.

The disadvantage of this approach is that it changes the history of the forks... If you don't want this, you can just merge upstream into fork (no need to cherry-pick I think).

于 2012-06-12T20:33:38.393 に答える