Subversion時代
かつてSubversionを使っていたときは、ほとんどブランチを使ったことがありませんでした。慣例にしたがってtrunk、branches、tagsを用意しましたが、使っていたのはtrunkだけです。
branchesフォルダとtagsフォルダの構造が同じこともあって、ブランチとタグの何が違うのかを理解していませんでした。
ブランチを試したことはありますが、筆者の操作が悪いのか、conflict解決できないことがありました。マージできないので、ブランチを作らなくなりました。
「変更履歴」と「以前の状態と比較できる」だけで満足していました。
「変更履歴」と「以前の状態と比較できる」だけでも使う価値はあったよね。
git時代
gitを使うようになってからブランチ／マージを試してみたら、あっけないほど簡単でした。日常的にmasterブランチと開発ブランチを使うようになりました。
するとブランチの名前の付け方を考えるようになりました。最初はmasterとwork。次の段階では、チケット番号を末尾につけて、work_1234 や ticket_1234と名前をつけていました。
標準的なブランチ名の付け方や運用方法があるなら、知りたいと思っていました。
git-flowモデル
素晴らしい記事を発見しました。ブランチが5種類あります。各ブランチの目的と運用方法が明確で迷うことはないと思います。
O-Showさんの日本語訳
A successful Git branching model を翻訳しました
Vincent Driessenさんの原文
A successful Git branching model
中央リポジトリ（例 github）
master
現在の製品バージョン。
develop
次回リリースの開発用。
開発者リポジトリ
feature-*
新規機能の開発用。developから分岐し、developへマージします。*(アスタリスク)はチケット番号です。例：feature-123。
release-*
次回リリースの準備用。developから分岐し、developとmasterへマージします。*(アスタリスク)はバージョン番号です。例：release-1.2。
hotfix-*
現在の製品バージョンのバグフィックス用。masterから分岐し、developとmasterへマージします。*(アスタリスク)はバージョン番号です。バージョン1.2からブランチを切る場合、バージョン番号をインクリメントします。例：hotfix-1.2.1。
※このブランチモデルをベースにしたgit-flow というプラグインがあります。
新しい記事で、git-flow、GitHub Flow、GitLab Flowのブランチ名をまとめました。
