はじめに

強いデッキ作ろうぜ！

俺「サイドラ入れて」
アイツ「サイクロン入れて」
コイツ「ミラフォ抜いて」
ソイツ「トラップを手札誘発に変えて」

俺「これ入れたの誰？」
アイツ「なんであれ抜いたの？」
コイツ「それ抜いたけどこれ入れてないぞ」
ソイツ「それ知らん」

あーあ、ぐちゃぐちゃになってしまいました
🤖<Gitを使えばよかったのに…

さて、改めてGitとは何か？

　超簡単に言えば履歴を管理してくれるやつです。
今回のカードゲームの例えで言うなら、「カード変更を提案する多数」と「実際にデッキを触る一人」に分かれるようなイメージです。このデッキを触る人こそがGit君なのです。

一人が上手くまとめてくれる

用語から学ぼう

　ビートダウン？ハンデス？？シナジー？？？
まるで意味がわかりませんが、知ればTCGが理解しやすくなるのもまた事実。
　Gitも同じ。用語から機能を理解したり、他の解説が読みやすくなったりします。用語を学びながら手順を理解しましょう。

クローン

　まずはどんなデッキを編集するのか、Git君からデッキのコピーもらってきましょう。決闘者的に言うならデッキレシピと言った方が想像しやすいでしょうか。このレシピこそがクローンです。
これからこのデッキレシピを色々書き換えていきます。

コミット

　デッキを見せてもらい「ここ違うな～」となったあなた。
自分の頭の中や、手元で実際にデッキをいじってみて、「よし、これでOK!」
では早速先ほどもらったデッキレシピに反映させましょう。これがコミットをするということです。

　ちなみにこのとき「どのような変更をしたのか」「なぜ変更したのか」を記したメモを一緒に渡します。これをコミットログといいます。

🙎<サイバネティック・ヒドゥン・テクノロジーの方がシナジーあるからな

これが無いと冒頭の様にごちゃごちゃとしてしまいます。よく使ってる魔法が抜かれてたら誰でも「なんで？？」となりますし、それが誰の編集なのか分からなければ理由の聞きようもありません。
地味だけどかなり重要な工程です。

コミットログは必ず残そう

プル

　さてデッキレシピにまとめた（コミットした）ものを早速デッキ本体に反映……する前に、他の編集者とすり合わせなければいけません。みんなバラバラの編集をしてるでしょうし、それを一つにまとめるのは大変です。
なので今、他の人がどんな編集をしていたのか、最新のデッキ情報を取得してくる。これをプルと言います（ときには矛盾が発生し、それを解決したりもします）。

　このときの差分は次のように表します。

デッキ編集差分

- 抜いたカード
+ 入れたカード

ちなみに最新のデッキ状況を確認するだけのものを

フェッチ

と言います。

プッシュ

　さぁいよいよ本体と合体するプッシュの時です。
コミットログとプルしたことを確認したら深いこと考えずにGO!
デッキ本体を確認してみてください。きっとより良いデッキになってるはずです。

ブランチ

少し長くなるよ

　ブランチとは作業を分岐する機能。またその枝分かれのことを言います。
全体の編集とは別に「モンスターカード担当」「魔法カード担当」といった様に分担するようなイメージです。（逆に時間かかりそうですが、あくまで例えなので……）
この枝分かれはそれぞれ分離独立しており、同時並行で編集しても互いに影響がありません。ピンとこないかもしれませんが、実際のプロジェクトではこれが結構大事なのです。
　今はなんとなく「カードが混ざらないのが大事なんだなぁ」くらいに覚えておいてください。

ちなみにこの枝分かれする前の本流のことをmasterといいます。
そしてブランチがmasterに再び合流することを

マージ（統合）

といいます。
上手く魔法が組めたらデッキに合流してあげましょう。

　さて、本流であるデッキ本体（master）の編集を持ってくることをプルと言いましたが、支流（ブランチ）同士でも似たようなことができます。

リベース

