Contents
この記事では、プログラムがよくわからないデザイナーの視点で、Gitを解説します。
「fetchやpullといった命令は、一体何をしているのか」を解説します。
とっつきづらいクセに、ゲーム開発では必ず使うGit。
Google先生もプログラマー用にコードの解説ばかり。
もっと視覚的に分かりやすく教えて欲しい！
そう悩んでいた過去の私に送る記事です。
3つのエリアをイメージする
- デフォルトブランチ（develop, main, master など）
- 作業ブランチ
- 自分のPC
この3つのエリアをイメージすることが、Gitの基本です。
デフォルトブランチを直接変えることはありません。
後戻りが難しくなるからです。
作業ブランチを間に挟むことで、リスクを下げ、問題の対処をしやすくします。
この記事では、
デフォルトブランチと作業ブランチの２つのブランチだけが存在すると仮定します。
clone
デフォルトブランチのデータを、自分のPCにコピーすることです。
最初に1度だけする行為です。
今後の作業場を作ります。
自分のPC内の あるフォルダ が、Gitとやり取りする場所になります。
ブランチの移動
ブランチを移動すると、cloneしてきたフォルダの中身が変わります。
別の場所に新しくコピーするわけではありません。
あくまで変更されるのは、紐づいたフォルダ内だけです。
ブランチを移動する時、このフォルダの中に対して、大量のデータの削除や更新、追加が行われます。
つまり、ブランチの行き来はけっこう処理が重いです。
fetch
「自分のPCのデータ」と「選んだブランチのデータ」を比較をします。
ウェブ上のブランチには、他の人もデータを上げます。
なので、毎日ブランチは変化していきます。
fetchは、自分のPCのデータが古くないかを知る行為です。
GitHubDesktopの場合、差異があれば、どれだけ差異があったのかを数字で示してくれます。↓
差がない場合は、数字が出ません。↓
pull
データのダウンロードのことです。
選んだブランチに更新があった場合、それをダウンロードしてきます。
fetch →差異アリ→ pull が一連の流れです。
push
データのアップロードのことです。
選んだブランチに、自分のPCのデータをアップロードすることです。
トラブルは大体この時に起こります。
たとえば、
・上げるブランチを間違えた。（＝他の人の作業に上書きしてしまった）
・誤ったデータを提出した。（＝エラーを生成した）
・上げたデータに不足がある。
・余計なデータを上げた。
などなど、
慎重～～～にやりましょう。
自分も何度かやらかして怒られました。Git、怖い。。
commit
pushの前段階です。
「箱詰め＋ラベル張り」と考えるといいです。
commitは、pushの前に必ずします。
こんな手順です↓
1.どれをアップするのか選ぶ。
2.不要なデータは削除。
3.それらのデータは、何のためのデータなのか明記する。
例）・モデルalice の修正
・戦闘用モーションを追加
箱：commit を荷詰めしたら、pushでブランチ上にアップします。
ちなみに、1度のpushで複数の箱：commitをアップすることが可能です。
merge
作業ブランチのデータを、別のブランチへ移植することです。
2つの世界線を融合させる。と考えると良いです。
もし、移植先のブランチでも同じデータを変更していた場合、コンフリクト(conflict)が起きます。
（コンフリクトについては後述）
新人の場合、merge作業は上司がするでしょう。
push以上に事故が起こりやすい作業です。
コンフリクト
デフォルトブランチと作業ブランチで、同じデータを変更していたら起こるエラーです。
「2人以上が同じデータに変更を加えていた」ということです。
Gitさんは、どっちのデータが本物なのかわからず混乱し、エラーを吐きます。
この場合は、
・どちらか一方のみを採用する。
・先に一方を確定する→次にもう一方を上書きする。
といった対処になります。
大体、pull,mergeをするときに発覚します。
他の作業者ときちんと情報交換をして、コンフリクトをそもそも起こさないことが大切です。
まとめ
Git に出てくる基本操作の解説をしました。
ミスると大事故になりかねないですが、正しく使えればこれほど便利なツールはありません。
理屈を知ることで、Gitへの恐怖を無くしましょう。
これまでの内容を、1枚の画像にまとめました。↓
