なんかエンジニアのひとたちがよく口にしているGitとかいうやつをこっそり覚える記事
■概要
なんかエンジニア（プログラマー）と交流したり、共同制作することになったり、あるいはエンジニア同士の会話を聞いていたりすると、よく出てくる単語がありますよね。
Gitとかいうやつ。
なんか共同制作するときに使うと便利なシステムらしい。
でも慣れるまでチョット難しいらしい。
じゃあGitってなんやろってｇｇると、まあ解説しているサイトはいっぱいヒットするものの（侍エンジニアとかいう所は絶対に参考にしてはいけません） 、ちょっとエンジニア向けっぽい専門用語が多くて取っつきづらい。
というエンジニアじゃない人向けに、Gitがどういうものなのか、できるだけわかりやすく解説したい記事です。でも識者の人から見ても間違いが書かれている侍のような記事にはしていないつもりです。
（Gitの解説記事自体はネット上にいっぱいありますが、どれもエンジニア向けっぽい書かれ方をしているので、それ以外の職種向けのGit記事とかおもしろいんじゃないかなあみたいな動機とかそんな感じかもしれない
◆この記事の対象
Gitというのが気にはなっているけどよくは知らない人向け、あるいは知り合いにそういう人がいる人が勧める記事、を目指しています。
なお、エンジニアがそれ以外の人にGitを押し付けるための記事ではありません。強要駄目、ゼッタイ。
◆この記事の解説範囲
あくまで、Gitというのがどういう意図で使われていて、どういうものなのかを極力わかりやすく、そして理解することが当記事の目的です。
なので具体的な導入法や運用法にはそこまで触れていません。解説しているサイトや書籍は山ほどあるので、この記事を読んで概要を理解した後でそれらを調べていけばよいと思います。侍以外で
■で、Gitとは？
Gitとは、バージョン管理システムの一種です。令和の今、最も使われているバージョン管理システムと言い換えることもできます。
いきなり専門用語が出てきているじゃねえか。まあまあ落ち着いてくれ。バージョン管理システムが何なのかもこのすぐ後に説明します。
↓一応wikipediaです。概要の上半分くらいはなんとなくわかるとおもう。
バージョン管理システムは（↑のwikipediaの解説を信じるならば）1962年には既にその原型が誕生している歴史あるシステムです。そしてコンピュータの歴史とともに、より洗練したシステムに進化を遂げています。
先述した通り、Gitは圧倒的なシェア率（2023年現在）を誇るバージョン管理システムです。現代においてバージョン管理システムを使う場合、よっぽどの拘りがない限りはGitを採用して良いでしょう。
まとめると
・Gitはバージョン管理システムのひとつ
・バージョン管理システムの種類はコンピュータ史においていっぱいある
・令和の今、バージョン管理システムを使う場合基本Gitでヨシ！
という感じです。
■じゃあ、バージョン管理システムってなによ
で、じゃあバージョン管理システムって一体なにものなのか。
先ほど挙げたwikipediaにもある通り、そしてその名前から推測できる通り、
「（大量の）ファイルをバージョン別に管理できるシステム」です。
平たく言うと「なんかいい感じにファイルをセーブできるシステム」です。
例えばイラストを描く場合、（一般的には）イラストデータはひとつのpsdファイルに格納されているため、このpsdファイルを適度にコピーしたりどこかのサーバーにアップロードすればそれでバックアップは完了します。しかし、これがゲームプロジェクトの場合、そのプロジェクトのフォルダの中には大量のソースコード・画像・音声データなどが格納されています。それは何百も。何千も。大規模なプロジェクトならそれこそ何万も。フォルダ容量もギガバイト単位になることもおかしくはないでしょう。
この大量のファイルを一つ一つ手作業でバックアップを取ることは現実的ではありません。かといって、数GBに膨れ上がったプロジェクトフォルダを、毎回丸ごとバックアップを取るのもそれも現実的ではありません。
バージョン管理システムは、この大量のファイルを「なんかいいかんじに」管理してくれるシステムです。
具体的には、任意のタイミングで、任意に選択されたファイル群をサーバー（厳密にはサーバーとは限らないのですがそれはまあ後で）に送信することで、プロジェクト全体の状態を「バージョン」として記録することができます。なんかゲームでセーブする感じです。このバージョン管理システムで記録するところを「リポジトリ」と呼びます。専門用語でちゃった。
どのタイミングでどのファイルが追加・更新・削除されたかをシステムが記録することで、「特定の日時の状態」を自由に確認したり、復元することも可能となります。ロードですね。また、各タイミングでの変更があった時のみ、そのファイルを保存するため、巨大なプロジェクトであっても大量のバックアップを要する必要なく、効率的に保存することができます。
（※ちなみにGitはスナップショット形式なので差分を記録してるわけではないのですが、ここを真面目に説明するとこの記事の範疇を超えるので割愛）
また、このサーバー上のリポジトリは複数人で管理することができます。
なので、他の人が反映した変更を共有することもできるわけですね。
一連の流れを図にするとこんなイメージになります。
（ところでこのイメージはどちらかといえばsvnなどの差分形式のイメージ図で、スナップショット形式のGitのイメージ図としては正確ではないのですが、スナップショットを正確にイメージ図にすることは困難を窮めるので差分形式のイメージ図で押し通しますゆるちて）
このシステムは、wikiの構造にどことなく似ています。wikiも各ページごとに保存出来て、かつ任意の状態を確認出来たり、その状態に差し戻したりすることができます。バージョン管理システムの場合、さらにwiki全体の「特定の日時」の状態を確認出来たりするわけです。
このように、「大量のファイルが含まれるプロジェクトフォルダを効率的に管理（バックアップ）することができる」というのがバージョン管理システムの役割です。
※ところで逆に言うと、リポジトリにセーブ（push）してしまったファイルは、たとえその直後に削除してもバージョン管理システム上は残ってしまいます（そのバージョンの状態にすればだれでも見れる）。あなたが間違えて×××な画像を上げてしまって慌てて消しても、そのファイルを上げたという事実がバージョン管理システムには永遠に刻まれます。
一度（リポジトリに）生まれたものは そう簡単には死なない。
まとめー。
バージョン管理システムは
・任意のタイミングで任意の（複数の）ファイルを記録できる
・バージョンとして状態を記録し、復元も可能
・そして複数人で状態を共有することができる
■Gitの利点
利点、というよりかは……プロジェクトが長期になる・大規模化するにつれ、Gitでプロジェクトを管理することはほぼ必然化します。
小規模なプロジェクトで、ゲームプロダクトそのものを管理するのがエンジニア一人の場合、各種リソースをGoogle Driveでやりとりする、でも十分共有は可能です。しかし大規模な開発になり、エンジニアが複数人、あるいはデザイナーも（例えばunityプロダクトの場合に）unityプロジェクトそのものに手を加えるような状態になった場合、（先述したようにゲームプロダクトは何千ものファイルを内包することも珍しくないので）これをGoogle Driveなどで各種ファイルを共有する、というのは無理があることは自明です。
◆Gitの難点
慣れてない人は最初は戸惑う。これに尽きる。
（わざわざこんな記事を書くくらいには）非エンジニアにとっては最初は面食らってもおかしくないシステムで、一朝一夕に覚えられるものではありません。先述したように、小規模・短期間のプロジェクトならぶっちゃけGoogle Driveの共有や、なんならDiscordで直にファイルアップロードで十分リソースのやりとりは完遂可能です。Gitを導入するかはチーム内で最初に相談して決めるのが良いと思います。間違っても、Git環境の導入を第三者に強要してはいけないと思います。（ここでいうのもあれですが、エンジニアがGit環境を無理強いした結果、デザイナーが混乱してしまった状況を見たことがあるので……） エンジニアのエゴでしかない。
※いやもちろん仕事とかなら業務として覚えてもらいたいですけど……
・プロダクトが長期・大規模化するにつれシステムの導入は必至
・逆に小規模なら導入しなくてもどうとでもなる
・慣れるまでは少し時間がかかるし他者に無理強いはヨクナイ
■Git、GitHub、Gitクライアントとは
エンジニアがGitを口にするとき、GitHubやらGitクライアントやらもよく口にします。これらがそれぞれ何を表しているか説明します。
◆Git
再三説明している通り、バージョン管理システムを指します。
システムそのものを指すことに留意するとよいです。
◆GitHub
ここまでのGitの説明を読んだ方ならわかると思いますが、Gitを利用する場合、（基本的な使い方の場合）サーバーが必要となります。GitHubはそのサーバーを提供するプラットフォームです。GitHubを利用することで、我々はサーバー環境を自力で構築する必要なく、Gitを利用できるようになるわけです。つまり、GitHubはGitを利用するサービスですが、GitがGitHubが必要なわけではありません。自前でGit用のサーバ環境を構築することもできるわけです。
◆Gitクライアント
Gitはシステムです。つまりCUIです。その気になれば、Gitをそのまま使うことはできます。
一部のギークなエンジニア以外はこの画面に拒否反応を示すといわれています。一部のギークは涎をたらしますがそいつらは変人なのでほっとけ。
というわけで、我々一般人でもわかりやすくGitを使えるようにするために、多数のGUIツールが作られており、それらをGitクライアントと呼びます。
じゃあどのGitクライアントがオススメかというと、GitHub Desktopをオススメします。その名が示す通り、GitHub公式のGitクライアントです。
尚この記事を書いている中の人、評判が悪いSourceTreeを使っている模様
別に今のところ不便を感じてないしええかなって
・Gitはバージョン管理システムそのもの
・GitHubはそのGitの環境（リポジトリ）を提供するサイト
・GitクライアントはGitを誰でも扱えるようにするためのGUIツール
■Gitでどういうことをするのかのシミュレーション
を、ここに図入りで簡単にシミュレートしようと思います。
デザイナーがエンジニアのリードのもと運用する状況を仮定しています。
◆Gitでチームとデータを共有するまで
エンジニア主導で行う場合、まずエンジニアがGitHubにリモートリポジトリを作成すると思います。そして多くの場合private（パブリックに公開しないリポジトリ）で作ると思われるので、招待を受けることになると思います。
ここで図が出てきます。Gitの作業においては「ワークフロー」
「インデックス」「ローカルリポジトリ」「リモートリポジトリ」の
4つを意識して作業することになります。
ワークフロー：いつもの自分のPCのファイル
インデックス：自分の作業をリポジトリに反映させる候補リスト。
（あくまで候補リストなので、ここにデータがあるわけではないです）
ローカルリポジトリ：ローカルのリポジトリ。
リモートリポジトリ：共有されるサーバー上のリポジトリ。
GitHubを使う場合はGitHubサーバーにあるリポジトリ。
リモートリポジトリにはエンジニアのZさんがあげた（プッシュした）
ゲームプロジェクトのソースコードが既にあるようです。
意識する必要はないかもしれません。目に見えるのはワークフローなので。
招待を受けた後、クローンを行います。クローンとは既存のリモートリポジトリをローカルに落とし込む最初の作業です。エンジニアがゲームプロジェクトをリポジトリに置いていた場合、この段階でローカルPCにもそのゲームプロジェクトが入ります。
これで最初の工程は完了です。
◆自分の作業した事をチームメンバーに共有する
ワークフローで作業を行います。っていうとそれっぽく聞こえますが、
ワークフロー＝いつものフォルダ なのでだいたいいつも通りの作業です。
psdファイルが出来上がりました。それをgitで共有しましょう。
まず共有したいデータをインデックスに追加します(アド・add）。
psdファイルがひとつならひとつ登録すればおわりです。
次にそれをローカルリポジトリに反映（コミット・Commit）します。
そしてそれをリモートリポジトリに反映（プッシュ・Push）することで
他の人が取得（プル・Pull）できる状態になります。
※この時（プッシュする時）に、コメントを付けられます。
他の人に何をしたか伝わるようにちゃんと説明をつけよう！
このようにGitでの共有は3ステップ必要ですが、最初のうちは（そして非エンジニアなら）この3ステップは機械的に、同時にやってしまっていいと思います。もちろん慣れれば適宜使い分けられるようになると思います。
◆チームメンバーの作業をローカルに反映する
では、あなたがプッシュしたpsdをほかの人が見る場合、あるいは
他の人がプッシュしたものをあなたが得たい場合はどうするか。
反映されます
まあプルというコマンドを実行するだけです。基本的には。
すると更新があったファイルを差し替えてくれます。
かんたん！
・最初にリポジトリに招待してもらってクローンする
・自分の作ったものをアド・コミット・プッシュして共有
・他の人の反映したものはプルで取得できる
※補足：超初心者向け安全Git運用法
本当に最初のうちは、リポジトリのトップにそれぞれの利用者のフォルダを作って、それぞれの利用者はその中でのみプッシュをしてもらう運用にすると、事故が起こりづらいです。
それGitを使う意味ある？ て聞かれたら ……＾＾； ではありますが、
Gitクライアントの操作にも慣れてない初心者がいるうちはこれくらいの運用の方が安全かもしれません。みんながGitに慣れてきたときに、初めて重なった領域でやりとりすればいい。
■Git環境の具体的な導入手順について
……は、ここでは説明しません！！ ここまで読んだ方なら、「Gitの導入」「GitHubのアカウント準備」「クライアント（GitHub Desktop）の導入」の3ステップが必要なことはわかると思います。それぞれの導入の仕方は、調べればいくらでもHITすると思うのでここでは特に説明しません！！ エンジニア以外が共同制作で導入する場合、リードしてくれるエンジニアがいる筈なので、分からないところや躓いたところが出た場合、そのエンジニアに聞いていけばよいと思います。あるいはエンジニアの人が最初にこのページを薦めてくれてもヨシ。
あ、ただし侍エンジニアという場所は参考にしないでください。案の定「Git 導入」で上位にHITしやがる
■なぜ侍エンジニアが××なのか
こんな見出し書きたくなかったわ。
でもこの記事書いてる途中でｇｇったら何回もヒットするんだもん。
一言でいえば、アフィブログのプログラミング版みたいな所だからです。組織としてロクに内容のチェックを通さず記事を粗製乱造しているようで、その記事内容には間違いが含まれていることが極めて多いです。
なまじ初学者から見てそれっぽく見える内容が多い（そのため間違った内容であることが当事者にわからない）ことが猶更タチが悪く、結果として様々な内容を間違えて覚えてしまっていた、という例が後を絶ちません。その一方でアフィブログの如く、SEO対策などをしっかり施し、検索で上位に来るようにすることには全力を注ぐタイプ（そしてその努力が実り、ちゃんと上位に来る××っぷりを発揮）です。
なんで業界からは基本的に鼻つまみ者扱いされているサイトですし、
こういった場所で「侍は参考にするな」と啓蒙されているわけです。
どのジャンルにおいても「良いコンテンツにする」のではなく、
「よく見えるコンテンツにする」事に全力を注ぐ輩はいるものですね……。
■まとめ
さあこの記事を読んでGitがだいたいどんなものか理解できたでしょうか？
こっそりGitを覚えて「Gitつかえますよ～」とエンジニアに言って
エンジニアに（こやつ、できる……！）と思わせてやりましょう！
ここで説明したのは、Gitの本当に最初の内容です。
しかしここまで読めば最低限の知識は身についたはずなので、
（より専門的に書かれた）ほかの場所のGitを説明したサイトも
読めるようになっていると思います。そのはずだ。侍以外で。
この記事は侍のネガキャンをする記事ではない筈なのだが……。
◆定型句
当記事がいい！とおもったら
スキ！やシェアとかフォローなど、お願いいたします！！
◆謝辞
当記事はUGDGの皆さんの協力によって執筆されました。
この場を借りて感謝申し上げます。ほとんど素通しだったけど！！
↑UGDGについての記事はこちら。
UGDGよいとこいちどはおいで。
この記事が気に入ったらサポートをしてみませんか？