第4回はブランチモデルについてです。
ブランチモデルというのはブランチをどうやって切るのかを予め決めておくルールのことです。
なぜそんなルールをわざわざ用意しなければならないのかというと複数人で作業している場合、何も決めずにブランチを切っていると「このブランチは何？なんのためにここで切ってるの？マージはされているの？」ってことになったりするからです。
という訳でルールを決めていこうと思います。
ブランチモデルには有名なものでgit-flowとGitHub Flowというのがあります。
KNAPではgit-flowを採用しようと思いますので今回はgit-flowについて説明します。
git-flowで作成する6つのブランチ
git-flowでは6つのブランチを使って作業を進めます。
それぞれ役割があるので一つずつ説明していきます。
masterブランチ
masterブランチは基本的に公開されたデータをマージするためのブランチとして使います。
つまり、すでに公開されているもので公開データが欲しい時はmasterブランチからデータをもらえば言い訳です。逆に開発中のデータはmasterブランチにあげてはいけないのがgit-flowのルールです。Gitを使い始めの方はmasterブランチにあげていた方も多いとは思いますがgit-flowを採用するのであればこれからはmasterブランチにあげないようにしましょう。
developブランチ
developブランチは開発を進めるためのブランチです。ただし、複数人で作業していく場合全員がdevelopブランチのデータを直接作業してコミットし始めたら大変なことになります。なのでdevelopブランチは作業を行なったファイルを一つにまとめるためのブランチとして使います。
featureブランチ
featureブランチはdevelopブランチと同様に開発を進めるためのブランチですがこちらは実際に作業を行うためのブランチです。featureブランチは複数個できることが考えられるブランチなのでブランチ名を記入する時は「feature/〇〇」といった形でブランチを作りましょう。〇〇には開発を行う箇所について単語にすると良いでしょう。例えば、コンタクトページを作成する場合は「feature/contact」といった感じです。
releaseブランチ
releaseブランチはその名の通りリリース、つまり公開するときに使うブランチです。
例えば、公開前に画像を圧縮したり、cssやjsのコメントを削除したりなどを行うときに使うと良いでしょう。
hotfixブランチ
公開が完了した後に「ここのテキストが間違ってました。直してください。」ってことたまにあると思うんです。そういう時はhotfixブランチの出番です。
そういった公開後の修正やcssの崩れ、jsのバグ修正などの際に使うのがこのブランチです。
supportブランチ
supportブランチは旧バージョンをサポートするためのブランチです。せっかくのgit-flowの最後のブランチですがあまり使う機会はないと思うのでこのブランチの説明はこれで終わりです。
最後に
Git講座は今回で一旦お開きです。
本当はスタッシュとかの機能についても説明したほうがいいんでしょうがひとまずこれでSourcetreeを使って充分にgitを使えるだろうと思うの頑張ってみてください。
