【git】"git-flow"を齧る
はじめに
本日はタイトルの通り、"git-flow"についてご紹介します。
gitでは簡単にブランチを切れて便利ですが、何も考えずにとりあえずブランチを切って作業してしまうと後の管理が困難になってしまいます。
そこで、"新規機能開発"、"リリース"といったソフトウェアの開発作業における"作業工程(目的)毎"にブランチを切って、それぞれのブランチで作業を遂行する
というブランチ戦略の考えが登場しました。
この"Git-flow"は、gitのブランチを管理するプライグインでして、ブランチ戦略、リリース管理をサポートするものとなっています。
筆者も「Myトレ」などでGitを使用していてこの"Git-flow"の考えはなんとなく取り入れていたのですが、なんとなくで留まってしまっていたため改めて理解を深めたいと思います。
本記事では、"git-flow"におけるブランチ戦略の考えと、実際の作業工程で具体的にどのような作業をするのか?をまとめます。
参考
「Vincent Driessen氏」が"A successful Git branching model"という記事にて紹介しています。
原文:A successful Git branching model » nvie.com
翻訳:見えないチカラ: A successful Git branching model を翻訳しました
"Git-flow"で用いるブランチの説明
ブランチの種類
- メインブランチ
メインブランチは、"開発"と"リリース"における最新の状態を管理します。サポートブランチと違い、永久的に管理します。
ブランチ名称 | 分岐元、マージ先 | 役割 |
master | 分岐元: - マージ先: - |
製品として出荷可能な状態を常に反映する |
develop | 分岐元: master マージ先: master |
「次のリリース」のための「最新の開発作業」の変更を反映する |
★masterのソースはdevelopブランチなどからマージすることで成長させます。直接masterブランチにてソースコードを修正してはいけないです。
- サポートブランチ
サポートブランチは、作業のため一時的に作られるブランチです。作業としての役目を終えたらブランチ自体を削除します。
feature | 分岐元: develop マージ先: develop |
developブランチから派生して、将来的にリリースの視野に入るような機能を開発する。 開発した結果、必要となったらdevelopにマージ、そうでなければ破棄をする |
release | 分岐元: develop マージ先: master, develop |
開発ブランチでリリースの準備ができたあとで、リリース完了するまでにソースの調整を行う |
hotfix | 分岐元: master マージ先: master, develop |
「develop作業中でリリース見込みがまだ立てられない、かつ緊急で修正すべき内容がある」といったケースで、本ブランチを生成して修正の作業を行う |
実際の作業プロセス
前提
- githubの使用を想定しているため、github特有の操作を含んでいます。
- 今回は、「開発工程」、「リリース工程」、この二つのプロセスについて説明します。
- 具体的に説明するために、審査に提出する工程も含んでいます。
★俺流なところもあるかもですがご了承ください!
開発工程
①開発環境の作成 - 開発用ブランチの作成
ブランチ:master → develop or develop → feature
コマンド:
git branch -a // 現在のブランチ、及びリモートブランチ含めた全ブランチを確認する git checkout -b develop // developブランチの作成(master → develop) git checkout -b feature_hogehoge // featureブランチの作成(develop → feature)
②作業内容の決定 - "issue"の作成
githubにてissueを作成する
④開発作業 - "issue"に対して改修の実施
実施作業:commit, push
コマンド:
git commit -m "#{issueの番号}" // issueに対して、コミットを紐付ける git push origin feature_hogehoge // feature_hogehogeブランチをgithubにプッシュ
⑤レビュー依頼 - pull requestの発行
⑥レビュー作業 - マージ or pull requeseの取り消し
リリース工程
①リリース準備 - リリースブランチの作成
コマンド:
git branch -a // 現在のブランチ、及びリモートブランチ含めた全ブランチを確認する git checkout -b release_v1.0.1 // releaseブランチの作成(develop → release)
②審査提出用ファイルの生成 - アーカイブファイルの生成
③(審査で不備がある場合、)修正作業
修正後コミットを切る
★審査が通るまで、②、③を繰り返す
⑤(審査が通った後、)リリースブランチのマージ
githubのマージ機能、gitコマンドの"merge", "rebase"など使用する
→自分のケースだとどれが良いかは、別途整理します。
④(審査が通った後、)ブランチのプッシュ
プッシュ対象ブランチ:master, develop
⑥リリースタグの作成
githubで"Draft a new release"を使用し、リリース時点のタグを作成する
おわりに
記事を書いている最中に"Github-flow"という別のgitのブランチ戦略があることを知りました。
一旦は、今回の"git-flow"をベースに開発を進めて、「なんとなくブランチを切る」という開発にさよならしていきたいと思います。