GitとGithub
『Git』と『Github』。
この２つはよく聞いてはいたが、
何かよく分かっていない。
バージョン管理システムの一種である認識だが、
『そもそもバージョン管理システムって何？』
という人は、こちらのサイトを参考にするとよいかもしれない。
簡潔にいうと、
Git ・・・・バージョン管理システム
となるかと。
現場でSubversionを使っているが、
それにあたるものがGitであるという認識。
バージョン管理がすぐれていると言われている点に
関して考えると、業務向けパッケージの開発などで、
ウォーターフォールと呼ばれる、
設計⇒開発⇒テスト⇒納品
を後戻りなく、順に実施の流れであれば、
現在のSubversionでも良いかと。
一方で、Webの開発現場などでアジャイル開発
開発⇒納品(ver1)⇒改修⇒納品(ver2)⇒・・・
の場合には、バージョン管理に特化しているは
非常に助かるのではないだろうか。
Githubに関してはBaserCMSをきっかけに、
使い始めてみようと思うので、
実際に使ってみることで、どう違うかを肌で感じたい。
また、バージョン管理に関して
色々と意見はあると思うが、
個人的な現場レベルでの不満と感じているのが、
・コミット時のコメント
・ソース修正の過去分を残す運用
の２点である。
まず、１点目「コミット時のコメント」。
「何を修正した」は記載があるが、
「何のために」を記載していないことがある。
仕様変更なのか、不具合なのか、他の人が見るとわからない。
自分自身では日時などはコミットログでわかるため、
「何のために」を簡潔に記載するようにしている。
そして２点目「ソース修正の過去分を残す運用」。
これに関しては、ソース内に
/*2015/01/01 add start*/
～
/*2015/01/01 add end*/
などの記載で、追記していく運用方法のことである。
この方法は１、２回の改修であれば問題ないのだが、
長期プロジェクトなどや過去資産から改修をかけるなど、
改修がたび重なってしまうと、非常にソースの可読性が
落ちるのでやめてほしい。
この点は、色々と提案したりするが、
『今までこうだったから～』
と話を聞いてもらえないことが多い。ん～ジレンマ。
やはり、各現場の雰囲気というか、企業風土というか、
チャレンジングな現場だったり、保守的だったり、
そういうところで変わってくるのかな。
