バージョン管理システムGitに関する世界観です。バージョン管理システムも参照のこと。
Gitは、バージョン管理システム。ファイルツリーの過去のすべての履歴を残した上で、ツリーへの新しい変更をコミット（登録）し、いつでも過去の状態に戻したり、複数人で開発する場合にオンラインのリポジトリを使ってプッシュ（ローカルからリポジトリへ更新）、プル（別の人の行った変更をリポジトリからローカルへ反映）、プルリクエスト（自分の変更を他の人にプルしてもらうようにマージのリクエストをする）などを行うことができる。
そもそもは、Linuxカーネルの開発のために作られたバージョン管理システム。Linuxカーネルでは、CVSへのリーナス個人の嫌悪からBitKeeperという商用のバージョン管理システムを使っていたが、いろいろとあって使えなくなった。CVSは設計の問題から、リーナスは個人的に憎むぐらい嫌いだった。Git以外に乱立していた他のバージョン管理システムの問題は、スピードが遅いこと。たくさんのパッチを管理するLinuxカーネルの開発では、パッチを取り込むスピードが重要になる。GitはLinuxカーネル開発者のリーナス・トーバルズにより、高パフォーマンスであることを優先してCVSやBitKeeperなどの代わりのシステムとして開発された。「他のバージョン管理システムの10倍ぐらい、時には100倍近い性能を誇ることもある」とのこと。
リーナスのネームバリューだけではなく、Gitはとても使いやすいシステムであり、そしてGitHubのようなリポジトリのホスティングサイトが生まれたことで、プログラマなどにとっては必須の開発ツールとなった。基本的に、管理するファイルをgit init（初期化）とgit add（ファイル登録）コマンドで登録すると、.gitと呼ばれるディレクトリが作成される。この状態で、変更するたびにその変更をコミットする。GitHubなどの中央リポジトリを使う場合は、そのリポジトリを設定してログインした上で、コミットの際に同時にプッシュする。他の人のプッシュしたコミットは、プルすることでそれぞれのローカルのファイルツリーに適用できる。
このgitは、プログラミングの際に使うバージョン管理システムとしてもとても有用だが、僕はホームページの管理に使っている。僕個人の感想から言って、FTPでアップロードするよりも、gitでコミットをGitHubにプッシュし、GitHub Pagesを利用した方がストレスがなくホームページを更新できる。FTPのミラーリングアップロードは時間がかかることもあり、大量にあると失敗することもある。gitで差分だけをコミット・プッシュした方が使いやすい。
余談だが、GitHubはなんとLinuxの宿敵だったはずのMicrosoftに買収された。GitHubはAtomというテキストエディタでも有名だが、Atomに使われているGitHubのWeb技術によるGUIアプリケーション開発技術であるElectronは、MicrosoftのテキストエディタであるVS-Codeの開発にも使われている。「ようやくMSも分かってくれたか」という言葉はまさに正しく、LinuxカーネルをそのままWindowsで動作させるWSL v.2を今Microsoftは全力で開発している。WindowsでLinuxアプリケーションを動作させることにも成功しつつある。昔はFUD戦略のように、「Linuxを使うと逆にコストがかかる」と主張していたMSだが、このような状況が、WindowsとLinuxの敵対関係の終結に寄与してくれたら良いと思う。
ちなみに、LinuxだけではなくWindowsでも動作する。Windowsでは、Windows版のgitと、TortoiseGitなどのWindows用のフロントエンドを使うことで、あまりコマンドを使う必要が無い。たまにコマンドを使うと便利だが、基本的にGUIから操作できる。
詳しくはWikipediaが参考になります。
ここまでGitが普及した背景には、Gitを使ったシステムの管理がとてもしやすい、ということが言えます。
たとえば、データベース管理システムを使った場合、できるのは検索と変更が主になりますが、Gitを使ったテキストファイルの管理の場合、UNIXのツールやテキストエディタで編集することもできますし、さまざまなことがデータベース管理システムよりもやりやすい、と言えます。
これが、Jekyllのようなデータベースを使わない静的サイトジェネレータがGitHubなどの界隈で流行っていることの理由として言えます。データベースでWebサイトのコンテンツを管理するよりも、HTMLやプレーンテキストなどの「ファイル」で、Gitを用いて管理した方が、さまざまな管理が楽になります。
OSTreeのような新技術では、ファイルシステムツリーをGitと同様のシステムで管理します。これも、Git技術を使うことで管理しやすいシステムになるということが言えるからです。NixOSというLinuxディストリビューションでは、システムの状態を設定ファイルにできます。このため、/etc/nixos/をGitで管理すれば、システムの状態を上手く管理することができるのです。
以下を参考にしてgitのWindows版とTortoiseGitと日本語化ファイルをインストールしてください。
後日注記：Windowsでは、GitHubの認証情報は「資格情報マネージャー」に保存される。コントロールパネルから資格情報マネージャーを検索して起動することで、GitHubのパスワード情報を削除できる。
大量にファイルがある場合、
git add .
とすると、そのディレクトリ下の全てのファイルをgitの管理対象にできる。この上でファイルをコミットすれば良い。
コミットは、
git commit -m "コミットメッセージ"
自分で作ったプロジェクトではなく、既にプロジェクトとして成立しているgitリポジトリの内容をローカルにコピーするには、git cloneを行なう。
git clone リポジトリ ディレクトリ
ディレクトリは省略可能。たとえば、
git clone https://github.com/schwarz1009/schwarz1009.github.io.git
基本的に、「git clone」→「git commit」→「git push / git pull」→「git commitに戻る」という使い方をする。gitはその繰り返しである。
.gitignoreには、gitで無視したいファイルを列挙する。特に、僕は
Thumbs.db
を設定している。（Thumbs.dbはWindowsのサムネイル画像のキャッシュファイル。）
gitでは、まず管理対象とするファイルをインデックスに追加し、その上でファイルを編集するたびに、コミットを行う。（コミットは複数のファイルを一気に行える。ひとつひとつコミットする必要はない。）
ファイルをインデックスに追加するためには、git addなどを使うほか、git/TortoiseGitをインストールしたWindowsであれば、右クリックやGUIから登録を行なえる。
コミットも、Windowsであれば右クリックメニューから簡単に行える（編集したファイルは勝手に検出される）。この時、サマリー（変更点の要約）をつけることが必須である。
ネットワークでさまざまな人と一緒にリポジトリを共有している時は、リポジトリにプッシュすることで、自分の変更履歴を共有できる。
逆に、他の人の変更履歴を共有するために最新のリポジトリの情報をローカルに反映するためには、プルを行う。
自分が管理するためにリポジトリを複製するためには、クローンを行う。
GitHubとよばれるオンラインサービスを使うことで、オンラインのリポジトリを簡単にホスティングすることができる。全てのファイルを公開するならば無料、非公開にしたいなら有料で、アカウントを作成してGitHubの共有リポジトリを作ることができる。
ブランチは、並行して同じファイルの複数のバージョンを管理する機能。特に設定していない場合はマスターブランチへとファイルをコミットする。
基本的に、
git remote add origin https://github.com/schwarz1009/schwarz1009.github.io.git
としてアドレスを登録し、プッシュする。
git push origin master
GitHubにリポジトリを公開し、プッシュする方法：
GitHubとpush/pullを上手く使うことで、さまざまなパソコンの中でデータを同期・共有できます。
オンラインのGitHubリポジトリを中央のファイルサーバに見立てて、最新の状態をGitHubに更新し、全てのパソコンで同じデータを同期できます。
家庭内だけではなく、職場など離れた環境でも、インターネットでGitHubに繋げる環境があり、gitがインストールされていれば、どこでも最新のデータを同期することができて、便利です。
ですが、GitHubはプライベートなデータの共有には向いていないので注意が必要です。私的なファイル、特にビジネスに必要なファイルのような場合は、Google Driveのようなオンラインストレージサービスを使いましょう。
プルリクエストは、コードの編集をレビュワーに通知してマージを依頼する機能。
GitHubのリポジトリに、自分で開発した成果を取り込んでもらいたい場合などに使用する。
Gitの入門。
みんなで共有出来るソフトウェア開発プロジェクトのためのWebサービス。
最近ではGitLabというGitHubに代わるサイトも流行している模様。
以下のページが参考になります。
最近僕が使い始めたgitの応用ソフトに、git-ftpがある。gitで更新したコミットだけをftpサーバーに転送できてとても便利。
注意点として、git-ftpをインストールする時に/binディレクトリにシンボリックリンクを作る時は、WindowsではスタートメニューのGit Bashの項目を右クリックして「管理者として実行」をクリックして実行したターミナルからコマンドを実行する。
それから、最初はgit ftp initを行うが、すでにFTPサーバーにファイルがある時はgit ftp catchupコマンドを使う。この時、FTPサーバーとローカルgitリポジトリで同じサイトの状態にしなければならない。
そして、ホスト名やユーザー名・パスワードなどのスコープ（名前を複数用意してたくさんのサーバーにデプロイできる）を作る時は
$ git config git-ftp.hogehoge.url FTPサーバのURL
のようにgit-ftp.hogehoge.urlとスペースを空けずに記述する必要がある。.userと.passwordも同様に設定する。URLは明示的なTLSを使う時はftpes://から始まる。
それから、デプロイ（FTP転送）の際にスコープを使う時はgit ftp pushに-s hogehogeなどとする。PASVモードで接続する時は--disable-epsvオプションを使う。
gitで、昔のバージョンに戻したい時があれば、git resetが使えます。
--hard、--mixed、--softの3つのオプションがありますが、「インデックスとワーキングツリーの状態を完全に戻してほしい」時は--hardを使います。
たとえばこのようにします。
git reset --hard 元に戻す先のコミットのハッシュ値
この状態で、ローカルディレクトリのHEADは以前の状態に戻りますが、この状態でgit pullをしてしまうと、GitHubの最新に戻ってしまいます。つまり、昔のバージョンに戻しても、pullをすると最新に戻ってしまうのです。
pullをせずにここでpushをするとエラーがでることがあり、ここではpullをして最新に戻すように勧められますが、GitHubにこの状態でpushを行いたい（リポジトリも元のデータのままで作業したい）時は、以下のように強制pushを行います。
git push -f origin ハッシュ値:master
パッチファイルを作成するにはgit diffを使う。
git diff > diff.patch
できたパッチファイルはUNIXのpatchコマンドで適用できる。
二つのコミットIDの比較は以下のようにする。
git diff 1つ目のコミットID 2つ目のコミットID
さまざまなオプションがあるので詳細は以下を参照のこと。
（以下はGit リポジトリに上がっているファイルを履歴ごと消すには？ - Qiitaを参考に執筆・引用しました。）
誤って個人情報やパスワードをリポジトリに公開してしまった場合、履歴を含めて全部消したい場合がある。
このような時は、git filter-branchを使って、以下のようにスナップショット全てを消せる。
git filter-branch --tree-filter "rm -f hogefile" HEAD git filter-branch --tree-filter "rm -rf hogedir/" HEAD
上は指定ファイルhogefileを消す、下は指定ディレクトリhogedir以下を消す。ディレクトリの場合は/で終わる必要がある。またトップディレクトリで実行する必要がある。
けっこう時間がかかるが、以下のようなメッセージがでれば正常に完了。
Rewrite (ハッシュ値が表示される) (4/4) Ref 'refs/heads/master' was rewritten
この状態で、リポジトリにまだ情報が残っているため、リポジトリを最適化する。
git gc --aggressive --prune=now
そして、リポジトリにpushする。普通にpushしようとするとハッシュが別物になってしまっていてpushできないので、-fで強制pushを行う。
git push -f --set-upstream origin master
また、GitHubなどでは静的HTMLを公開できるGitHub Pagesと呼ばれる機能があり、僕も利用しています。ファイルを公開する必要はありますが、無料ホームページなどを使わず、広告なしでホームページを公開できます。
GitHub Pagesを使う利点は、「リポジトリへのプッシュだけで差分ファイルを更新できる」という点。FTPに比べて、ミラーリングや同期に必要なチェックの時間が短く、さっと公開できます。また、複数のマシンでリポジトリを共有すれば、別のマシンでもホームページを更新できます。
gitは、過去に溜まったコミットをたまに単一ファイルにアーカイブするので、バックアップしている時は注意が必要です。
僕はWindowsでUNIXのrsyncのようなフリーの同期ソフトであるRealSyncをバックアップに使っていましたが、同期しようとした時.gitディレクトリ以下のファイルが大量に消えていたので、「gitが壊れたのかな」と勘違いをしました。
実際は、gitが過去に溜まったコミットをアーカイブしていただけで、単一のファイル（packファイル）の中に消えてしまったファイルの情報は残っていたため（コミットを記録したルースオブジェクトが一連の変更の差分のみを保存したpackファイルにパッキングされただけ）、gitは壊れていないことが分かりました。
このアーカイブ化を手動で行いたい場合は、git gcコマンドを実行します。巨大なリポジトリを操作していると、たまにgit gcコマンドが実行され、リポジトリの中のお掃除をしてくれるようになっています。
Gitが出来る前、ITの世界にはさまざまなバージョン管理システムがありました。
昔からバージョン管理システムの標準として使われていたCVSは設計面で劣悪で、そのために次世代のバージョン管理システムとしてSubversionが開発されました。
また、他にもたくさんのバージョン管理システムの候補がありました。GNU arch, Bazaar, Darcs, Mercurial, Monotone, Veracityなど。
CVSやバージョン管理システムも参照のこと。
GitはLinuxカーネルの開発のために作られました。Linux創始者のリーナス・トーバルズによって開発されました。
Linuxカーネルの開発には、昔はオープンソースではないBitKeeperというソフトウェアが使われていた。CVSは劣悪で使えない。リーナスはBitKeeperの代替品として、自らGitを書くことを決めた。特に、パフォーマンスの点で妥協したくなかったらしい。
GitHubはなんとマイクロソフトによって買収された。マイクロソフトも、本気でオープンソースをやるようになった。
以前、オープンソースを「癌だ」と言っていた時代とは全く逆である。マイクロソフトは最近はLinuxカーネルの開発にも貢献しているオープンソース企業である。
gitについて言えることは、「オープンソースの開発がとても簡単になった」ということです。
適当にgit cloneするだけで、誰でも簡単にオープンソースプロジェクトに開発者として参加できるようになってしまったのです。
gitを開発したのはLinuxカーネル開発者のリーナス・トーバルズですが、彼自身はインポスター症候群（ある程度以上の能力を持って成功しているのにもかかわらず、自分の能力を過小に評価し、「自分は詐欺師である」と感じる症状のこと。詐欺師症候群とも）の傾向があると言って、「LinuxはUNIXの再実装を作っただけ」であると語り、「gitを開発したことで、自分が単なる改良以上のことを成すことができたと自信を持てた」とか「一発屋ではないことの証明になった」と言っていますが、僕はgitは素晴らしいソフトウェアであると思います。リーナスは自分のことを過小評価しすぎです。
ツイッターなどでは、「リーナスが自信を持てないなら自分が自信を持てないのは当たり前だな」などと言った意見があり、面白いです。
余談だが、最近はGitHubなどの普及によって、今までのLinuxにおけるソフトウェアパッケージの導入の方法が変わってきた。いきなりgit cloneしてそれを使えばいいだけ、という風になってきて、FedoraやDebianのようなパッケージ管理システムが必要なくなってきたのである。
ただ、C/C++などのビルドが必要なコンパイラ言語はあるが、逆にいきなりRustで書いてしまって、cargoでインストールを行うような強者アプリも現れてきている。JavaScriptやEmacsにもパッケージ管理システムはあるが、gitがそうした役目の全てを担い始めてきているのである。
ただし、完全にシステムのパッケージ管理システムが不要になるかというとそうではなく、依存関係の処理やアップデートなど今でもパッケージ管理システムは必要である。だが、手軽に開発者と同じ感覚でアプリを導入したいなら、GitHubからgit cloneという方法も今では普通になりつつある。
また、最近のオープンソースに言えることは、「プルリクエストだけで開発が成り立つようになってきている」ということです。
gitを使えば、既存のリポジトリからgit cloneし、ローカルでファイルを編集し、自分のリポジトリを作った上で編集したコードを公開し、プルリクエストを行ってマージしてもらうだけで、簡単に開発ができます。
確かにメーリングリストでパッチを受け入れるプロジェクトは、まだまだたくさんありますが、時代は少しずつgitに移行してきています。
最初は既存リポジトリからcloneしてコピーをローカルに作るか、自分で作ったプロジェクトであればinitとaddでファイルを登録する。
基本的にファイル編集→コミット→リポジトリにプッシュ・リポジトリからプル→ファイル編集の流れを繰り返す。
さまざまな使えるコマンドがあるので知っておこう。
リポジトリのコピーを作る。
ファイルの変更を登録する。
コミットした内容でネットワーク上のリポジトリを更新する。
リポジトリの内容（他人や他のコンピュータが更新した内容）をローカルに反映する。
自分のリポジトリにプッシュした内容を他のリポジトリでもプルして反映するようにお願いを立てる。
gitを使う上で自分のリポジトリとして使うことができる無料のホスティングサービス。
GitHub Pagesという機能を使うことで静的HTMLを公開するホームページ公開サービスとしても使うことができる。