本来開発知識編の中に詰めておく予定だったが、なんか思ったより長くなりそうなので別で解説することにしました。
Gitが何なのか解説します。知ってる方は読み飛ばしてOK。 Gitはいわゆる「バージョン管理ツール」のこと。開発において書いたコードを「コミット」という単位で保存することができる。
開発の工程を記録し、どの段階でどんなコードを書いたかを履歴として残す事の出来るシステム。 集中管理方式と分散管理方式があるが、今は専ら分散管理方式を使う。 というかGitが分散管理方式なのでほぼそれ一択みたいなもん。
| 管理方式 | システム名 |
|---|---|
| 集中管理方式 | CVS(Concurrent Versions System) |
| 集中管理方式 | SVN(Subversion) |
| 分散管理方式 | Git |
| 分散管理方式 | Mercurial |
集中型と分散型の違いは マンガでわかるGit 第6話「集中型と分散型、何がどう違うの？ を読むと分かりやすい。
「マンガでわかるGit」はGitについて学ぶなら普通にいい本？らしい（ちなみに筆者はおススメされたが買う前に大体わかってしまったので買ってない）
ぶっちゃけサル先生のサイトでも十分学べるので買わなくてもいける。
GitHubとはその名の通り、GitのHub、つまりGitの中継的な機能を提供するサービス。
Gitをホスティング（共有管理）出来る開発プラットフォームという認識で問題ない。
ちなみに同じようなサービスにGitLabやBitBucket等がある。
そもそも自前でGitのサーバーを作れなくもない。が、めちゃ面倒なので大体GitHubで済ませる。
GitHubではネットワーク上でリポジトリを作成、共有することができる。 そのため、GitHub上でOSS（オープンソースソフトウェア）の開発を行うことができる。
あくまでGitHubはGitを管理しているだけなので、開発に使用する場合は、ローカルマシンにGitがインストールされてなければならない。
GitHub関係の情報を漁っているとよくローカルだとかリモートだとかいう単語を見かける。 これらはそれぞれどのリポジトリに焦点を当てているかで呼び方が決まっているからである。
GitHubに上がっている（公開されている）リポジトリをリモートリポジトリ、それらをクローン（ダウンロード）してきたリポジトリをローカルリポジトリという。 そのため、Gitで管理されているリモートリポジトリを扱うにはローカルリポジトリでも同じようにGitを使用しなければならない。
ここからはGitHubについて少し詳しく説明していく。
GitHubのリポジトリには2つの種類が存在する。publicリポジトリとprivateリポジトリである。 名前から察することのできるように、これらはソースコードを公開するか非公開にするかの違いである。 publicを指定すると、誰でもソースコードを閲覧することが出来るようになる。かつてこれが問題になった事がある。どこぞの銀行のソースコードがGitHub上に公開されていたという話だ。詳しい話はこちらを参照。
ちなみにpublicだろうがprivateだろうが業務的に秘密にしなければならないものは個人でGitHubに上げないほうが良い。privateリポジトリに不正アクセスされた事案があるからである。詳細はこちらを参照。
privateリポジトリでは、対象のソースを見ようとしても、権限がない場合は「404 not found」が返ってくる。 privateなリポジトリで他の人と一緒に作業する場合は、コラボレーターとして対象のユーザーを追加しなければならない。 実際のところpublicでもコラボレーターとして参加しないと作業が出来ないかもしれないが。
筆者は最近完全にVSCodeに浸かっていて、Git関係の操作も全てVSCodeを通しているため、ネイティブなコマンドは久しく使っていない。 申し訳ないが、コマンドを使用する場合は、各自で調べてほしい。
GutHub上にリポジトリを作成するには、何種類かある。
- GitHub上から直接空のリポジトリを作成する。
- 既にあるソースコードをGit管理させてから、GitHub上にアップロードする。
- 他のリポジトリをフォークしてくる。
1はそのままの意味。GitHubのサイト上から空のリポジトリを作成する。
2は、既存のソースコードをアップロード出来るため、プロジェクトリーダー等がひな形やデフォルトのコードを作成してから行えばスムーズに開発が進む。
3は少し特殊な例。GitHubでは、リポジトリーをフォークすることができる。フォークというのは、リポジトリをまるっと自分のリポジトリとしてGitHub上にコピーすることである（厳密には少し異なる）。publicなリポジトリの場合は、コピー元のリポジトリが削除、あるいは非公開になっても残り続ける。privateなリポジトリの場合は、forkしたリポジトリはすべて消えてしまう。（ただしローカルには残っている）
フォークの特徴は、普通のリポジトリのコピーと違い、コピー元のリポジトリにプルリクエストを送ったり、コピー元の変更を反映させられる事が出来る事である。
ぶっちゃけそこまで気にしなくてもいい。
先で述べた、「既にあるソースコードをGit管理させてから、GitHub上にアップロードする」という行為は、慣れない状態で行うと大変なことになる場合がある。
- Debug用のファイルやフォルダもGitで管理したため、マージする時に毎回コンフリクトが起きる。
- アクセストークンやパスワード、API_KEYをGitHub上に公開してしまう。
- node_module等のパッケージ群まで含んでしまい、更新ファイル数が頭おかしい量になる。
実はこれらは筆者がやらかした内容。他にもなんかあるかもしれない。
これらを解決するのがgitignoreである
Gitは、追跡対象となるフォルダ（ディレクトリ）を指定することで管理を開始する。 監視対象となるフォルダには「.git」という隠しファイルが作られ、その中にGit関連の設定ファイルが入っている。 その隠しファイルと同じ階層に「.gitignore」というファイルを作成すると、Gitから監視を外すフォルダやファイルを指定することができる。
ディレクトリ例）
root/
├─ .git/
│ ├─ config
│ ├─ HEAD
│ etc..
│
├─ .gitignore
│
└─ src/
├─ index.js
├─ index.html
etc...
が、実はここで少し面倒な事が発生する。
本来（コマンドを使用）のgitでは、一度監視を始めたファイルは、後からgitignoreを指定しても監視され続けるのだ。 これは本来のgitignoreが、監視されていないファイルを監視しないものとして維持するという機能だから。 つまるところ、既に監視されている項目を後からgitignoreに入れても、監視を終了する事が出来ないのである。
Gitの監視対象から外す場合は基本コマンドから行うしかない。監視対象から外すコマンドは
git rm --cached 対象のファイルパスのようなものである。
ディレクトリ（フォルダ）の場合は、git rm --cached -r 対象のフォルダパスとする。
コマンドのオプションについて説明する。
--cachedの部分はコマンドのオプションといわれており、無くてもコマンド自体は動く。しかし、挙動が変わってしまうため注意。
--cachedは、監視対象から外すときに、同時にファイルそのものを削除するかどうかのオプションである。
--cachedを指定しない場合は、監視対象から外すと同時に実際のファイルも削除される。
--cachedが指定されている場合は、監視対処から外すのみで、実際のファイルは削除されない。
時と場合で使い分けるといい。
ちなみに-rは再帰的(recursive)の頭文字で、ディレクトリの中まで再帰的に処理するという意味である。簡単に言うと、ディレクトリを指定する時につけなければいけないおまじないみたいなもの。-r無しでは、ディレクトリを対象に何かする事は出来ない。
gitignoreについて詳しく書かれているサイトとしては、ここと ここ（Qiita）
監視済みのファイルを監視から外すメカニズムに関しては上記のQiitaの記事が役に立つ。
Gitはファイルの差分を記録し、誰が何処で編集したのかも記録できる。 おかげでクソコードを書いて勝手にマージしても普通にバレる。 GitLensを入れておくとよく分かる。
現状は「開発用仕様書.pptx」にまとめてあるが、より詳細をこちらで記載する予定。目指せ脱パワポ。 図があったほうが良いのであちらで解説済み。
ここまでGitについて話しておきたい事をつらつらと書いておいた。 思いついたら追記していく。 出来れば全員にGitの管理者側（Merge役やリポジトリ主）を体験してほしい。得られる経験がだいぶあると思う。
- 2022-07-20
- 第一版完成