第4章 バージョン管理 バージョン管理
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
ポラロイドメガネを通して世界を見る
労働者階級にとっては、状況はずっと良くなるだろう。
ギャング・オブ・フォー、"アイ・ファウンド・ザット・エッセンス・レア"
この章では、リビジョン管理システム(RCS)について説明する。RCSは、あるプロジェクトが発展していく過程で、そのプロジェクトのさまざまなバージョンのスナップショットを管理するもので、例えば、本の開発段階、苦悩に満ちたラブレター、あるいはプログラミングの開発段階などである。
RCSを使うことで、私の仕事の仕方が変わった。例えて説明するなら、文章を書くことをロッククライミングに例えて考えてみよう。ロッククライミングをしたことがない人なら、固い岩壁と、頂上まで行くという威圧的で命がけの作業を思い浮かべるかもしれない。しかし現代では、そのプロセスはもっとインクリメント的だ。ロープにつかまって数メートル登り、特殊化した器具(カム、ピン、カラビナなど)を使ってロープを壁に固定する。これで、もし落ちてもロープは最後のカラビナで引っかかるので、それなりに安全だ。壁の上にいる間は、頂上に到達することよりも、次のカラビナをどこにクリップできるかを発見することに集中する。
RCSを使った執筆に戻ると、1日の仕事はもはや頂上に向かって無機能のスローグではなく、小さなステップのシーケンスになる。何かひとつ機能を追加できないだろうか?どんな問題を解決できるか?一歩を踏み出し、コードベースが安全でクリーンな状態であることを確認したら、リビジョンをコミットする。次の一歩が悲惨な結果に終わっても、最初からやり直すのではなく、コミットしたリビジョンに戻ることができる。
しかし、書くプロセスを構造化し、安全な点をマークできるようにすることは、ほんの始まりに過ぎない:
-
ファイルシステムに時間の次元が加わった。RCSのファイル情報リポジトリをクエリして、あるファイルが先週どのような状態だったのか、そしてその時点から現在までにどのように変化したのかを見ることができる。他の力がなくても、これだけで私はより自信に満ちたライターとなることが発見できた。
-
自分のコピーと共著者のコピーのように、プロジェクトの複数のバージョンを追跡することができる。自分の仕事の中でも、実験的な機能を持つプロジェクトのバージョン(ブランチ)が欲しいことがある。
-
GitHubには、この記事を書いている時点で、主にC言語で書かれていると自己申告しているプロジェクトが約314,000あり、GNUのSavannahのような他の小規模なRCSリポジトリホストには、もっと多くのCプロジェクトがある。コードを修正するつもりがなくても、これらのリポジトリをクローンすることは、プログラムやライブラリを自分のハードドライブに取り込み、自分で使うための手っ取り早い方法だ。自分のプロジェクトが一般に使えるようになったら(あるいはそれ以前に)、配布の別の手段としてリポジトリを公開することができる。
-
今、あなたと私は同じプロジェクトの同じバージョンを持っており、コードベースのそれぞれのバージョンをハックする能力を同等に持っている。リビジョン管理は、複数のスレッドをできるだけ簡単にマージする力を与えてくれる。
この章ではGitを取り上げる。Gitは分散リビジョン管理システムで、プロジェクトのどのコピーも、プロジェクトとその履歴の独立したリポジトリとして機能する。他にも、MercurialやBazaarがこのカテゴリーのトップランナーである。これらのシステムの機能には、ほぼ一対一のマッピングがあり、大きな違いがあったとしても、長い年月の間にマッピングが統合されたので、この章を読み終えたら、他のシステムもすぐに使いこなすことができるだろう。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access