6

クライアント固有の機能を管理し、 Git-flowまたはGit一般のリクエストを変更することをどのように推奨しますか？クライアント固有の機能は、クライアント専用の別のブランチに含める必要がありますか？（各クライアントは開発ブランチから独自のブランチを持っています。）または、それらは別々のリポジトリにあるべきですか？（各クライアントには専用のリポジトリがあり、マスターリポジトリがメインリポジトリです。）

4

2 に答える 2

7

すべてのクライアントが使用するコードベースがあり、クライアント固有の機能のための「ハック」があるようです。

私の意見では、マスターブランチにすべての「ベース」コードがあります。すべてのクライアントには、クライアント固有のブランチがあります。注意して、変更が行われている場所を確認してください。

時々、クライアントブランチをリベースし、基本的にそれらをベースコードに戻し、その上で特定の変更をすべて再生するようにしてください。

リベースは、実際に動作するのを見るまではかなり混乱する可能性があります。

明確にするために順次コミット番号を使用します。コミットは実際には数値ではありません

マスターはコミット10にあります
 \
   ブランチにはコミット10、11、12、13、14、15があります（コミット10もあることに注意してください）
|
マスターは16、17をコミットします


リベースするとき：
  マスターは10、16、17を持っています。
  ブランチには10、16、17、11、12、13、14、15があります

ここでの順序は非常に重要です。リベースはブランチを10に巻き戻し、16と17を適用してから、11、12、13、14、および15の変更を再生します。

この時点で、競合がない限り、ブランチはマスターと最新であり、クライアント固有の変更があります。

于 2012-06-05T20:50:43.990 に答える
2

ベースとクライアント用に別のリポジトリを作成します。クライアントには、リモートブランチを持つベースがあり、それがベースになります。クライアントが新しいリリースを必要とするとき、それはこの方法ではるかに簡単です。すべてのクライアントを1つのリポジトリに配置する場合は、gitフローのリリースを開始する前に、統合/開発者ブランチを手動で変更する必要があります。これにより、異なるクライアントの複数のリリースで作業する能力が制限されます。

于 2012-06-11T19:51:42.010 に答える