Gitの話をしよう。
Gitなんて「息をするように」つかうもんだよねぇ～
最近はこんな初心者殺しなことを平気で言う人もいたりします。そんなこといたって。
知らないものはしらんよ。
なわけで、少しずつ整理して理解を深めていけばいいと思います。私ならそうします。ただ、gitの使い方とかテクニックとかそういう話は数多あるんで、そちらにゆずります。 この記事では、おもにGit と Git Hubは違いますよ～って話をしたいと思います。
この記事には「本当ではないこと」が多分に含まれています。概念と経緯を浸透しやすく丸めて、理解しやすくしたいと考えているからです。読んでくれた人が少しでも分かってくれたらうれしいな。
Gitってなんですか？
Gitはファイルのバージョンを管理するためのソフトで SCM(Source Control Management) 一つです。SCMのもっとも重要な役割は以下二点で、これができないソフトはSCMではありません。
- ファイルの状態管理
- ファイルの変更履歴管理
ここで 「変更履歴管理」 とさらっと書いていますが。これは、過去のあらゆる時点（コミット）にさかのぼってファイルを再現可能であるということ意味します。よくあるファイルサーバでファイル名+日付管理は人がやりますが。プログラムという超多量のファイルの集合体に対して管理してくれるのがSCMの利点です。
| No. | 世代 | 名称 | ネットワーク共有 (リポジトリ) |
備考 |
|---|---|---|---|---|
| 1. | 第一世代 | SCCS | なし | 対象ファイルのディレクトリに管理ディレクトリを作成しDELTASファイルを作成、更新する。 |
| 2. | 第世代 | CVS | あり | RCSを基礎として開発。ネットワーク共有機能を追加。整理。 |
| 3. | 第二世代 | Subversion | あり | CVSの問題点を解消。例えば、ファイル名変更時の履歴の引継ぎや、http等のより汎用性の高いプロトコル利用など、より利用しやすくなっている。 |
| 4. | 第三世代 | Git | あり | 分散管理型SCM。Linux kernel管理用に開発 |
| 5. | 第三世代 | Mercurial | あり | 分散管理型SCM。JavaFXのコード管理などに利用されている |
コンピュータの使われ方と密接に関係しています。そのため、第三世代として取り上げているGit/Mercurialは、登場時期も同じです。同じような課題を解決したいと思っているはずなのでおそらくできることもほぼ同じかと。。。知らんけど。
リポジトリってなんですか？
リポジトリとは、ファイルを共有するためのデータプールです。利用者はこのリポジトリを共有することで、ネットワークごしの共有を実現します。リポジトリに対する操作の代表を以下に示します。
| No. | 操作 | 役割 | 備考 |
|---|---|---|---|
| 1 | Check Out （チェックアウト) |
リポジトリからファイルを取得する。 | |
| 2 | Add （追加） |
ファイル(または、その変更)をリポジトリに追加する。 | 対象の変更を登録対象として印をつける（ステージする） |
| 3 | Commit （コミット） |
ファイルを（または、その変更）リポジトリに登録する。 | この時点でリポジトリに取り込まれ、再現可能な静止点となる |
リポジトリを共有しましょう
このリポジトリの共有の仕方は、「集中管理型」 と 「分散管理型」 で大別されます。
| No. | 共有方式 | 特徴 |
|---|---|---|
| 1 | 集中管理型 | リポジトリを全ユーザ間で共有する。 |
| 2 | 分散管理型 | リポジトリをユーザ毎にコピーして利用する。 |
集中管理型では、リポジトリの情報を取得するたびに、ネットワークを介して情報を取得します。(そこにしか情報がないのです。)
日本のSIerに今でも大人気 のSubersionはこのタイプです。Subversionの場合、「指定したフォルダ以下の全てのファイル」の最新版だけをワーキングcopyとして取得します。checkout commit, 過去のファイルの取得もネットワーク接続時にのみ可能です。閉鎖ネットワークで開発することを前提とした場合とても使いやすいものです。（あと、ネットワークリソースやストレージリソースが貧弱な場合も）
分散管理型は、リモートだけではなく、ローカルにリポジトリをcopyしておくので、必要な情報をいつでも取得可能としています。
OSS開発で大人気のGitは、このタイプです。ネットワーク速度の向上とストレージ価格の下落が普及を後押ししました。OSSの過去の状態をいつでも参照可能で、作業を自体をネットワーク接続から分離できる特徴から世界中で利用されています。
湖畔の別荘でのんびり開発したい！！ そこにネットワークがないからできないとか単なる甘え
ってことです。さすが、欧米人は違います。
出てくる要素が1段増えたので、操作も増えます。
| No. | 操作 | 役割 | 備考 |
|---|---|---|---|
| 1 | Check Out （チェックアウト) |
リポジトリからファイルを取得する。 | |
| 2 | Add （追加） |
ファイル(または、その変更)をリポジトリに追加する。 | 対象の変更を登録対象として印をつける（ステージする） |
| 3 | Commit （コミット） |
ファイルを（または、その変更）リポジトリに登録する。 | この時点でリポジトリに取り込まれ、再現可能な静止点となる |
| 4 | Copy1 | リモートリポジトリをローカルリポジトリに複製する。Git ではClone | Clone はcopyと一緒にmasterもしくはmainのcheckoutも行う。 |
| 5 | Copyback2 | ローカルリポジトリの変更をリモートリポジトリに反映する。Git ではPush |
最後に、Git と Subversionの検索回数の差です。やはりGitの方が人気なように見えますが。Gitの方が難しいという意味もあるのかもしれません。
あれ？GitHubが出ていないよ？
はい。出ていません。出てくる場面がないのです。だってGit Hub は バージョン管理システムじゃないから。Gitの話をしている場合は、ビタイチ出てこないのです。では、GitHubとは何なのでしょうか？
リモートリポジトリに要求されるもの
話を戻しましょう。Gitの運用に欠かせないリモートリポジトリに求められるものは何でしょうか？
| No. | 求められること | 具体的には？ | 必須 |
|---|---|---|---|
| 1 | 誰でも利用可能なプロトコルによる応答 | HTTP(S) または SSH | 〇 |
| 2 | 適切なユーザだけが、リポジトリを操作可能とすること | 認証 | 〇 |
| 3 | ユーザの役割に応じてできる操作、アクセス可能なデータを制限すること | 認可 | △ |
| 4 | 潤沢なストレージ | HDD/SSD/NAS/S3/Cloud Storage | 〇 |
| 5 | データを失ってはいけない | バックアップ | 〇 |
| 6 | なるべく高速なレスポンス | キャパシティ見積もりかなぁ | 〇 |
1,2,4を実現するのは割と簡単で、極端な話SSHDが走っているLinuxサーバがあれば十分です。
慣れた人なら1日かからず運用を開始できます。しかし、3,5はそうではないのです。最低5を整えるだけで、バックアップシステムの設計、開発、構築。バックアップストレージの設計い開発、構築、レストア手順の策定とちょっと油断すると数千万円規模の予算が必要になります。継続的に運用する必要があるので、ランニングも馬鹿になりません。
GitHub大地に立つ！！
ところで、上の表に開発対象ごとに異なる要件ってありますか？ないですよね。だったらとっても大きい箱を用意して、それをみんなで使うほうが、「安く、早く、安全」になりそうです。
それをサービス（ビジネス）として実現、提供しているのがGitHubです。あぁやっと出てきた。
差別化しないとね！
さて、リモートリポジトリ代行サービス。「だけ」だと、すぐにレッドオーシャン化してしまいます。ちょっと大きなデータセンタ抱えてれば誰にでもできてしまうのです。皆さんご存知のF〇itsuとか日本の電気屋さんとか、国内のダメダメベンダーだって実現可能です。長く商売をするには差別化要因が必要です。たとえば 「ルナチタニウム合金」 とか 「パイロットがニュータイプ」 みたいな。。
彼らの差別化要因はやはりOSS開発に根差したものでした。
- Pull Request機能による開発者主体の開発の実現
- Issue管理との連動
- APIの制定とその運用
1点目と3点目がすごく大きいかと思います。1点目は商標なのか、後発の各製品がある時期軒並み「Pull Request」を「Merge Request」に置き換えました。APIの制定と運用も大きいですね。他のCI/CD製品が連動する基盤としての地位を気付きあげることに成功したのです。これらのキーアイデアを武器に、OSS開発者のUXを磨き上げ、他者との差別化を図っています。
Git Hubクローンだってさ
こんなに素晴らしいGitHub。みんながまねをするに違いありません。え？ガンダム基、GitHubは唯一無二でほかに変わるものはない？ありますお？ガンダムにだって、陸戦型やら、パーフェクトやらフルアーマーやジムがいたんだから、GitHubにだってGitHubクローンが出てきてあたり前です。いくつか例を挙げます。
| No. | ソフト名 | 概要 |
|---|---|---|
| 1 | Git Lab | 言わすと知れた、貧者のGitHub APIだってほぼ同じように使えます。 |
| 2 | GitBucket | takezoe氏のGit Hub オマージュ。1 warでいきなり起動。試すだけなら一番簡単 |
じゃぁ、そのうちGitHubは廃れちゃうの？
立ち止まっていればそうでしょう。でも彼らは立ち止まりません。先だってリリースされたGitHub copilotは素晴らしい。MSの資本をうけた一つの成果だと思います。
まとめ
以上、Git と Git Hub についてでした。いわゆるGitの良さを語る場合、Pull Requestがぁ～ とか APIがぁ～ とか ISSUE管理と連動してとか言っちゃうのは、「GitHubの良さじゃね～か‼Gitの話違うんかい」 ビッシィ というお話でしした。