5

プロジェクトを独自のコードベースにフォークしますが、フォーク元のプロジェクトに厳密に従います。

私はそれが次のように機能するのを見ます:

フォークされたプロジェクトは、製品を再ブランド化するためのいくつかの初期変更を開発します。これらの変更を元のプロジェクトと共有したくありませんが、今後は変更をマージしたいと考えています。

セットアップ方法は、現在同じ履歴を持ち、お互いにリモートを追加するだけの個別のリポジトリです。

私が考えていたワークフローは次のとおりです。

機能ブランチで作業するようにし、機能ごとに 1 つのコミットしか持たないようにして、それぞれ git cherry-pick できるようにする必要があります。機能に取り組んでコミットするときはいつでも、機能のブランチで git commit --amend を実行してください。ファイナライズされたら、コミットをチェリーピックできます。

チェリーピッキングの後に機能が変更された場合、開発者は終了するのではなく、新しいコミットを作成することを覚えておく必要があるため、私はこれが好きではありません。

マージまたはリベースでこれを行う方法が大好きです。

4

6 に答える 6

3

One possible way to structure this is with three repositories where one repository is the 'white label version' and the other two repositories are for the two front ends. The two front ends would reference the 'white label version' repository as a submodule.

With this structure you:

  1. have clearly called out the white label version as a shared resource that is 'controlled' but others
  2. yet, still allow for changes to the white label version by the two front ends
  3. allow the two front ends to develop independently with their repository contents.

If your two front ends are going to be similar, then they can be branches of one repository (but both dependent on the submodule). In this case, if you are merging back and forth between the two front ends, a good approach is to create a branch for each and every feature. Having a branch per feature frees you from the restriction of 'one commit per branch'. [edit] Depending on the nature of the feature branch you could a) cherry-pick all the commits using <branch-base>..<branch-head>; or b) rebase everything on the branch into one commit and then cherry-pick that one commit or c) use merge/rebase to get the feature branch onto another branch (See the numerous examples from the git rebase documentation, particularly the --onto option.) [/edit]

Also here is a common, well-respected branching model with a discussion on feature branches.

[edit2] You can do this with one repository if you prefer. Keep three primary branches: white-label-dev, prod1-dev, prod2-dev and have the developers on each of the three teams operate only on their branches or their created branches off of their branches. When one team has something that should be shared, the 'corporate integration lead' will do the work of moving commits from that one team's work to the other team's branches. (Moving the commits as I described above.)

Your teams will need some discipline to avoid mucking with another team's branches. But, if you've got a shared repository you can assign hooks to prevent pushes from the wrong team onto another team's branches. [/edit2]

于 2013-04-08T04:35:04.213 に答える
1

フォークされたプロジェクトを最新の状態に保つために Github が使用するのと同様の手順に従いたいと思います。

whitelabelまず、レポから始めます。これは、他のプロジェクトがフォークするものです。次に、他のプロジェクトは、リポジトリとして設定されているwhitelabelのクローンになります。これを使用すると、またはワークフローに応じて実行できるようになります。whitelabelupstreamgit merge upstream/mastergit rebase upstream/master

利点は、メイン プロジェクトのステータスを維持する必要がないことです。他のプロジェクトは独自のフォークになり、簡単に更新できます。変更しようとすると、cherry-pick特に多くのコミットで簡単に面倒になる可能性があります。他のプロジェクトの 1 つが元のリポジトリからのコードに変更を加えたい場合、これを行うと、その変更をより簡単に管理できます。

http://www.techblogistech.com/2012/07/setting-a-default-upstream-branch-in-git/

ここで変更のプルに関するセクションを参照してください: https://help.github.com/articles/fork-a-repo

于 2013-04-11T18:45:24.287 に答える
0

フォークが forkee の足跡をたどることになっている場合は、マスター リポジトリのブランチにフォークを保持することをお勧めします。そうしないと、アップストリームのチェリーピッキングの変更などが不必要に難しくなります。

