Gitワークフローとは？
ソフトウェア開発チームの強化は、単一のブランチ戦略を特定することから始まります。
単一のGitワークフローの特定は、迅速なデリバリーを実現するためには不可欠なステップです。ソフトウェア開発チームには、さまざまな経歴や経験があるコントリビューターが含まれています。そのため、以前に使用していたワークフローに慣れていると考えられます。単一のワークフローを確立しておかなければ、チームにおいて複数の開発ワークフローが乱立し、サイクルタイムが長くなってしまう可能性があります。
Gitワークフローを明確に定義しておけば、チームが強化され、効果的なコラボレーションの土台となり、ソフトウェア開発プロセスが合理化され、さらに継続的なデリバリーが促進されます。単一のGitワークフローを決定することで、よりスムーズに競合解決を行い、より一貫したコードベースを構築するための道が開かれます。
Gitワークフローによって、チームは、役割と責任を明確化し、境界を設定し、改善すべき分野を特定できるようになります。
集中型Gitワークフローでは、チームメンバー全員が、mainブランチ（masterブランチやデフォルトブランチと呼ばれることもある）に直接変更を加えられるようになります。この場合、すべての変更が実行履歴に記録されます。集中型ワークフローの場合、すべてのコントリビューターが、他のブランチを一切使用せずにmainブランチにコミットすることになります。このやり方は小規模なチームに適しています。チームメンバーがコミュニケーションをとることで、複数の開発者が同じコードに同時にコントリビュートすることがなくなるからです。チームメンバー間でしっかりとコミュニケーションを取れば、集中型ワークフローはシームレスに進みますが、これには限界もあります。複数の開発者が同じブランチにコミットする場合、変更のリリースに適した安定したタイミングを見つけることは難しいものです。従って、リリースの準備ができるまで、開発者は不安定な変更をローカルにとどめておく必要があります。
集中型Gitワークフローのメリットとは？
デベロッパーはstashを適用してマージの競合を解決すれば、同時に変更をプッシュする人がいない限り、自動マージコミットに対処することなく通常通りにコミットできます。この戦略はシンプルであるため、小規模なチーム、Git初心者、更新があまり行われないプロジェクトに適しています。
このワークフローにデベロッパーがコミットする場合、機能ごとに独自のブランチを作成します。デベロッパーはmainブランチに直接コミットせずに、ブランチを作成し、変更を加え、マージリクエスト（またはプルリクエスト）を送信してから、mainにマージします。
理想的には、フィーチャーブランチの存続時間は数時間であるべきです。ブランチの存続時間が長くなるほど、mainへのマージ時に統合の競合が生じるリスクが高くなります。この規模になると、やはり多くのチームが他のブランチで作業を行い、変更内容を直接mainブランチに反映しているため、無秩序化に加え、ローカルでの変更との競合が発生する可能性が高まります。
フィーチャーブランチのGitワークフローのメリットとは？
このGitワークフローの場合、mainブランチに未完成の機能が反映されないため、無駄なものがない状態に保てます。フィーチャーブランチでは、複数の開発者が並行して同じ機能に取り組めるため、あらゆる規模のチームで使用できます。フィーチャーブランチのメリットが最大限に発揮されるのはまだ開発中のソフトウェアで利用した場合ですが、より成熟したアプリケーションでもこのワークフローを利用できます。
トランクベース開発では、トランクと呼ばれる単一のブランチでの並行開発を容易に進められます。デベロッパーは中央リポジトリに変更をプッシュする準備ができたら、中央リポジトリからプルしてリベースし、中央ブランチの実行コピーを更新します。トランクベースの開発を成功させるには、開発者がローカルでマージの競合を解決することが不可欠です。ローカルブランチを敵的に更新すると、変更の統合による影響を抑えられます。影響が少ない段階で見つけられるため、マージの問題を回避できます。
トランクベース開発のGitワークフローのメリットとは？
トランクベース開発では、毎日多くの小さなマージが頻繁に行われるため、マージの競合が起きる可能性が減り、コードをクリーンに保てます。継続的インテグレーションと併せてトランクベースのワークフローを利用することで、フィードバックの迅速化に加え、コードの所有権と開発に対するチーム志向のアプローチを実現できます。
パーソナルブランチはフィーチャーブランチに似ているものの、フィーチャーごとにブランチを1つ作成する代わりに、開発者ごとにブランチを作成します。このアプローチは、チームメンバーが異なる機能やバグに取り組んでいる場合に適しています。各ユーザーは、作業が終了するたびにmainブランチにマージできます。
パーソナルブランチのGitワークフローのメリットとは？
パーソナルブランチにはフィーチャーブランチと同様のメリットがあります。さらに、ブランチの数を抑えられることから、ブランチの管理が楽になるというメリットもあります。パーソナルブランチは、バグ修正やその他の小規模な変更に利用できます。また、実験に興味がある開発者が新たな開発を行う際にも役立ちます。パーソナルブランチは、単一のリリースサイクル内では終わらない可能性のある長期的な機能の開発時に効果的です。この戦略は、チームメンバーがアプリケーション内の特定の部分をそれぞれ開発している、小規模なチームでの利用に適しています。
フォークによるバージョン管理のアプローチでは、リポジトリの完全なコピーを作成するところから始まります。フォークによりGitリポジトリのローカルコピーを効果的に作成でき、さらに共同作業のための新たな構造を作成できるようになります。要するに、チーム内の開発者は全員、ローカルワークスペースとリモートリポジトリの2つのリポジトリを持つことになります。
このワークフローは、複数の開発者がコントリビュートするプロジェクト、中でも特にオープンソースプロジェクトでよく利用されています。結局のところ、何千人ものコントリビューターが共同作業を行えるよう、リポジトリへの権限を付与し追跡し続けるのは大変なことです。メンテナーがコントリビューターに対し、フォークされたコピーに変更を加えることを許可できれば、変更の提案の管理をより安全かつ楽に行えるようになります。
Gitのフォーク型ワークフローのメリットとは？
フォーク型ワークフローを使用すると、コントリビューターはサーバー側のリポジトリに変更をプッシュできるため、低品質のコードやバグがソースコードに含まれる可能性が軽減されます。ソースコードへの変更を統合できるのは、プロジェクトのメンテナーだけです。ソフトウェア開発プロジェクトで大規模なチームが共同作業を行う場合、フォークを利用することで安全かつ品質重視の開発が可能になります。
GitFlowでは、mainブランチは常に本番環境にリリース可能であるべきで、テストしていないコードや未完成のコードがmainブランチにあってはなりません。このGitワークフローを利用する場合、mainブランチにコミットせずに、フィーチャーブランチと一緒に開発ブランチを使用します。本番環境に開発ブランチを移行する準備ができたら、コントリビューターはリリースブランチを作成します。リリースブランチでは、開発ブランチにマージする前に、テストとバグ修正が行われます。リリースブランチには、mainブランチにマージする際に競合を解決する専用の場所があるため、コードレビューのプロセスが簡単になります。この戦略では、mainブランチは常に本番環境を反映します。
GitFlow Gitワークフローのメリット
GitFlowのGit本番環境ワークフローとしての利点は、大規模なチームが複雑なソフトウェアに取り組みながらも、本番環境でバグを素早く修正できることにあります。さらにリリースブランチではユーザーがリリース前にステージング環境でソフトウェアをテストでき、これによってコードの開発が妨げられることはありません。GitFlowはどのような規模のチームでも使うことができますが、複雑なため、小規模なチームの場合は他の戦略のほうが使いやすいと感じるかもしれません。複数の環境や通常のデプロイの場合、GitFlowは一部のチームが必要とするワークフローの柔軟性を提供できる可能性があります。
Gitを一緒に始めましょう！
GitLabでワークフローを柔軟にする方法を見る
