本投稿の閲覧が役に立ちそうな人
- プログラムもそんなにやったことがない人
- Shellとかコマンドプロンプトとかの知識がないけどGitがなんか使えるってことは聞いたからやってみたい人
- Gitの導入になんかそのすんごい苦戦している人
- ↑これらの人に教えようとしているけど、なんかその人がよくわからんところで詰まってて「いや、もう無理。〇〇のサイトみて自分で勉強して」って言いたくなってる人。
なお本記事では、Windows10・11環境でのGit導入について記載しております。
はじめに～本記事を書くにあたって～
どうも、ゲーム制作サークルのマホウビンのビンボーです。
最近めちゃくちゃ寒くて、駅の入り口につららができていたことに感動して写メ取ってたら遅刻しました。（幸い、どこかの誰かが線路立ち入りしてたので、遅延証明がでてくれました。）
天気予報とかで「見て！ 東京0℃！」とかいう声を聞くと、ちょっと布団から出るのに頑張らないといけないレベルで済んでる関西で育ってよかったなーと思います。
北海道・東北の人、ほんと尊敬する……。
さてこの度、新規でゲーム制作をするにあたって、メンバーのマギエル（通称マギたん）との会話で
一人で使ってるとプルリクエストとかしないから勉強にならんだろう。
あー、でもプライベートの共用リポジトリでええのか。
プルリクエストとか理解しているならいいけど。(善意)
みたいなノリになったのでGitHubを導入しようと考えておりました。
い、いや、知ってるんですよ、GitやGitHub。存在は。
ほらUnityやってるとアセットのダウンロードでGitHubのページ行ったり、Unityのオンラインマルチゲーム制作用のAPIことMLAPI（いまだとNETCODEか）の導入にGit使いますし……。
バージョン管理システムという認識で……あってるでしょ？？？
こんだけ使ってる人もいるし、みんな優しいからしっかりと説明してくれるページもあるし、なんなら公式リファレンスが充実してるっぽいから、まぁ、よ、余裕余裕ー。
と、思っていた自分がバカでした。
ええ、苦戦しました。
いや、苦戦したというか、「なにやったらいいの？」って状態で全くわかりませんでした。
最終導入までにかかった時間、なんと2時間30分。
「やったことない人ならいいんじゃね？」
的に思ってくれる人がいるかもしれませんが、私は仕事が社内SEなんですよね……。
相当へこみました。
が、これは、絶対他の人も苦しんでしまうはず！
というか私のような「マニュアル通りに実行しているつもりでなんかやっちゃう系Git初心者」を想定しているマニュアルが少ない！！！
そう思ったので、今回記事にしました。以上です。ご清聴ありがとうございました。
まず結論：Unityの開発環境をGitHubで管理するのに必要な作業。
色々専門用語がこの後出てきますが、専門用語を崩して説明すると……
①GitをPCにインストール。
②GitHubのアカウントを作成。
③GitHubでプロジェクトのページを作成する。
④PCのUnityプロジェクトのディレクトリ(フォルダのこと)にGitを使って「.git」という設定フォルダっぽいサムシングを作る。
（新規プロジェクトの場合は、先に⑤をやってから④やるほうがいいのかな？）
⑤GitHubのプロジェクトとPCのディレクトリをリモートまたはクローンさせる。
となります。
「Init」⇒「add」⇒「commit」⇒「remote」⇒「push」。
新規の時は、先にGitHubでプロジェクト作って「Clone」ね。
Gitの導入
①Gitとはなんぞや。GitHubとの違いってなに？
Gitとは「ソースコードのバージョンを管理するツール」またはそのコマンドのことである！！！
GitHubとは「Gitを利用した、開発者を支援するWebサービス」である！！！
と、下記引用サイトでそんな感じのことが書いてました！！！！（本項に関してはこんなくそ雑魚サイト見るよりも下記サイト見たほうがいいよ！！！ かなりわかりやすい。）
『システム開発では複数の開発者によってソースコードが書き換わります。いつ誰がどこを変えたのか？ 最新のバージョンはどれか？ など、ソースコードのバージョンを把握する必要があります。このバージョン管理をするツールの1つが「Git」です。』 (引用サイト： i3DESIGN Co.：https://www.i3design.jp/in-pocket/3111)
なるほど。GitHubがバージョン管理ツールかと思ってましたが、そもそもそこから間違ってましたね。
……あれ、じゃあ個人利用ならGitで終わりじゃない？ GitHubにすることでいいことあるの？ 教えてマギたん！！
クラウド管理だから、PCのロールバックの影響を受けない。
ソースでわからないところとかあったら人に聞きやすい。
あとソースだけじゃなくてデザインや文書管理にも使える。
名前が売れやすい。などなど。
ということらしいです。WebサービスなのでGitを管理するツールはたくさんあるようでした。
職場の人に聞いたところ、うちの職場でも「AzureDevOps」を使っているようです。なんでもGitHubと違って「AzureはAD認証での利用ができ会社管理で利用しやすいので、そのプロジェクトの管理者が蒸発したとかあっても割と簡単に対応できる」とのことでした。色々あるんですねー。
……あれ、使ってたなら誰かGitの使い方教えてくれてもよいのではなかろうか。え、もしかして私、ハブ(ry
②Gitの導入
GitやGitHubとはなんぞや、色々あるんだなーということが前回で大雑把にわかったので、早速利用を開始してみよう。
まずは大元のGit（ソース管理ツール）の導入から。
ダウンロードが終わったので、早速インストールを開始！！
英語かー。まぁ仕事でSEやってる以上、ある程度の英語はなんとかなりますけど、ちょっと日本人には敷居が高いっすー。
色んなサイト見ても教え方バラバラなのと、インストーラーのバージョンや現環境によって内容違うみたいなので、とりあえず「Git2.35.1.2Setup」の内容をご案内。
補足：一応ざっと内容案内しますと、「GitのGNUGPL(GNUのプロジェクトで開発されたソフトウェアライセンス)は内容の改変・共有OKで、ソフトウェアのコピーを配布する/ダウンロードするのは自由だよ。ただ配布した際の貴方の権利は有料だろうが無料だろうが配布した相手にも権利が付与されるよー。要はこのソフトウェアには保証というものがないよー」というものです。
基本そのままで「NEXT」
※初めにチェックがついてるやつは外さない。特に「GitBashHere」は絶対いるので注意。
デスクトップにアイコンを追加したい場合は「Additional icons」下の「On the Desktop」を選択しておく。
それ以外はそのまま「Next」でOK。
ここまではなんとなくわかる。問題はここから。
Linuxとかを触ったことある人は使ったことあるとは思いますが、確かにちょっと使いづらいです。特にUnityで作業する方は別のにしたほうがいいかもしれませんね。さて……
……いっぱいあるなー。
まぁUnity使っている人なら「VisualStudio」か「VisualStudioCode」を利用していると思いますので「Use Visual Studio Code as Git's default editor」を選択しましょう。
って選んだら、なんかでてきましたよ。
とりあえず別に困るところがないので、VSCodeのまま「NEXT」を押しました。
補足：Gitのインストール前にVisualStudioCodeのインストール・アップデートをしておきましょう。
リポジトリ……？ ブランチ……？ え、何それ。
いや待てよ、リポジトリってどこかで聞いたような……。
あああああ－－－！「はじめに」で言ってたやつうううう！！！！
リポジトリを調べたら「開発プロジェクトに関連するデータの貯蔵庫」的なものらしい。
……でもブランチってなに？ え、何？ 教えてマギえもん。
例えば「サイトの運営」プロジェクトにて「①広告機能」「②Youtube動画の表示編集」「③サイドバー編集」「④バグ対応」という作業があった場合、Gitでは「どこで何をやったか」っていう作業履歴をそれぞれ別々に名前を付けて管理することができるんだ。これが「ブランチ」。
ここで聞かれてるのは、一番初め「マスターブランチ」っていうプロジェクトの本筋につける名前をどうするかということ。
Git上でリポジトリを作るときに「git init」っていうコマンドを作るんだけど、それで設定されるマスターブランチ名を設定してねって言ってるんだ。
さすがマギえもんだぜ。
ということは、さっきの画面ではこういうことを言っているんだな。
「Let Git decide」を選ぶと、とりあえず新しいリポジトリ作成した時は「master」ってブランチ名にするけど（その内変えるかもだけど）。
「Override the default branch name for new repositories(デフォルトのブランチ名を書き換える)」で、別の名前にすることもできっけど。どうする？
ああ、読める！読めるぞ！！（byムスカ）
でもさっきも出てたけど、「git init」ってのがこういうコマンドだっていうのを知らないと……っていうか、Gitのシステム知らないとココ突破できなくない！？
補足：「git init」コマンドは、Git上でリポジトリを作成する際に実行するコマンドです。Gitでこのコマンドを打つと、そのディレクトリに「.git」というリポジトリ設定フォルダができます。設定フォルダはGitHubとのリモートなどに利用するのでかなり大事なコマンドです。別関連記事でまた出てきますが、軽く覚えておくとよいかもしれません。
ということで、とりあえず「Let Git decide」で進めることにしました。
Git使うときはGitBashしか使わん！っていうなら、上の「Use Git from Git Bash only」でいいけど。
ということで、「Git from the command line and also from 3rd-party software.」を選択。後で気付いたけど、大体Powershellでやっちゃってる人間なので、これは自分には必須だった。Powershellやサードパーティー製のコマンドラインツールを使わない人は上の「Use Git from Git Bash only」でいいと思います。この記事内では、GitBashしか使いませんのでご安心を。
独自で設定している外部OpenSSHがある人は下を。「なんじゃそりゃ」っていう人は上を選ぼう。
ここ、新しくなっているせいかなかなか最新の説明ページがなくて少し焦りました。
幸いSSHについては仕事である程度どういうものか理解していたので、スルー出来ました。
【コラム：OpenSSHって何？ そもそもSSHって？】 SSHとは、サーバーとの間でやり取りをする際に使われる「暗号化された通信方式」のことで、私たちがGitHubなどのクラウドサーバーとの通信でやり取りを暗号化することで安全に利用することができます。GitHubに接続するときにサインインパスとか隠さずに送るのは危ないので、これを利用します。 OpenSSHとは、そのSSH.exeのオープンソースのことです。 ちなみに、Webページにアクセスするときに使うSSLとは似て非なる物です。
GitHubを利用するのであれば上で大丈夫です。会社でUnityをチームで作ってます！っていう人で、会社がリポジトリサーバを運用していて、AD認証を推奨しているようであれば下を選びましょう。
実はここ結構大事な項目です。ただ大抵の人は上になるかと思います。
何をいっているのか、というと……
上はGitのOpenSSHに入ってる「ca-bundle.crt」っていう証明書ファイル使うんだけど、もし使ってるPCが会社利用でActiveDirectoryに入ってる場合だと、たぶんプロジェクト管理で別のルート証明書ファイルあるかもしんないのよね。
一回システム管理者に聞いてみて、使ってるなら下選んで。
とのこと。
「いや、Gitがどういうものか現段階で大雑把でしかわかってないのに、こんな質問されても……。」とは思いますが、これGit単体でみるとかなり大事なポイントだったりします。
まぁGitHubの場合はほぼ上なので、気にしなくてもいいと言われればそうなんですが、あまりにもあっさり流してるサイトが多いので一応念のため。（今回も上を選んでNextしてます）
これもWindowsなら上でいいと思います。
……ん？？？ チェックアウトってなに？ また新用語？？
あ、あった。「Checkout：ターゲット エンティティの異なるバージョン間の切り替え」？？？
・WindowsOSはCRLF（「\r\n」=行の一番左に行って、改行する）方式
・Macの古いOSはCR（「\r」=行の一番左に移動するだけ）方式
・他のUNIXはLF（「\n」=下方向に移動するだけ）方式
だったよね？ 端末ごとに変換してくれるってことかな？
具体的にどういうことしてくれるんだい、Git君。
それを変換する機能がここで言ってるやつなんすわ。
俺はWindowsやねんけどどれ選んだらいいの？
これらの設定は「core.autocrlf」の値かえたら変更できるから「なんかおかしいな」思ったら後でここの数値かえてやー。
補足：具体的にいうと、上を選ぶとチェックアウト時に改行がLF方式(UNIX方式)の時はCRLF方式(Windows方式)に変換し、また入れる時にLF方式(UNIX方式)に戻します。真ん中を選ぶとチェックアウト時に改行がCRLF方式(Windows方式)の時はLF方式(UNIX方式)に変換して、再度入れる時はCRLF方式(Windows方式)に戻します。下を選ぶと何もしません。
上を選ぶのが無難ではあるが、「MinTTY上でWindows用dockerなどのWindowsコンソールコマンドを使う場合、頭に『winpty』と付ける必要がある」ことを留意しておこう。
……そろそろ読むのが面倒になってきた。
今度は何だろう？ TTY？ テレタイプライター(ほかの端末と通信するタイプライター)のことだっけ。
たしかにPowerShellとかでVIMエディタ動かしてる時に画面サイズ変更すると落ちることあるけど……。
ということで、今回は「MinTTY」を選択します。
基本的には、デフォルトでOK
デフォだと「pullできる時は今のbranch状況をfetchしたbranchにfast-forward Margeして、できない時はMarge commitする」になってるけど。
「fetchしたbranchにrebaseする」設定もできるし、「fetchしたbranchへのfast-forward Margeだけ試す」設定にもできるよ。
まだ知識が追い付いてないのに、詰んだわ……。
で、プルした際に「fetchしたブランチ（マスターからの枝分かれしてる最新の履歴データ）でコミットされてるのがあると、これがマスターブランチの最新版から繋がっているデータかどうか判別して、もしそうだったらそのままMarge(マスターブランチに統合すること)して使い、もし違ったら現状を全てコミットしてマージする」っていうのがデフォルトの設定なんだ。
マスターよりも最新の履歴があったら常に最新バージョンを取ってくるってこと？
問題はその取り方の違い。
まぁ大体の企業がデフォルトの設定でやってるし、デフォルトでいいと思うよ。
ということで「Default」設定で。
補足：「git pull」コマンドはGitHubのプロジェクト管理ではよく利用するコマンドです。GitHubに置いているプロジェクトから自分のGit内に置いているプロジェクトの状態を更新するコマンドで、誰かが更新した内容を取得する時などで利用します。
上を選ぶとGitの資格情報マネージャーを利用してGitHubなどへの接続方法を記録することができます。ブラウザのパスワード記憶みたいなものですね。
A.「Enable file system caching.」ファイルシステムのキャッシュを有効
B.「Enable symbolic Links.」シンボリックリンク（特定のファイル・ディレクトリへの参照を別ファイルを使ってリンクする方法）
とりあえずデフォルトでOK。Bのシンボリックリンクは便利なのですが、設定内容が多いので無しで。
正直、ここはバグがあったりするとめんどくさいので、チェックを外すことに。
……うん、そろそろいってもいいよね。
なっが！！！！
察している方もおられたかと思いますが、ええ、ここまで超調べました。
「わけのわからないものをPCに入れたくない」という心情があり、頑張って調べておりましたがまぁ内容がややこしいですし公式のドキュメントはインストールをさっと流すし、でかなり心配になりながらインストールしてましたよ。
Nextを押すたびに「なんか厄介なマルウェア的なソフト入ったらどうしよう」と思いながら進めること既に1時間が経過しております。
が、ついにきました！！「Install」の文字！！！
うおおおおおお、とうとう俺もGitが使えるんだ――――！！！！
「GitHubあれこれ | 初心者がUnity管理にGit Hubを導入しようとしてかなり苦戦する話②～Gitとはなんぞや～」に続く。
