Git リモートリポジトリ:Linux 使い（略）Advent Calendar 2024
はじめに
これは「Linux 使いになりたい人のための Advent Calendar 2024」の記事です。
筆者は、Web エンジニアを志望する人には、セルフホスト Git サービスを稼働させて利用することをオススメしています。もし Git を使ったことがないなら、Git を学ぶときに、セルフホスト Git サービスを稼働させることも視野に含めながら学習するのが効率的だと考えています。
Git リモートリポジトリ
今回は、Git リモートリポジトリについて、セルフホスト Git サービスを稼働させるときに知っておきたいことについて説明します。
ローカルマシンで用意する Git リモートリポジトリ
GitHub などのクラウドサービスを使って Git を学んだ人は意外と知らないのではないかと思いますが、Git リモートリポジトリはリモートマシンになくても用意することができます。
Git のリポジトリをクローンするときに使う git clone コマンドは、クローンのソース URL を指定するので、そこに file://<絶対パス> を指定すれば、ローカルマシンにある Git リポジトリのクローンができます。
ただ、学習時にローカルマシンにある Git リポジトリを使う説明をするより、実際にリモートマシンにある Git リポジトリを使った方が説明と実体が一致するので、わかりやすいはずなので、そちらを使うことが多いはずです。
これを知っておくと、リポジトリのバックアップを別ディスクへ作成するときに、 git clone をすれば、後は git fetch や git pull で差分バックアップがとれば良いということに気がつけます。とはいえ、バックアップは普通にファイルコピーや rsync コマンドでの差分同期コピーでも良いので、知らないと困るというわけでもありません。
他にはディスククラッシュ時にディスクだけ取り出して、git コマンドでデータが正しく操作できるか確認するためにも使えますね。知らないと「リモートアクセスで、サルベージした Git リポジトリが使える環境を用意してから確認するしかない」と思って余計な作業をしてから確認することになります。
Git リポジトリ用のディレクトリー
ローカルマシンで使用する Git リポジトリーは編集作業で使えるワーキングディレクトリーと、そこに含まれる .git ディレクトリーで構成されています。
ここに出てくる .git ディレクトリーが Git リポジトリ用のディレクトリーの実体なので、それを知っていると Git についての理解が深まるはずです。
ですから、実はローカルマシンの Git リポジトリーをバックアップするときにワーキングディレクトリーにあるものは無視して良い場合は .git だけアーカイブしておけばバックアップになります。
こんな知識は何に役に立つのか疑問に思うことでしょう。筆者の場合は、次のようなときに利用しています。
筆者は学習用コンテンツを作成することがあるのですが、そのときのソースコードについてバージョン管理をしています。この学習用コンテンツのソースコード用 Git リポジトリとは別に、解説用のドキュメントは別の Git リポジトリで管理しています。
解説用のドキュメントは説明用なのでソースコードとは別のバージョン管理が必要です。とはいえ、別のリポジトリで管理するというのも手間が多いです。こういうときに、ソースコード用の Git リポジトリについては、.git ディレクトリをアーカイブして、それを解説用のドキュメントの Git リポジトリで管理することにしています。
また、筆者は開発コンテナー内で作成することが多いのですが、開発コンテナー内でサンプルコードのような軽めのコードを作成するときも基本的にバージョン管理しています。これを Docker ホストにあるリポジトリへ含めて管理したいときは、これを Docker ホストへコピーします。そういったときに、必要なのは .git ディレクトリだけなので、これをアーカイブしてコピーして、それを Docker ホストにあるリポジトリへそのまま登録しています。
ちなみに、開発コンテナー利用時に Docker のバインドマウントを使えば、Docker ホストへのコピーは必要ないのですが、バインドマウントは副作用も多く性能面でも環境によっては問題が起きることが多いので、基本的に使わない方針で作業をしています。コンテナーで使うファイルで永続化が必要なものは基本的に Docker ボリュームに入れています。
また、ディスク復旧の作業をしているときや開発用ではないコンテナーを使っているときは、git コマンドは使えないけど tar コマンドや cp コマンドは使えるといった場面も多くあります。そういったときに、git コマンドを使わずに Git リポジトリをコピーしたい場面で、役に立つはずです。なかなか、そういった場面はないかもしれませんけど :P
Git リモートリポジトリの管理
さて、ここで、Git リモートリポジトリの管理方法について考えてみます。ここまでの説明から、パソコンが1台しかない場合は、わざわざ別マシンを用意して Git リモートリポジトリを用意しなくても良さそうだと思う人も多いことでしょう。
実際のところ、Git をそれほど使わない、Git リポジトリの数も数個しかない、というのなら、ファイルベースで管理しても大丈夫でしょう。ただ、Git を使いこなすようになってヘビーユーザーになってくると、そうもいかなくなります。
Git リモートリポジトリにメタデータを付与して、簡単に説明をつけておいたり、どんなバージョン変更を加えてきたのかのサマリーがわかるようにしたり、リポジトリの一覧から絞り込み検索をしたり、といったことができる環境が欲しくなってきます。
そういったニーズに簡単に応えることができるのが、セルフホスト Git サービスになるのです。セルフホスト Git サービス用のソフトウェアには種類がいろいろありますが、長く使うことを考えると Web ベースで利用可能なものが良いです。
Git リポジトリは一生使い続ける前提といっても良いものなので、その視点から決めたいところでしょう。
- 継続的に開発がされそうなもの
- サポートされる OS/CPUアーキテクチャ が多いもの
- 自分が管理できそうなもの
「継続的に開発がされそうなもの」というのは、個人開発のものよりはチーム開発されているもの、頻繁に更新がされているもの、利用者数が多いもの、といった評価軸で選定すれば良いはずです。
サポートされる OS/CPUアーキテクチャ が多い方が良いのは、現在自分が使っているパソコンの OS で動きさえすれば良いという視点だと長期継続利用というのが難しくなるからです。筆者も、最初は Windows マシンをメインにして使っていましたが、途中で macOS マシンになり、現在は Ubuntu マシンとなっています。
知り合いの学生さんは、「大学1年生のときは Windows マシンが良かったけど、2年生以上だと Ubuntu マシンが良さそう。でもインターンでお世話になった会社だと macOS マシンが支給されていたから、macOS マシンが良いのかな」と言っていて、置かれる環境によって、どの OS を使うのが良いかは変わる時代になっています。
サポートされる OS が多ければ、OS を変更しても移行して使い続けることはできるでしょう。最近は Docker があるので、それほど困ることはないかもしれませんが、Intel/AMD 系と ARM/M 系の両方をサポートしているかどうかも影響があるので注意したいところです。
最後は、「自分が管理できそうか」になりますが、持っているハードウェアやスキルによって管理できるかどうかが変わります。たとえば、GitLab はそれなりに高性能なハードウェアが必要なので、それが用意できないのに使おうとすると、重すぎてやってられなくなるでしょう。
Java プログラマーを目指したいと考えているなら、Java で実装されたものを使うモチベーションが高くなるはずです。たとえば、利用時になにかトラブルがあったとき、解決にあたっては Java や OS についての知識が必要になることが多いです。そういったトラブルシュートの経験を積むことによって深まる理解もたくさんあり、これがスキルアップにつながります。
スキルアップにつながることから、何かトラブルがあっても、それを解決して管理しようという意欲が継続するでしょうが、そうでなければ、嫌になって使わなくなってしまうかもしれません。
おわりに
ということで、筆者は増えていく Git リモートリポジトリを管理するには、セルフホスト Git サービスが便利だと考え、これを個人運用することで、スキルアップしてきました。仮想環境関連の知識も、セルフホスト Git サービス用の仮想環境を用意することで身につけてきました。
普段は使わないものについて、スキルアップするのは特別に時間を確保する必要があり難しいものです。普段は使っていて役に立つものについては、自然と知識が増えていきます。筆者は、そういう環境を用意することが大切だと考えています。
Discussion