コミットの粒度
コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。
【元ネタ】
git commit するまえに考えるべき10のこと | Act as Professional - hiroki.jp by HIROCASTER
「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組
GitやMercurialがCVSやSVNよりも優れている点は、ブランチ管理の容易さと豊富なマージコマンド。
特に、ローカルにブランチを作り、プライベートなブランチとして開発者は好き放題にコミットすればいい。
そして、masterに最終的にコミットする時、必要なパッチのみまとめて送ればいい。
コミット履歴を改変する必要があるのは、masterのコミット履歴を綺麗にする場合だろう。
ローカルのブランチは自分だけが好きなようにコミットしてもいいが、masterのコミット履歴は、その変更意図が分かるような歴史で残すようにしたい。
特に、ソース管理が一人だけの開発者ではなく、大規模システムで複数人の開発者の出入りが激しい場合、ソース管理のコミット履歴はとても重要な情報になる。
「No Ticket, No Commit」はあまりにも厳しいルールという批判を受ける時がある。
コミットする時に逐一チケット番号を書くのは面倒で、プログラミング速度が落ちる、と。
そもそも「No Ticket, No Commit」のルールは、障害管理における変更履歴を残す所から生まれた背景がある。
つまり、障害管理をきちんとしなければならないようなシステム開発であり、開発者がずっとシステムの面倒をみるプロジェクトではない。
ソースは一人だけの開発者の物ではなく、プロジェクトに関わる全員の物だ。
XPのソースの共同所有はそういう発想なのだろう。
だが、皆が関わるブランチ(master)は「No Ticket, No Commit」を守る方が運用保守ではとても効果的だが、ローカルのプライベートブランチまで必要かどうかは言ってはいない。
プライベートブランチは開発者一人だけの物であり、最後に必要なパッチを送る時に、チケット番号も一緒に送ればいいだけだ。
SVNのコミットログの書き方: プログラマの思索にも書いたけれども、特にプログラミング初心者はコミットログを意識して書くようにした方がいい。
そうすれば、コミットの粒度がとても明確になる。
コミットの粒度はよく迷うが、チケットの粒度の考え方と同じ。
コミットの粒度も小さい方がやりやすいが、意味ある大きさでコミットしなければ、逆にコミットが面倒になる。
以前、@yusuke_kokuboさんが、RedmineのメインコミッタであるJPLはコミットの粒度がよく考えられている、と言われていて、なるほどと思う時があった。
また、No Ticket, No Commitの効果: プログラマの思索にも書いたけれども、昔のソースほど、無駄なコメントがソースにガラクタのように残っている。
チケット駆動開発でソース管理しているならば、ソースから最終的には全てのコメントは消えて、ソースは必要最低限の機能を実装するものになると思う。
つまり、プログラムの途中で仕様を説明したいならば、コミットログにチケットNoを貼り付けておき、チケットを参照するようにすればいい。
ソースに更新履歴や仕様を説明したコメントは不要だ。
すると、SCMコミットログはファイルのメタ情報: プログラマの思索にも書いたが、コミット履歴は最終的にはソースのメタ情報になる。
つまり、チケットやリポジトリのコミットログは、変更履歴の全文検索の対象であり、ソフトウェア開発の資産(ナレッジ)そのもの。
ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索にも書いたが、ApacheやEclipseのリポジトリのコミットログから、意味ある経験知を見出そうと研究するソフトウェア・リポジトリ・マイニングというソフトウェア工学の手法もある。
こういう研究が可能になったのも、バージョン管理ツールが普及し、オープンソースのツールが商用ツールに匹敵するほど量も質も良くなってきたことがあげられるだろう。
面白い時代だと思う。
| 固定リンク
「プログラミング」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- Ruby技術者認定試験の感想(2020.05.08)
- 前処理大全の良いところ~SQLとRとPythonで対比できる(2019.07.10)
- WinSCPでトンネリングする方法のリンク(2018.09.09)
- 仕様書にもExcel脱却が求められている(2017.12.23)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「Git・構成管理」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
「チケット駆動開発」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント