Git ブランチの運用
ブランチとは?
ブランチとは、本番環境にリリースされているソースコードとは別のところで開発を続ける機能のことです。Gitでは、ブランチの作成と切り替えを一瞬で行うことができます。
リリースブランチ、作業ブランチなど、ブランチを適切に分けながら効率良くチーム開発を行うことができます。
もしもブランチ機能がなかったら?
=> 常に本番環境のソースコードを直接編集することになります。作業途中あるいは、バグを含んでいる可能性があるコードが本番稼働しているソースコードに直接反映されたらと考えると…
git-flow
ブランチの運用を考えるうえで一つの指針となるgit-flowについて紹介します。

本番で稼働しているアプリケーションのソースコードと等しい
開発中の状態。ステージング環境のソースコードと等しい。
作業ブランチ。開発者各自が作成し、基本的にこのブランチ上で開発を行う。
緊急で対応する必要のあるバグ修正など。
リリース準備のためのブランチ。developブランチには含めたくない情報。
ブランチ運用の基本的な考え方
ブランチ運用は、サービスの規模や開発人数などにより最適解が異なるため、一概に正解はありません。ですが、master、develop、featureの3つはほぼマストといえます。(個人で開発しているようなサービスだとdevelopすら要らない可能性もあります。)
masterとdevelopは基本的に同内容となっています。各開発者は、developからfeature(作業ブランチ)を切り、開発を進め、完了後、developに取り込みます。

ブランチは、「きる」という表現を使うよ。
feature => developへの取り込みは、プルリクエストという形でコードレビュー後に取り込まれるよ。
おすすめの運用方法
筆者の所属している組織では、master, develop, featureの三つのブランチで運用しています。稀にhotfixを使用したり、後に説明するGitのタグ機能を使用しています。
常時5人前後の組織ですと、master, develop, featureの三つでほぼ事足ります。開発時のコンフリクトの可能性やリリース時期(タスクの期間)などを考慮して、柔軟にブランチ運用のルールを追加するのが好ましいと言えます。
featureブランチの命名規則
ブランチの命名規則はプロジェクトにより異なるところです。筆者がこれまでやってきた中でストレスを感じなかったのは下記に従った命名です。
名前/日付/内容
ex.) HogeTaro/20180121/remove-foo
日付を入れるというところがミソで、どうしても内容だけでは次第に枯渇していきます。(不要なリモートブランチは削除しろよという話ですが…)

master, staging, featureで運用してみて、状況に応じて変えていくのがおすすめだよ!
ディスカッション
コメント一覧
まだ、コメントがありません