　正確には持ってくるというより他人の編集に乗っかる、枝をそのまま接ぎ替えるようなイメージです。
モンスターカードと魔法カードのブランチがあったとして……

　もう少し嚙み砕いて説明しましょう。

「モンスターカード担当がツイン抜いてノヴァ入れたらしい」
「マジか、結構でかいな」
「それな。他にどんな編集してるのか一度見せてもらおう」

だいたいこんなもんです。
　リベースはあくまでモンスターカード担当の編集を見せてもらう（反映させる）ものなので、魔法カード担当が行ったリベースはモンスターカード担当自体への影響がありません。

　役割がわかりづらい！という人はもしリベースが無かったらを考えてみた方が早いかもしれませんね。
　先ほど説明した通り、カードの担当同士は独立しているので互いの編集が見えません。これはカードが混ざらないためでしたね。
だから他の担当がどんな編集をしてるのか見たかったら毎回
　モンスターカード担当のプッシュ
　↓
　魔法カード担当のプル
を挟まなくちゃいけなくなります。一々頼むのも面倒ですし、分流と合流を繰り返すのもごちゃついてて汚いですね。
結局カードが混ざっちゃいそうで本末転倒というやつです。

もしリベースが無ければ……¹

　なので基本はそれぞれでやって、必要があったら見せてもらう。相手への影響がないので互いの独立性も保たれます。

　以上が用語説明になります。少しはGitを使う流れが掴めたでしょうか？
せっかくなので実際のソフトにもさらっと触れてみましょう。

実際にさわってみよう

今回の登場人物

Source Tree
難しいコマンドとか使わなくても分かり易い操作でGit使えるよ
Azure Dev Ops
クラウドサービスの一つ。
アマゾンのAWSなら聞いたことあるだろうか。言わばそのMicrosoft版だよ。
今回はリポジトリっていう機能だけ使うよ。
要はみんなで使う引き出しみたいなものだよ。

手順

組織を作ろう（入ろう）
　Azure DevOpsに登録、プロジェクトを立ち上げてください。
細かいことわかんない！とか誰かが用意してくれてるよ～って人は気にしなくていいです。
もし自分で1から立ち上げたい人はこちらを参照してください。
→ リポジトリの作成
鍵を作ろう
　右上の歯車>Personal access tokens>+New Tokenからトークンを作成してください。
みんなで使う引き出しの合鍵になります🔑
⚠️ちなみにトークンは一度しか表示されません！ちゃんと控えておきましょう
Sourcetree
Sourcetreeをリンク先からダウンロード、インストールしてください。
用語で説明した手順通り、まずはクローン！
　今回はAzureを使うので、[リモートリポジトリ]から先ほどのリポジトリにアクセスしましょう。
ホスティングサービスはAzureDevOps
ホストURLはおそらくhttps://dev.azure.com/[会社名]/[プロジェクト名]みたいな感じ
PersonalAccessTorkenはユーザ名（outlookアカウント、会社で使ってるメアドとか）
パスワードは先ほど作った合鍵、トークンを入力します
　使いたいリポジトリを選んだら履歴や枝分かれの画面が表示されます。

黒塗りばかりで申し訳ない…
¹
　クローンが作成出来たら右上のExplorerを押してみてください。ローカル保存されたGitフォルダが開けるはずです。
その中でファイルを追加したり変更したりしたらまたSourceTreeに戻ってきてください。
作業ツリーのファイルから必要な項目を＋ボタンで抜き出し、コミット。画面下にコミットログを書くのを忘れずに。
あとは説明した通りにプル、プッシュ。必要に応じてブランチ、マージ。

おわりに

　結局のところ、Gitとは「みんなで同じ作業机使ったらごちゃごちゃするからそれぞれの机にもってこーぜ」というだけの話なのです。
基本は自分の机で作業して、キリの良いところでみんなの所に持っていく。ただそれだけ。
ブランチが東京地下鉄路線図みたいなことになって迷子になったりなんて無いので、まずは気楽に使ってみてください！

Source Tree公式サイトより ↩ ↩²