フォーク リポジトリの利点とコストを考慮してください。すべてをまとめることは、違いを引きずることを意味します (おそらく小さい?)。

gitoliteを使用すると、必要に応じてブランチへのアクセスを制御できます。

于 2013-04-06T00:47:41.067 に答える
0

ブランド化されたコードがすべてviews/ディレクトリ内に「きれいに」存在できると仮定すると、ビューを独自の git リポジトリに分割し、それをメイン プロジェクト内にネストすることをお勧めします。こちらをご覧ください

その後、次のいずれかのオプションがあります

  1. フォーク用の単一のビューリポジトリで git ブランチを使用する、または
  2. ブランドごとに個別のビューリポジトリを使用します。

ビューの一部は、ホワイト ラベルに折り返すか、ホワイト ラベルからブランドにチェリー ピッキングして共有する必要があると予想されるため、1. を優先します。

考えられるプロジェクト作業レイアウト

ホワイト レーベル プロジェクトのレイアウト。

- app_whitelabel/  <<-- clone of "app" repo on default branch
  + config/
  + controllers/
  + errors/
  + views/         <<-- nested clone of "views" repo on branch "brand1"

ブランド 1 プロジェクトのレイアウト。

- app_brand1/     <<-- clone of "app" repo on default branch
  + config/
  + controllers/
  + errors/
  + views/         <<-- nested clone of "views" repo on branch "brand1"

ブランド [n] プロジェクトのレイアウト。

- app_brand2/      <<-- clone of "app" repo on default branch
  + config/
  + controllers/
  + errors/
  + views/         <<-- nested clone of "views" repo on branch "brand[n]"

長所

  • 共有コード ベースを最新の状態に保つためにチェリー ピックを行う必要はありません。プルするだけです。
  • 「アプリ」のプルは「ビュー」には影響しません。
  • クリーンなmvcモデルを維持するように強制します-悪いことではありません:)

短所

  • あなた / 他の人は、より複雑なプロジェクト レイアウトに注意する必要があります。
  • クリーンなmvcモデルを維持するように強制します-常に簡単なことではありません:)
于 2013-04-10T02:07:49.850 に答える
0

両方のリポジトリを制御できると仮定すると、解決策は簡単です。

各機能のブランチを維持します。

機能リリース ブランチを維持します。

機能が完成したら、機能ブランチをリリース ブランチにマージしてタグ付けします。

機能にバグ修正が必要な場合は、機能ブランチで修正してから、新しいバージョンで再マージしてタグを付け直します。

機能リリース ブランチは、更新された機能やバグ修正をまとめてチェリー ピックできる場所です。タグによって、使用している機能のバージョンを簡単に識別できます。

また、機能リリース ブランチのコミット履歴を簡単に見て、更新があったかどうかを確認することもできます。

これらのブランチとは別に、私はバージョン リリース ブランチを維持しています。公にリリースされたものはすべて QAd であり、バージョン リリース ブランチにコミットされます。

全員のローカル作業リポジトリは、制限なしで必要な数のコミットを持つことができます。

マスター リポジトリには、フィーチャー リリースとバージョン リリースに継続的にマージされる、明確にセグメント化されたコミットで明確に区別されたブランチがあります。

フォークは、機能リリース ブランチまたはバージョン リリース ブランチのいずれかに従って簡単に更新できます。フォークされたリポジトリは、必要なときにいつでも適切なものを取得できます。

雑な絵を描いた

黄色のブランチはタグ付き機能リリース ブランチで、緑色はバージョン リリース ブランチです。フォークはこれらのブランチのいずれかから自由に引っ張ることができ、チェリーピックで何が得られるかを正確に知ることができます。作業機能ブランチは、相互に依存していない限り、すべてリリース ブランチに基づいています。バグ修正は、リリースとは別に処理されます。

そして、私が言ったように...すべての開発者は独自の作業リポジトリを持ち、それらに自由にコミットできます。

于 2013-04-13T09:58:53.870 に答える