0

私は最近 git ワークフローを調べていて、どれが私たちのチームに最適かを調べています。

私たちが使用できる最高の(または最高の 1 つの) git ワークフローは何でしょうか? このワークフローは、次の点の一部/ほとんど/すべてを尊重する必要があります。

  • 2 つのチーム (それぞれ約 8 人) が git を使用し、両方とも同じアプリケーションで作業します。各チームには、プライベート リポジトリがある場合とない場合があります。
  • アプリケーションにはいくつかのバージョンがあります。バージョン (n+1) の開発の開始は、バージョン (n) のリリース前に開始される場合があります。バージョン (n+1) の開発は、バージョン (n) に含めるべきではありません
  • クライアントは、前の月に開発された次のリリースに機能 x を含めないことを土壇場で決定する場合があります。
  • プロジェクトの歴史は理解しやすいものでなければなりません。

私のワークフローのアイデア: ここにあるものとは少し異なるワークフロー: http://nvie.com/posts/a-successful-git-branching-model/

  • SSH で利用できる、2 つのチーム用の 1 つの中央リポジトリ。
  • 支部長安定です。
  • ブランチ開発は作成されません。代わりに、アプリケーションの各バージョンには独自のブランチがあり、チームはそれらで開発します。バージョン (n+1) のブランチは、バージョン (n) のブランチから作成されます。したがって、ブランチ (n) でバグ修正が行われている間に、ブランチ (n+1) で新しい開発が発生する可能性があります。
  • モデルのように、新しい機能とバグ修正ごとにブランチが作成されます。
  • チームごとに 2 つのメイン リポジトリを使用するのは簡単ではないように思われるため、両方のチームに 1 つの中央リポジトリのみを使用します。チームごとに 2 つのリポジトリを使用するワークフローはどのようなものでしょうか? それだけの価値はありますか？
  • 早送りが発生した場合、機能 x が含まれないようにする方法がないように見えるため、ほとんどの (すべてではないにしても) マージは早送りしないでください。
  • リリース時に、バージョン (n) をマスターにマージし、タグを付ける

また、この戦略では支店が多すぎませんか? リリース後、簡単に約 30 ~ のバグ修正が行われる可能性があります。バグ修正ごとにブランチを作ると、あっという間にたくさんのブランチができてしまいます。それを避けるための解決策はありますか？

パッチワークフローは良いアイデアでしょうか? どうなり得るか？すべてのバグ修正と機能に独自のパッチがあり、クライアントが必要なものを選択できるようになると思います.

お手伝いありがとう。

4

1 に答える 1

0

分岐などの Git ワークフロー。実際には、人々がプライベートリポジトリとブランチを持つことを防ぐことはできません (そして、このようにそれらを制御しようとするのは本当にばかげた考えです: 分散型 VCS の最強のポイントを失うことになります)。あなたが制御できる (唯一の!) のは、あなたが直接アクセスできるリポジトリです: 他の人が自分の変更をリポジトリにプッシュするのを止めたり、アクセスを完全に閉じたりすることさえできます。厳密に制御された環境では、通常、直接のプッシュは許可されません。変更は、専任のチーム メンバーによって他のメンバーからプルされます。テストされ、その後、チーム全体で使用できるようになりました。

要求する単純なワークフローについては、Pro Git book で説明されている戦略が適切に見えます: http://git-scm.com/book/en/Git-Branching-Branching-Workflows

土壇場で、長い間行われた機能を参照git cherry-pickしてください。履歴の閲覧用 (実際には、このためのグラフィカル ツールが多数あります)。パブリック開発およびリリース ブランチは、おそらく独自のメンテナーがいるパブリック ブランチです。gitk

GitHubなどの大きな Git ホスティング サイトによって促進されるワークフローを確認することをお勧めします。これらには、同様のオープンソース実装 (Android プロジェクトによる Gerrit など) があります。

于 2012-07-26T12:37:28.617 に答える