バージョン管理とは / 01-a-vcs

Transcript

1. 1 26 バージョン管理とは 慶應義塾大学理工学部物理情報工学科 渡辺 2026年3月9日 計算物理春の学校2026「計算物理屋のためのGit/GitHub入門」
2. 2 26 バージョンを管理するということ 実行 開発 デバッグ 多くの知的生産活動は、修正を繰り返す 執筆 添削 プログラム開発 論文執筆
3. 3 26 バージョンを管理するということ 仕様書_佐藤修正_吉本追記.docx 仕様書_最終版_田中修正v2.docx どっちが最新？ バージョン管理システム (Version Control System, VCS)
4. 4 26 バージョン管理システム • ファイルの編集履歴を管理するためのシステム • 編集履歴をすべて保存する「リポジトリ」というデータベースを持つ • ユーザはリポジトリにアクセスしながら開発を行う バージョン管理システムとは？ 何ができるようになるの？ • 任意の時点に状態を戻すことができる • 任意の時点間の差分を確認できる • 誰が、いつ、どこを修正したか確認できる 超優秀な秘書のようなもの
5. 5 26 バージョン管理システムの歴史 ローカル型 クライアント・サーバ型 分散型 SCCS, RCS等 CVS, Subversion等 Mercurial, Git等 歴史的に大きく分けると、以下の三種類
6. 6 26 バージョン管理システムの歴史 第一期：ローカル型 • (おそらく)世界初のVCS • IBM System/370向けに開発、後にPDP-11へ移植 • 複数のバージョンを一つのファイルに保存 1992年 Source Code Control System (SCCS) 1982年 Revision Control System (RCS) • バージョン管理はファイル単位 • ファイルを修正する時に「チェックアウト」する ファイル修正時にロックをかける(排他制御) → 複数の人が同時に編集できない 管理がファイル単位 →プロジェクトとして管理できない
7. 7 26 バージョン管理システムの歴史 第二期：クライアント・サーバ型 • RCSのフロントエンド • リモートリポジトリを導入 • 複数の人が同時に修正可能 • 「マージ」の導入 1986年 Concurrent Version System (CVS) 2000年 Subversion • ファイル名変更やディレクトリの管理をサポート • プロジェクト全体にバージョン番号(リビジョン)を付与 中央集権的なリモートリポジトリ → 全ての歴史がリモート側にある → 単一障害点になってしまう
8. 8 26 バージョン管理システムの歴史 第三期：分散型 2000年 BitKeeper • ローカルに全ての情報がある(分散型) • Linuxカーネル開発に使われた商用ソフトウェア 2005年 Git • 一部のLinux開発者がBitKeeperをリバースエンジニアリング • BitKeeperを使えなくなったLinusがGitを開発 • 高速なブランチ切り替えやマージ 全てのリポジトリが完全な履歴を持つ リモートとローカルの歴史の整合性を取る
9. 9 26 バージョン管理システムの歴史 Eclipse Community Survey SubversionとGitのシェア 利用率(%) 2018年のStackoverflow Surveyでは、Git 87.2%、Subversion 16.1% 現在、VCSとしてはGitが大きなシェアを持っている
10. 10 26 GitとGitHub Git バージョン管理システム 履歴などを管理する 自分にとって「ローカル」 GitHub Gitのホスティングサービス データや履歴をリモートにも保存 ソフトウェア開発のプラットフォーム 自分にとって「リモート」 Git logo by Jason Long CC BY 3.0 ※ GitのホスティングサービスとしてはGitLabも有名
11. 11 26 ありがちなパターン1 1. 自宅と大学で論文執筆作業 2. 先生に論文添削を依頼 3. 添削が返ってきた時、古いバージョンを渡してしまったことに気づく
12. 12 26 ありがちなパターン2 ローカル スパコン 2. 動かなかったので修正 3. ジョブ実行中、機能追加 4. 修正したコードをスパコンへ あ！上書きしちゃった！ 1. 開発したコードをスパコンへ
13. 13 26 バージョン管理してたら？ 1. 論文を修正して送信 3. 論文を受け取って修正 学生 先生 2. 添削を依頼 ※ Overleafなどを使う人も多い
14. 14 26 バージョン管理してたら？ ローカル スパコン 3. ジョブ実行中、機能追加 1. 開発したコードをスパコンへ 2. 動かなかったので修正 4. 修正したコードをスパコンに持っていこうとしたら拒否される バージョン管理していると作業が失われない
15. 15 26 バージョン管理システム バージョン管理システム導入の二大メリット 渡辺が 考える バックアップ 履歴保存
16. 16 26 バックアップ 作業中のPCが壊れた！ 間違って古いバージョンで上書き！ 作業ミスで消しちゃった！ 重要なファイルの消失により、大きな「手戻り」が発生する
17. 17 26 バックアップ バージョン管理システムとして Git/GitHubを使うと上記要件を 自動的に満たす バックアップは定期的にとる バックアップ頻度＝データが飛んだ時の手戻りの時間 最低でも毎日バックアップすること バックアップはリモートにとる 自分のPCの別フォルダにコピーするのはダメ USBへのコピーも信用できない
18. 18 26 履歴保存 バージョン管理システムを使っていると... • 任意の時点に状態を戻すことができる • 任意の時点間の差分を確認できる デバッグ時間の短縮
19. 19 26 履歴保存とデバッグ 数値計算コードを開発中、 • メインカーネルを修正し • 別のインプットを与えたら 計算に失敗した 計算ルーチン (修正前) インプット A OK 計算ルーチン (修正版) インプットB NG その機能を追加したことによるバグ？ もともとあったバグがインプットにより顕在化？
20. 20 26 履歴保存とデバッグ バージョン管理システムを使っていないと... ソースとにらめっこして 気合でデバッグ 徹夜でなんとか バグ発見 自分で入れたバグを自分でとっただけで、仕事はなんら進んでいない
21. 21 26 履歴保存とデバッグ バージョン管理システムを使っていれば... 修正前のメインカーネルを取得し、Input Bを食わせる OK NG 今回の修正でバグが入った 計算ルーチン (修正前) インプット B もともとあったバグが顕在化 問題の切り分けが容易
22. 22 26 履歴保存とデバッグ 昔入れたバグほど、デバッグが困難に (修正内容を忘れているから) 開発時間軸 Ver. 1 Ver. 2 Ver. 3 Ver. 4 Ver. 5 (1)ここでバグ発覚 (3)ここでバグ混入 (2)ここまでは動作することを確認 デバッグ時間軸 Ver. 2とVer. 3の差分を取れば、バグの原因がすぐにわかる
23. 23 26 プログラミングのできる人、できない人 開発 デバッグ 開発 デバッグ 作業時間 進捗 作業時間 プログラミングが早い人は「デバッグ時間」が短い 左の人の方が「がんばっている」ように見えるが、 右の人の方が作業は進んでいる
24. 24 26 見えないコスト 開発 デバッグ 開発 手戻り バージョン管理システムを使っていない人は 「バージョン管理システムを使っていれば節約できた時間」 を認識できない デバッグに時間をかけているひと「自分はがんばっている」 PCが壊れてデータを失った人「自分は運が悪かった」 VCSを使っていれば この時間節約できたかも
25. 25 26 バージョン管理システム バージョン管理システムを使えばデバッグ時間が短く なるわけではない 「できる人」はGitが使えるから「できる」のではない GitやGitHubはあくまでも「開発スタイル」を支援するツール • Gitが「何を」実現するツールなのか • 自分がGitで「何を」しようとしているのか を理解することなしに開発効率は向上しない
26. 26 26 まとめ • バージョン管理システムとは、ドキュメントやソフ トウェアのバージョンを管理するためのシステム • 複数人開発で有用なツールだが、個人開発でも有用 →三日前の自分は他人 • バージョン管理システムを使えば開発効率が上がる わけではない →開発スタイルを変えなくてはならない Git/GitHubの使い方を学ぶことが目的ではない ツールに流れる哲学を学ぶ