次のように、開発者ごとに git ブランチを使用してゲート付きコミット ワークフローを設定することを検討しています。
- 各開発者には、独自のリモート ブランチがあります。
- 開発者はリモート ブランチにのみプッシュします。
- CI サーバーは各ブランチを個別に構築し、テストに合格するとマスターにマージします。
- 開発者は、ブランチをプルしてマスターにリベースすることで変更を受け取ります。
これは合理的な解決策ですか?私は Subversion から来ており、git の経験はあまりありません。
次のように、開発者ごとに git ブランチを使用してゲート付きコミット ワークフローを設定することを検討しています。
これは合理的な解決策ですか?私は Subversion から来ており、git の経験はあまりありません。
アプローチは一般的に合理的だと思います。ブランチを「リモート」とは考えないようにします。これは、Subversion からの変更の一部です。すべての開発者は、実際のリモート リポジトリとの同期に使用されるローカルおよびリモート (ステージング) 領域 (「オリジン」) の両方を持っています。開発者は、マスター ブランチを使用して頻繁にコミット、プル、プッシュ、リベース (最新の状態に保つ) を行う必要があります。
ワークフローの詳細については、git branch、fork、fetch、merge、rebase、clone、what are the difference? を参照してください。
私のワークフローは次のとおりです。
私の個人的な経験では、過去に私のチームに最適なワークフローは、すべての開発者が 1 つのリモート ブランチを共有することでした。私のチームでは、たまたまこのブランチを「マスター」と呼んでいます。私たちの分岐戦略は、記事a-successful-git-branching-modelからアイデアを借りています。記事の「開発/マスター」ブランチを「マスター/リリース」と交換するだけで、基本的にセットアップが完了します。表記が違うだけで同じです。
私は基本的に、すべての開発者が master にコミットできるようにしますが、マージのみをコミットするという規則を追加しました。すべての直接コーディングは、トピック ブランチで行われます。変更セットが 1 つだけのクイック修正の場合は、マスターに直接コミットすることができます。しかし、一般的には、ローカル トピック ブランチの使用が強く推奨されます。
また、マスターへのすべてのコミットはすぐにプッシュする必要があります。そうしないと、差分が蓄積されてマージが難しくなります。このように、マージを解決する負担は、チーム リーダーや一部の自動化されたソフトウェアではなく、開発者の責任です。通常、自分の変更を最もよく知っているのはコードを開発する人なので、これは理想的な状況です。
複数の開発者が 1 つのトピック ブランチで作業する必要がある場合は、すべての開発者が自分のブランチを特定のパス (私の場合は "shared/") でリモートにプッシュできるようにして、他の開発者がそこからプルおよびプッシュできるようにします。
テスト サーバー (CI サーバー) については、テストの実行ごとに master とブランチを更新します。新しいブランチでテストすることは必ずしも必要ではありませんが、自動化されたスクリプトの一部が master で直接動作しないことを知っていると、より安心できます。
あなたが svn から来ている場合、共有ブランチで常に小さな変更が行われるのは少し怖いかもしれません。恐れる必要はありません。通常、git は競合の解決に非常に優れており、90% の確率で競合を引き起こすことさえありませんgit merge
。git pull
最後に、頻繁にコミットし、頻繁にプルする習慣を開発者に植え付けてください。小さな増分変更は、実際には git マージ コードの改善に役立ちます。
Gerritを使用する- 基本的には、コード レビュー機能が組み込まれたゲート コミット ソリューションです。