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」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #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)
コメント