【非エンジニア向け】宇宙一わかりやすいGitことはじめ
これ何？
つれづれなるままに、パソコンくらしぎっとにむかひて、画面にうつりゆくよしなし事を、そこはかとなく書きつくれば、あやしうこそものぐるほしけれ
―by だれか
非エンジニアなのに、何やら小難しそうなGitとやらを使うことを要求される場面、あると思います。
この記事では、エンジニアでもなければそもそもパソコンも詳しくない人にGitを今から布教します。
なぜGitが必要なのか？ということなども、この解説を見ていればそのうちわかってくることでしょう。早速始めます。
いきなり仕事が来た！
あなた（A社員） は、仕事で「ラーメンの食べ方」というガイドを作成することになりました。
テーマに沿って、こんなテキストファイルを作り上げました。
# ラーメンの食べ方
1. 橋を手に取る
2. 啜る
3. おいしい
これをラーメンの食べ方.txtとして提出したところ、上司にこってりと絞られてしまいました。何がいけなかったのかさっぱりわからなかったので、とりあえず近くにいたB助くんにこのファイルが渡し、直してもらうことにしました。
# ラーメンの食べ方
1. 箸を手に取る
2. 啜る
3. おいしい！
B助くんは、これをラーメンの食べ方_修正版.txtとして、とりあえず保存しました。
しかし何かが足りないと思ったB助くんは、優秀と噂のC太郎くんに手伝ってもらうことにしました。すると、こうなりました。
# ラーメンの食べ方
1. 食券を購入するか、メニューを見て店員さんに注文を伝える
2. テーブルに届くまで待つ
3. ラーメンができたら、箸を取り出す
4. 箸を使い、啜って食べる
5. 熱いうちにいただく
さすがはC太郎くん、わかりやすい食べ方のガイドができました。でも、このファイルはもともと「修正版」と書いてあります。なので、ラーメンの食べ方_修正版（最新）.txtとして保存しました。
その後なんと、このファイルを見かけたD三郎くんが、「これも書き出したほうがいいんじゃないか」と、勝手にファイルを編集してしまいました。
# ラーメンの食べ方
1. 食券を購入するか、メニューを見て店員さんに注文を伝える
2. テーブルに届くまで待つ
3. ラーメンができたら、箸を取り出す
4. 箸を使い、啜って食べる
5. 熱いうちにいただく
ヒント︰熱いうちに食べないと、麺がのびておいしくなくなってしまいます！
D三郎くんは、これをうっかりラーメンの食べ方_修正版（最新）.txtとして上書き保存してしまいました。でも「文章を追加しただけだし、まあいっか」とお気楽な様子です。
おっと、あなた（A社員）はここで、最初の提出時に「箸」を「橋」と書いていたことに気がついたようです。直しましょう。
# ラーメンの食べ方
1. 箸を手に取る
2. 啜る
3. おいしい
これで完璧です。今日は4月1日なので、ラーメンの食べ方_0401.txtとして保存しました。
さらにさらに、ここで少しパソコンに詳しいE社長が「なんでこれはMarkdownなのに.txtなんだ？」と考え、拡張子を書き換えてしまいました。
さらにさらにさらに、F美部長がちょうどどこかのタイミングで、「ラーメンの作り方」を含む全てのファイルのバックアップを取っていたようです。しかし、E社長が編集してしまっているので、それより前の編集履歴についてはわかりません。
さらにさらにさらにさらに、社内にいるスパイのXが、わざと誤字を入れたり順番を入れ替えるなどのいたずらをしてしまいました。
この「ラーメンの食べ方」をレビューする上司は地獄を見ることになりましたとさ。めでたしめでたし。
何がいけなかったか
「社会人としてまず勝手に他人のファイルを弄ってはいけない」というご指摘はさておき、それ以外の合意を取った場面でも問題は山積みです。
ファイル名が散らかる
パッと浮かぶのはこれだと思います。明記したものだけで、
ラーメンの食べ方.txtラーメンの食べ方_修正版.txtラーメンの食べ方_修正版（最新）.txtラーメンの食べ方0401.txtラーメンの食べ方0401.md
の5パターンがあります。しかも、書き方もバラバラです。まさに地獄ですね。
誰がどこを編集したのかわからない
A社員は、B社員に相談したうえで又聞きでC社員も参加しました。これでは、誰がどこを編集したのかまるでわかりません。万が一ミスがあったりしたときに「誰が責任を取るべきか？」ということも決められません。
いつ編集したのかわからない
今回は、ただのテキストファイルです。いつどこを編集したのか追えないため、内容の衝突があったときに簡単に解決できません。どちらが新しくてどちらが古いのかもわかりません。
バックアップからの復元が難しい
バックアップは、あくまで「その時間ではこうだった」というものをコピーする作業に過ぎません。とはいえ、ファイルを編集するたびにバックアップを取っていては大変です。
改ざんされてもわからない
今回、無理矢理ではあるものの悪意のある人を登場させました。ただのテキストファイルは、こういった改ざんに対しても弱いです。
下書きにできない
下書きにしたい場合やコメントを入れたい場合、そこを強調したりファイルを作成する必要があります。
しかし、下書きにすると
- データが散らかる
- コメントを消し忘れる
- いつの間にか、誰が作った下書き・コメントなのかわからず、消すに消せなくなる
という問題も起きます。
Gitですべて解決できる
この悩み、すべてGitで解決できます。それでは、Gitを使っている世界線の「ラーメンの食べ方」を見ていきましょう。
A社員が取るべき行動
- A社員が、テキストファイルを作成する
- 「ラーメンの作り方」という リポジトリ（repository） を作成する
- コミット（commit） して プッシュ（push） する
B助くん、C太郎くん、D三郎くんが取るべき行動
- B助くんが、リポジトリを クローン（clone） または プル（pull） する
- 作業用の ブランチ（branch） を作成する
- 編集する
- 編集した部分をコミットしてプッシュする
- A社員に プルリクエスト（pull request） を送る
のっけから横文字だらけでごめんなさい。翻訳すると、
- リポジトリ…データの保管場所
- コミット…「セーブ」
- プッシュ…セーブを反映
- クローン…コピー
- プル…ネットから上書きコピー
- ブランチ…「並行世界」
- プルリクエスト…「この内容でファイル更新していいですか？」と要求を送ること
となります。
真似してみる
準備編
まずは1つアプリを入れましょう。たった1つです。
VSCode
超高機能なメモ帳です。インストール時に出てくる「コンテクストメニューがどうこう」というものは有効を推奨します。
実践編
まずは適当なフォルダを作ります。
VSCodeを開いたら、フォルダをドラッグアンドドロップしましょう。
そうしたら、右下のこの黒い線のところにマウスカーソルを合わせることができるはずです。上に引っ張り上げましょう。
そうしたら、このコマンドを実行してください。
winget install --id Git.Git -e --source winget
そうしたら、これでGitを使う準備は完了しました。いきなりネット上のものに触る前に、まずは手元のパソコンでGitの使い方を学んでみましょう。
リポジトリの作成
まずは、リポジトリ（保管場所）を作成します。その前に、一度ターミナルを破棄しておきましょう。
そうしたら、もう一度下から上に引っ張り上げて、以下のコマンドを実行します。
git init
Initialized empty Git repository in…と出てきたら成功です。
そうしたら、適当にファイルを作ってみましょう。今回は「ラーメンの作り方」に倣ってみることとします。
ここを押すとファイルを作成できます。その隣はフォルダ作成ボタンです。
ここで注意点です。VSCodeは、拡張子を勝手に付け足したりはしてくれません。ちゃんと手動で.txtや.mdなどを入力しましょう。このあと行うGitのコミット（セーブ）のあとにファイル名を変更してしまうと、別のファイルと見なされてしまい、履歴が追いにくくなります。
というわけで、作成しました。これをセーブ（コミット）してみましょう。
各ボタンについて説明します。
- 紙に矢印のアイコン…そのファイルを開きます。
- 戻る矢印のアイコン…そのファイルの変更を、前回のセーブポイントまで取り消します。今回はファイルの作成から始めたので、これを押すと「ラーメンの食べ方.md」の存在がなかったことになります。
- 「＋」…そのファイルを、ステージ（コミットの対象化）します。
- 「U」…ボタンではありませんが、説明しておきます。ここの文字は、編集内容により変わります。「U」は新しいファイル、「M」はファイルの内容変更、「D」はファイルの削除を表します。
今回は新しくファイルを「セーブ」したいので、「＋」を押してステージします。
Commitを押してコミットします。上にテキストを入れるところがありますが、この記入は必須です。
プロジェクトや会社により記入のルールがありますが、最初のコミットでは英語なら「Initial Commit」、日本語なら「最初のコミット」と書くのが無難だと思います。
セーブ完了
これで「セーブ」は完了しました。あとは、GitHubアカウントがあるならこれを全世界や組織の中で公開することもできますが、一人でこのまま使い続けることもできます。
基本的に覚えておくべき単語は、
- リポジトリ
- クローン（GitHubからプロジェクトのデータを取ってくるときに、最初に一度だけ実行します）
- コミット
- プッシュ
- ステージ
だけでもなんとかなります。その他の単語は、必要に応じて覚えていってください。
編集してみる
それでは、ここで追加の編集をしてみましょう。
5行目の左に青い線がつきました。これは「変更点があった」ということを示しています。
この状態でソースコントロールに入ると、「どこが変わってどこが変わっていないのか」が人目でわかります。これをステージしてコミットすることで、変更を反映できます。
今ミットすると、左下の数珠みたいなものが伸びてきました。ここに変更履歴がすべて入っています。これにより、
- 誰かが同時に編集しても、衝突したときに比較ができる
- 誰が、いつ、どこを編集したのかわかる
という利点があります。
Q&A
VSCodeって英語でしか使えないの？
もちろん日本語化できます。
GitとGitHubの違いって何？
Gitは「バージョン管理ツール」のことで、GitHubは「Gitのプロジェクトのフォルダ（リポジトリ）や編集履歴をWebで見やすくしてくれたり、インターネット上にリポジトリをおいておいてくれるサービス」のことです。
Gitを使いこなして、労力の消滅を0にしよう
Gitの最大の利点は、衝突が起こったときにどうするかを決定できるところにあります。「会社内のネットワークにある適当なファイルを同時に何人も編集した」という場合だと、絶対に衝突が起き、誰かの仕事が無駄になってしまいます。WordやExcelにはロック機能がありますが、ロック機能があるということは同時に一人しか編集できないということでもあります。
Gitをつかうことで、こういった問題点はすべて最初からなかったことになります。決めるべきは、「衝突が起きたときに同解決するのか」ということだけです。
Gitはかつてはコマンドラインが使えることが前提でしたが、今はGitHubが最初からサポートしているので随分使いやすくなりました。ぜひ気軽に試してみてください。
Discussion