コミットの粒度
コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。
【元ネタ】
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)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「廃止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」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント