PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み
PullRequestは分散バージョン管理の利点を生かしたコードレビューのパッチ取り込みなのだと下記の記事を読んでようやく分かった。
考えたことをラフなメモ書き。
【元ネタ】
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok
現在の開発では、trunk(マスター)に対して各開発者がブランチを作ったり、2次開発や大きめの機能の開発、別の顧客向けにカスタマイズする開発などでブランチを作るのはとても普通だ。
すると、マージ作業が発生し、そのマージ作業に非常に大きなコストがかかるのは従来から知られていた。
だが、GitHubが提供しているPullRequest機能を使えば、ブランチ作成(フォーク)→パッチ作成→PullRequest時にコードレビュー→OKならマージ完了という流れがスムーズに行える。
マスターからフォークすることで自分用のブランチを作り、そこで育てたパッチをマスター開発者へ送る時にPullRequest機能を使う。
そこで、自分が作ったパッチはマスター開発者の目にさらされるし、PullRequestによるパッチを誰が誰に送り、どんな議論があったのか、を他の人が参照することもできる。
僕がRedmineで並行開発を行なっていた時、その作業はチケットを経由してやり取りしていたが、コミット後にコードレビューしていたから良い運用とは言えなかった。
チケット単位のトピックブランチによる開発でも、そのトピックブランチはRedmineの管理下にないため、トピックブランチのパッチを手作業でチケットにアップしなくてはならない手間がかかる。
だが、RedmineのVer1.4以降では、SCMのマルチリポジトリ機能があるので、すべてのトピックブランチを登録して、PullRequestをチケット経由で行うようにするやり方もある。
そうすれば、チケットにコードレビューの結果が残るし、どんな経緯でそのパッチが作られて取り込まれたのか、という履歴が残るので、その後の運用保守で非常に役立つ。
できれば、RedmineでもPullRequestの機能を追加できるといいだろう。
実際の運用イメージとしては、マスターとなるリポジトリからブランチを派生できる機能、そのブランチのパッチをマスターへPullRequestする機能があればいいだろう。
つまり、ブランチがマスターのどのリビジョンから派生して、どのリビジョンへ取り込まれたのかが分かるような機能になれば良い。
GitやMercurialがコミット履歴の維持や改変の機能を強化しているように、コミット履歴や作業履歴はソフトウェア開発でとても重要なのだ。
仕様という結果だけではなく、その仕様が決まった経緯も知りたいのだ。
RedmineとGit又はMercurialを組み合わせたチケット駆動開発は、並行開発に関わるソフトウェア開発を大きく変える可能性があると思う。
| 固定リンク
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- 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)
コメント