コミットの粒度
コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。
【元ネタ】
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のリポジトリのコミットログから、意味ある経験知を見出そうと研究するソフトウェア・リポジトリ・マイニングというソフトウェア工学の手法もある。
こういう研究が可能になったのも、バージョン管理ツールが普及し、オープンソースのツールが商用ツールに匹敵するほど量も質も良くなってきたことがあげられるだろう。
面白い時代だと思う。
| 固定リンク
「プログラミング」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのモジュールシステムは複雑性をより増している(2022.09.10)
- Javaはなぜ関数型言語になろうとしているのか(2022.09.02)
- Javaのラムダ式の考え方(2022.08.10)
- Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
「ソフトウェア工学」カテゴリの記事
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.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」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
コメント