読者です 読者をやめる 読者になる 読者になる

不器用(TOT) エンジニアの気ままにプログラミング

~考え、作って、また考える~

GitとGithub

BaserCMS

『Git』と『Github』。

f:id:shevhome:20150725222131j:plainf:id:shevhome:20150725224652j:plain

この2つはよく聞いてはいたが、

何かよく分かっていない。

 

バージョン管理システムの一種である認識だが、

『そもそもバージョン管理システムって何?』

という人は、こちらのサイトを参考にするとよいかもしれない。

 

簡潔にいうと、

Git  ・・・・バージョン管理システム

Github・・・Gitを使ったWebサービス

となるかと。

現場でSubversionを使っているが、

それにあたるものがGitであるという認識。

SVNWebサービス化したものが、Githubかなと。

 

バージョン管理がすぐれていると言われている点に

関して考えると、業務向けパッケージの開発などで、

ウォーターフォールと呼ばれる、

設計⇒開発⇒テスト⇒納品

を後戻りなく、順に実施の流れであれば、

現在のSubversionでも良いかと。

一方で、Webの開発現場などでアジャイル開発

開発⇒納品(ver1)⇒改修⇒納品(ver2)⇒・・・

の場合には、バージョン管理に特化しているは

非常に助かるのではないだろうか。

 

Githubに関してはBaserCMSをきっかけに、

使い始めてみようと思うので、

実際に使ってみることで、どう違うかを肌で感じたい。

 

また、バージョン管理に関して

色々と意見はあると思うが、

個人的な現場レベルでの不満と感じているのが、

・コミット時のコメント

・ソース修正の過去分を残す運用

の2点である。

 

まず、1点目「コミット時のコメント」

「何を修正した」は記載があるが、

「何のために」を記載していないことがある。

仕様変更なのか、不具合なのか、他の人が見るとわからない。

自分自身では日時などはコミットログでわかるため、

「何のために」を簡潔に記載するようにしている。

 

そして2点目「ソース修正の過去分を残す運用」。

これに関しては、ソース内に

/*2015/01/01 add start*/

 ~

/*2015/01/01 add end*/

などの記載で、追記していく運用方法のことである。

この方法は1、2回の改修であれば問題ないのだが、

長期プロジェクトなどや過去資産から改修をかけるなど、

改修がたび重なってしまうと、非常にソースの可読性が

落ちるのでやめてほしい。

この点は、色々と提案したりするが、

『今までこうだったから~』

と話を聞いてもらえないことが多い。ん~ジレンマ。

 

やはり、各現場の雰囲気というか、企業風土というか、

チャレンジングな現場だったり、保守的だったり、

そういうところで変わってくるのかな。