【追記】
この記事を簡潔にまとめたバージョンを作ったのですが、そちらの方がわかりやすくまとまっている記事になってしまったので、GitHubを学ぶ目的であればこちらより新しく書いた記事の方を参考にした方がいいと思います。
新しいバージョンの記事はこちら![]()
はじめに
こんにちは。
今回は、GitHub Desktopを使ったUnityの共同開発をClaudeを使って学んだので、その学んだことをまとめて、
- 共同開発でGitHubを使ってみたい
- GitHubに触れてみたい
と思う人向けに記事を書きました。
また、今回の記事はあくまで「初心者向け」かつ「触れる」ことに重点を置いているので、
- 本格的な運用を学びたい
- GitHubについてちゃんと学びたい
- 既にGitHubを使った経験がある
という人には向いていない内容です。予めご了承ください。
また、かなりの長文になってしまいました。(教材として作成したので長いです)
後々内容を分割して、今回のこの記事はそれらのまとめ記事として出すかもしれません。
今回使用した環境
- Windows 11(25H2)
- GitHub Desktop
- Git LFS(Git Large File Storage)
- Unity Hub & Unity Editor(6000.3.11f1)
そもそも「Git」「GitHub」とは?
一応前提としてClaudeに解説してもらいました。
Git はソースコードの変更履歴を管理するツールです。「いつ・誰が・何を変更したか」を記録でき、過去の状態に戻したり、複数人で並行して開発したりすることができます。
GitHub はGitの仕組みを使ったクラウドサービスです。コードをオンラインで保存・共有でき、チームでの共同開発やオープンソースプロジェクトのホスティングに広く使われています。
一言で言えば、Gitがバージョン管理の仕組み、GitHubがそれを使えるWebサービスです。
こんな感じで、Gitを使って管理できるサービスがGitHubとなっています。
準備
ということで、準備から説明します。
1.GitHubに登録
まずはGitHubのアカウントを作りましょう。
特に手順は載せませんが、指示通り作れば何も問題ない(はず)です。
(今回の記事を書く用に新規で登録してみましたが、特に問題なくできました。)
2.GitHub Desktopのインストール
次に、GitHub Desktopのインストールです。
「Download for Windows (64bit)」をクリックして、インストーラーを起動しましょう。
(Macでもほとんど同じ操作で行けると思います。)
GitHub Desktopが起動したら、GitHubのアカウントでログインしてください。
(ブラウザの方でログインする感じになります)
ログインの後の指示がよくわからない人はこちら
ログイン後、GitHubとGitHub Desktopを紐づけをするかの確認が出てくると思うので、緑色の許可ボタンを押して完了です。
「関連付けられたアプリを起動しますか?」のような表示がブラウザの上側から出てきたら、「開く」か「許可」みたいなボタンを押しましょう。
(詳しく覚えていませんがそんな感じだった気がします。)
ここまでが必須ですが、次に入れるのはUnityのプロジェクトデータなどの、大容量のファイルを扱いたい人向けです。必要ないと思う方は、次のステップに飛ばして構いませんが、個人的には入れておくことをお勧めします。
3.Git LFS(Git Large File Storage)のインストール
まず、大前提としてこれは何なのかを説明します。
GitHubは使用上、1つで100MBを超えるファイルをアップロードすることはできません。
そのため、大容量のファイルを扱う開発の場合は、この「Git LFS」というツールを使って、数GB単位のファイルもアップロードできるようにしなければならないのです。
100MBを超えるファイルはそのままでだとアップロードできない
Git LFSがあれば大容量ファイルもアップロード可能
ということでインストールしましょう。
インストールにはGitが必要なのでGitをインストールしていきます。
(途中でGit LFSもついでにインストールできます)
Standalone Installerの「Git for Windows/x64 Setup」を押してインストーラーをダウンロードします。arm系CPUの場合はその下の「ARM64 Setup」をクリックしましょう。
Mac OSの人はインストール手順がかなり異なってきます。
GitやGit LFSのページに書いてあるインストール手順や、ほかの方が解説してくれている記事を参考に進めてほしいです。(今回はWindowsの手順のみを載せます)
では、インストーラーを起動してインストールしましょう。
基本的にこだわりがなければ「Next」を押していけばいいのですが、何点か重要な点があるので確認してほしいです。
1.Git LFSにチェックを入れる
3つ目の画面で「Git LFS」にチェックが入っているかを確認してください。
2.VS Codeをデフォルトのエディタにする
これはVS Codeを使っている人はぜひしてほしい設定なのですが、デフォルトのエディタをVS Codeにした方がいいと思います。(「Vim」というのが初期値ですが癖があって後から面倒になるそうです。)
VS Codeをまだインストールしていない場合は「Next」が押せないと思います。
この設定をしたい場合はVS Codeをインストールしてからしましょう。
実際に触ろう!!!
ということで長かったかもですが、実際に触っていきましょう!
1.リポジトリの作成
まずは「リポジトリの作成」を行います。
「リポジトリ」とは?
データすべてをまとめて置く場所みたいな感じです。
Gitの特性上、単なるファイルの保存や共有だけでなく、
- いつ
- 誰が
- 何を変えたのか
という情報も記録されます。それらを保存するためのものという感じですね。
GitHub DesktopとGitHubのWebページのどちらからでも作成できますが、今回は操作の説明のためGitHubのWebページ上で作成したいと思います。
ということでGitHubのページにアクセスします
では、この画面の左上「Create repository」をクリックしましょう。
2つ目以降は、「New」というボタンに変わりますが、手順は同じになります。
ここでは、上から順に
- Repository name/Description
リポジトリ名/リポジトリの説明を設定
- Choose visibility
アクセス範囲(「Public(公開)」「Private(非公開)」を選択
- Add README
説明文を追加するか(ONを推奨します)
- Add .gitignore
含めないファイルを指定する設定ファイル(下で説明)
- Add license
ライセンスの設定(下で説明)
の5つを主に設定します。
特に、「Add .gitignore」と「Add license」の2つについて解説します。
.gitignoreとは
「含めないファイルを指定する設定ファイル」です。
GitHub側である程度のテンプレートが用意されており、自分の使う環境に合ったテンプレートを選択するだけで、不要なファイルと必要なファイルを自動で選別してくれます。
自分はUnityを使って共同制作したいので、「Unity」を選択したいと思います。
Licenseとは
「利用についてのルールとかを書いたりするもの」です。
これがないと、このリポジトリを見たときに好き勝手に使っていいのかわからないっていう問題が発生するので、それを回避するために、ちゃんと著作者や利用するルールを書いたファイルを作ろうといった感じです。
何もこだわりがなければ、「MIT License」がおすすめです。
これは、「著作者を明記すれば、コードは自由に使っていいよ。でも、動作の保証は一切しないよ。」という感じのライセンスです。(詳しくは調べてください)
2.リポジトリのクローン
これでやっとリポジトリができましたが、編集したり作業ができるわけではありません。
そこで、「自分の端末」と「GitHub」のリポジトリを同期させる作業を行います。
まずは、「GitHub Desktop」を開いてください。
画像がないのですが、最初に「Clone repository」という表示があったと思うので、そこを押しましょう。
そうすることで、クローンするリポジトを選ぶ画面が出てきます。

ここでは、
自分の端末にクローンしたいリポジトリ
クローンしたリポジトリを自分の端末のどこに保存するか
を設定します。
クローンしたいリポジトリの選択
まず、ここで自分の端末にクローンしたいリポジトリを選択します。
保存場所の設定
次に、その下側にある「Local path」の設定で、「自分の端末のどこにクローンしたファイルを保存するか」を設定します。
画像は例なので、この文字をそのままコピーすると変なところに保存されます
自分のわかりやすい場所へ保存しましょう
すべてできたら、「Clone」というボタンを押しましょう。
これで、指定した場所にリポジトリがクローンされたと思います!
3.Git LFSの設定(最初だけ)
この項目は、Unityを使う方、もしくはGit LFSを使う方向けの説明になります。
Git LFSのインストールも必須なので、忘れずにインストールしましょう。
ここからは、Git LFSの設定をして、GitHub DesktopがGit LFSを使ってくれるように設定していきます。
1.Unityのプロジェクトデータ作成
Unityを使わない場合は、手順2へ進んでください。
まず、Unityを使う人は、プロジェクトを先ほどクローンしたリポジトリに作成しましょう。
(作成されている場合はこの手順をスキップしてください)
プロジェクトの設定はお任せしますが、作成場所は必ずクローンしたリポジトリのフォルダに作りましょう。
「保存場所」の項目をクリックし、クローンしたリポジトリのフォルダを選択します。
プロジェクトが新規作成され、Unity Editorの画面が出てきたら、いったんEditorを閉じましょう。
その後、エクスプローラーで、「.gitignore」ファイルを、プロジェクトのあるフォルダに移し替えます。
2.「Git LFS(.gitattributes)」の設定
他の人がこの手順を行ってくれていた場合でも、Step2までは必ず行わないといけません。
次に、GitHub DesktopでGit LFSを使ってもらうための設定用ファイルを配置します。
その設定用ファイルを「.gitattributes」っていいます。
「あれ?さっきも似たようなものが...」
となった人は、記憶力がいいですね(?)
ここでの注意は、「.gitignore」と「.gitattributes」を混在して覚えないようにすることかなと思います。
「.gitignore」
除外するファイルの設定「.gitattributes」
Git LFSを使ってもらうファイルの設定
です。覚えておきましょう。
ということで、説明していきます。
Step1.リポジトリのフォルダでcmdを起動
まずはエクスプローラーでリポジトリを保存したファイルを開きましょう。
先ほどの項目で「.gitignore」を移動させたのでこうなっています
(Mac OSだとここの手順は異なります。詳しくは調べてください。)
この画像の上側にある「ドキュメント」や「(クローンしたリポジトリのフォルダ名)」が書いてある部分(アドレスバー)をクリックし、下の画像のように「cmd」と入れて、Enterキーを押してみてください。
すると以下のような文字が出てくる画面が出ると思います。
(クローンしたリポジトリの保存場所)>
この時点でクローンしたリポジトリの場所が指定できてない場合、もう一度エクスプローラーから「cmd」と入力して起動させてください
例として出しますが、「TestRepository」という名前のリポジトリを「C:\Users\username\Documents\TestRepository」にクローンした場合、
cmdC:\Users\username\Documents\TestRepository>のような感じになっていればOKです。
cmdC:\Windows\System32>のように、クローンしたリポジトリのある場所が指定できていない場合は、もう一度やり直してください。
ここにコマンドを打ち込んでいきます。
Step2.Git LFSの初期化
git lfs install
と入力し、Enterを押して実行します。
ここから先は、誰かがすでに1度行っている(リポジトリに「.gitattributes」が既にある)場合、Step3とStep4は設定不要です。
ただし、「.gitattributes」を編集したい場合は続けてください。
Step3.管理するファイル形式を指定
次に、Git LFSで管理してほしいファイル形式の設定を行います。
例えば、「MP4」と「PNG」形式のファイルを指定する場合、
git lfs track "*.png" "*.mp4"
のように入力して、実行しましょう。
こうすることで、「MP4」と「PNG」形式のファイルを管理するように指定できました。
今回Unityを使っている人は、以下のコマンドをコピーしてそのまま張り付けると、ある程度の大容量ファイルに対応してくれます。「.vrm」など、他に追加したいものがある場合は、このコードに先ほどのように付け足してください。
cmdgit lfs track "*.png" "*.jpg" "*.psd" "*.fbx" "*.mp3" "*.wav" "*.mp4" "*.unitypackage"
Step4.追加&Commit
最後に、
git add .gitattributes
git commit -m "Add Git LFS tracking"
と入力して、実行しましょう!
最初のコマンドで、Step3で指定したファイルをGit LFSで管理してくれるようになる設定を書いた「.gitattributes」というファイルを新規作成しています。
次のコマンドはCommitという操作をしています。(詳しくは次で説明します。)
4.「Commit」と「Push」
次に、編集したデータをGitHubにアップロードして反映させていきます。
そこで登場するのが、「Commit」と「Push」です。
まずはCommitから
「Commit」は、日記のようなもので、変更した記録を自分のPCに保存します。
基本的には、きりがいいところで「何をしたか」を簡単にまとめておきましょう。例えば、
- バグ修正
- 機能追加
など、1つの作業を終わらせる毎に行うといい感じに管理・運用できます。
では、実際にやってみましょう。
Unityのプロジェクトを作成した人は、「GitHub Desktop」を再度開くと、こんな感じで何か表示が変わっていると思います。
ここに出されているのが、変更のあったファイルになります。
こういう変更があった部分を「差分」と呼びますが、めっちゃ大事な知識ではないので軽く覚えておきましょう。
そして、この画面の左下にあるところが「Commit」をする部分です。
「Summary」には、簡単なまとめを、
「Description」には、詳細な説明を残しておきましょう。
では、青色の「Commit」のボタンを押しましょう!
いっぱい出ていた表示が消えていれば完了です!
次にPush!
次に、Commitした記録をGitHubへアップロードしましょう!
そこで使うのが、「Push」です!
Pushとは
簡単に説明すると、編集したデータを送り込む感じの動作のことです。
Gitではそれなりに出てくる用語なので知っておきましょう!
さて、実際にPushしましょう!
Commitした後、上側をよく見ると、一番右側に「Push origin」と出ています。
これを押します!すると...
「Fetch origin」に表示が切り替わりました!これで完了です!
「Fetch origin」はGitHubの最新情報を確認する機能です。
Push後はこの表示に切り替わります。
5.ブランチ
次に、ブランチという概念について説明します!
簡単に言えば、枝分けしてそれをくっつけたりできるといった機能です。
言葉だと分かりにくい気がするので、図示しました。
こうするメリットは、いくつかあります。
例えば、
- コードを編集していたらデータを壊してしまった
- ファイルを統合したらエラーが発生してしまった
- データの復元に時間がかかってしまった
というような経験はないでしょうか?
しかし、Gitの「ブランチ」を図のように活用することで、「共有する本番環境」と「自分の開発環境」を分離することができます!
そうすることで、
- 自分のデータを壊しても、本番の環境に影響が出ない
- エラーの発生を事前に確認できる(「7.Pull Request」を見てください)
- すぐに復元できる
など、安全に大人数で開発できるというメリットがブランチの強みです。
また、あるブランチから分岐させることを「ブランチを切る」といい、あるブランチをもう一つのブランチに合体させることを「マージ」といいます。
これだけじゃわかりにくいと思うので、イメージとしては、
ブランチを切る
「共有するデータのブランチ」を分岐させて、「自分の作業用のブランチ」を作る。マージ
「自分の作業用のブランチ」を「共有するデータのブランチ」へ合体する。
というような感じで操作をしていきます。
基本的には、「ブランチを切ってマージする」の繰り返しをしていく感じになっています。
なので、開発する際は必ず「共有する環境」を直接編集するのではなく、ブランチを切って、そのブランチを編集するという感じになります。編集が終わったら、それを「共有する環境」に統合します。
6.ブランチを切る
では、実際にブランチを切ってみましょう。
「GitHub Desktop」の上のバーの真ん中にある「Current Branch」を押しましょう。
クリックすると、このような感じで現在のリポジトリにあるブランチ一覧が出てきます。
mainのみしかないので、右上の「New Branch」というボタンを押して、mainブランチを切ってみましょう!
そうすると、上のバーの右上に「Publish branch」と出てくるので、それを押しましょう!
こうすることで、切ったブランチをGitHubにアップロードすることができました!
7.「Pull Request」と「Merge」
いよいよマージをしてみましょう。
まず、ブランチが先ほど切ったブランチになっているかを確認し、リポジトリ内のファイルを編集します。(テスト程度なら何かファイルを新規作成したりしてみてください)
編集し終わったら、保存して「GitHub Desktop」を開きましょう。
さっきまでやってきた手順通り、「Commit」→「Push」を行います。
まずは「Pull Request」
編集が終わりPushできたら、こんどはマージをする前段階である、「Pull Request」を出します。これは、共同制作で必須になる機能なので、覚えた方がいい知識となっています。
まず、「Pull」ですが、「Push」の逆です。なので、
Pull
データをもらうこと(受け取ること)
となります。
一応今回の場合、「main」ブランチが、「(mainから切ったブランチ名)」ブランチの内容をもらうという感じになっているので、操作としては「Pull」になるわけです。(ややこしいですが「マージの正体がこれだ!」といった感じです)
次は、「Pull Request」です。
簡単に説明すると、「何を変更したか」を書いて、マージしたいことを告知することです。
共同開発の際の「Pull Request」からマージの流れを先に説明すると、
1.「Pull Request」を出す
ここで「何を変更したか」、「どんなところを見てほしいか」を書いて、チームのメンバーへ「共有する本番環境」に変更を加えたいことを周知する。2.「コードレビュー」を書いてもらう
ほかの人が「Pull Request」に書かれている内容を元に、問題がないかを調べ、評価します。
この段階で何か問題があった場合は、修正を要求することもできます。3.「マージ」する
コードレビューを行って問題がなければ、「Pull Request」で告知した通りマージをします。
という感じになります。
では、説明だけだとわかりにくいので、実際にやってみましょう!
Pushし終わると、「GitHub Desktop」の中央に、下のような感じの表示が出ます。
この一番上の青色の項目「Create Pull Request」をクリックします。
ここで、「Pull Request」を出します。
設定する項目としては、
- どのブランチにPullするか
- どんな変更を加えるかの概要
の2つがメインになっています。
最後に、「Create Pull Request」をクリックしてみましょう。
すると、
こんな感じの画面に切り替わると思います!
これで、「Pull Request」を出せて、どんな変更を加えたいのかを周知できました!
次にコードレビュー
ここからコードレビューをするのですが、今回は省きます。
コードレビューのやり方が載っている記事を見つけたので、参考にしてください。
最後に「Merge」する
コードレビューが終わり、問題なしだという前提で進めます!
なので、次にマージします!
先ほどの画像の真ん中にある、「Merge pull request」を押しましょう!
最後に、コメントを書いて、左下の「Confirm merge」を押しましょう!
最後に自分の端末のmainブランチを更新
他の人がマージした際に必要な操作ですが、一人だけならあんまり気にしなくていいかもです。
最後に自分の端末のmainブランチを更新します。
「GitHub Desktop」の「branch」から、「Update from main」を押します。
次に、差分が見つかった場合はPullの表示が出てきます。
Pullが出てきたときはPullしましょう。
これで完了です!
最後に
ここまで大変だったと思いますが、こんな感じになっています。
最初にも話した通り、これは教材としてテキトーに作ったものをいいかんじにしただけなので情報量がとんでもないことになってると思います。
いつかうまいこと分割してもっと内容をすっきりさせたバージョンを出そうと思っているので、そちらもお願いします。
この記事で伝えたいのは、とにかく簡単だよねってことを伝えたいです。
自分はGitHubをQiitaで勉強しようと思いましたが、何一つわからなくて3度くらい挫折してますw
AIの手助けってすごいなって感じられた内容になりました。
ぜひ何度もやってみて、GitHubのスキルを身に着けてみてください!
次は運用時の問題の対処についての記事になってます!
是非こちらも参考にしてください!












































