GitHubリポジトリのベストプラクティス、フォークまたは新しいブランチの作成
GitHubでフォークとブランチのベストプラクティスを探しています。私はこれを読みました GitHubでのフォークとブランチ ですが、関係ありません。
私たちの5人のチームは同じリポジトリで作業しており、コード内の問題、競合、またはリグレッションのマージを回避したいと考えています。目標は、5人がプロジェクトのさまざまな部分で、多くの場合同じファイルで作業することです。
私はそれが価値があるかどうか知りたいです：
- プロジェクトをフォークし、作業してプルリクエストを作成し、各自がコードを簡単に確認できるようにします。
- 新しいブランチを作成します-作業が完了したら、作業してマスターでマージします。
私にとって、複数の開発者がいるプロジェクトを扱う場合のベストプラクティスは、gitflow分岐モデルを使用することです。
まず、masterブランチは、 Semantic Versionning に従って、アプリのリリース、メジャー、マイナー、またはパッチバージョンを追跡するためにのみ使用されるようになりました。
開発ブランチは、さまざまな機能とリリースの間の橋渡しをするため、プロジェクトの中核になります。
このシステムは、単純な分岐システムと同じように、マージの数を減らすのに役立ちますが、セマンティックロジックと、それに付属するフレンドリーで単純なコマンドを追加します。
Gitflowの詳細については、 このリンク をたどることができます。
フォークを維持すると、各フォークが上流から変更をプルする必要があるため、追加のオーバーヘッドが発生します。すべての開発者が共有リポジトリにアクセスできる場合、そうすることにメリットはありません。
プルリクエストはコードレビューに非常に便利なメカニズムですが、フォークを使用する必要はありません。同じリポジトリにブランチを作成し、プルリクエストを使用して、それらをマスターブランチにマージすることを管理できます。
私のオフィスでも同様の状況があります。5人以上の開発者がコミットアクセス権を持ち、通常は少なくとも3人がいつでもそれに取り組んでいる大規模なプロジェクトです。ブランチとプルリクエストを備えた単一のリポジトリを使用してすべてを管理しますが、問題は発生していません（とにかく、ソース管理のセットアップが原因でした）。
プルリクエストは、他の開発者からコードレビューを求めるための優れた方法です。これは、同じ開発者が翌日コードを操作する場合に特に重要です。一方、フォークは実際には何のメリットもありません。これは、制御されたコードベースへのより広いアクセスを許可するという問題の解決策であり、誰もがリポジトリへのアクセスをコミットしている場合、その問題は存在しません。
Atlassianのgitチュートリアルページには、フォークと他のgitワークフローの違いに関する優れた記事があります。 （ フォークワークフロー| Atlassian Gitチュートリアル を参照）
関連する引用：
フォークワークフローの主な利点は、誰もが単一の中央リポジトリにプッシュする必要なしに、コントリビューションを統合できることです。開発者は独自のサーバー側リポジトリにプッシュし、プロジェクトメンテナのみが公式リポジトリにプッシュできます。これにより、メンテナは、公式コードベースへの書き込みアクセスを許可せずに、開発者からのコミットを受け入れることができます。
.。
フォークワークフローの「公式」リポジトリの概念は単なる慣例であることを理解することが重要です。技術的な観点から、Gitは各開発者の公開リポジトリと公式リポジトリの間に違いはありません。実際、公式リポジトリを非常に公式にする唯一のことは、それがプロジェクトメンテナの公開リポジトリであるということです。
.。
これらの個人用公開リポジトリはすべて、他の開発者とブランチを共有するための便利な方法にすぎません。機能ブランチワークフローやGitflowワークフローと同様に、誰もがブランチを使用して個々の機能を分離する必要があります。唯一の違いは、これらのブランチが共有される方法です。 Forkingワークフローでは、それらは別の開発者のローカルリポジトリにプルされますが、Feature BranchおよびGitflowワークフローでは、それらは公式リポジトリにプッシュされます。
私は「一元化された」方法で作業します。つまり、誰もがフォークするメインリポジトリを持ち、すべての開発者が独自のリポジトリにコミットするため、コードレビュープロセスが簡単になります。コードレビューが完了したら、変更をメインリポジトリにマージできます。
これが主なアイデアです...
また、分岐方法に関する戦略を設定する必要があります。私はお勧めします Nvieモデル
ボトルネックは分岐や分岐ではないと感じています。どちらのアプローチでも、変更をマージ/レビューする手動の介入が必要です。、
したがって、ボトルネックはアプリケーション開発アプローチにあります。チームが同じファイルで共同作業しているときに問題が発生します。適切なアーキテクチャ設計で、個別のファイルを持つ個別のモジュールとして分割できますか？実行時またはビルド時に、個別のモジュール（またはファイル）を集約して、機能全体（または単一のファイル）を形成することができます。
そのレベルでそれを解決できれば、チームのサイズが大きくなるか、機能の複雑さが増すと、物事はスムーズにスケーリングされます。