【自分とこの環境下におけるGit & GitLabレクチャー】
研究室内でのプロジェクトの開発や共有を行いやすいように決めた独自ルールについて説明する．
ここでは多人数開発のためのタグおよびブランチの使い方ルールについての説明となる．
タグ・ブランチについてはA successful Git branching modelを参考にしている．
なおGitLabを前提にしたプロジェクトの在り方については独自ルール:多人数開発のためのグループプロジェクトについてを参考のこと．
ブランチのルール
意識せず使用する場合，ブランチはmainとなっている．しかしmainブランチは重要であり必ずいつでも動作するものとしたいのでmainブランチを直接みんなで操作するのを避けたい．そのため，以下のようにする．
- ブランチを三つの役割(メインブランチ:main，開発用ブランチ，修正用ブランチ)に分ける．
- 開発用ブランチ，修正用ブランチで実際の編集を行い，動作確認を行う．
- 動作が確認できた上で，mainブランチにmergeする．
グループプロジェクトはもちろん，慣れるためにも個人プロジェクトでも上記ルールを適用すること．
ブランチ詳細
- メインブランチ:main
- プロジェクトを作成する側だけでなく，プロジェクトの成果を単純に利用する人もアクセスするブランチ．よって必ず動作している状態にしておくことが重要．
- 開発用ブランチ:develop-(ブランチ作成者名)-(機能名称や通し番号)
- 新しい機能を追加したりロジックを変える時用のブランチ．
例1:develop-ken-add_sumfunc
例2:develop-ken-001 - 修正用ブランチブランチ:hotfix-(ブランチ作成者名)-(GitLabのissue番号や修正内容)
- バグ修正のためのブランチ．
GitLabのissue番号:一般的にバクなどをGitLabで報告すると"issue10"など番号が付与される．これを使用する．
例1:hotfix-ken-issue10
例2:hotfix-ken-pointer-error
各ブランチの役割を名確認し，細かくきちんと分ける．
- 大きな開発用ブランチを作成しない．
- 細かく開発内容を分け，細かくブランチを分ける．大きな開発用ブランチは完成せず，mainにmergeされず，利用されない．
- 大きな修正用ブランチを作成しない．
- 同上
- 開発用ブランチと修正用ブランチを混ぜない．
- 開発途中にバグを発見することはよくある．この時，その開発用ブランチにてバグ修正しない．mainから新しく修正用ブランチを作成し，そちらで修正が終わったらmainおよび開発用ブランチに反映させる．詳しくはGit book 3.2を参照のこと．
タグのルール
タグは基本的にメインブランチに付与する．他のブランチは作成者に任せる．
タグ名:バージョン番号
タグは3桁ピリオド区切りのバージョン番号とする．
- α.β.γ
- α
- メジャーバージョン
- 大きい仕様変更が生じたら+1．特に下位互換がなくなったら+1しコメントにも詳細を残すこと．
- メジャーバージョン
- β
- マイナーバージョン
- 機能追加など内容の拡張が起きたら+1．
- マイナーバージョン
- γ
- リビジョン
- バグ修正など本質的な変更のない修正が起きたら+1．
- リビジョン
- α
- 例
- 1.0.0
開発開始時は0.1.0あたりから開始し，外部公開できるレベル(他人に使ってもらえるレベル)になったら1.0.0くらいが目安．