Zenn
💻

非エンジニアのためのGit/GitHub講座 全体像 & Gitでできること をふんわり理解する

2021/12/08に公開
Git
GitHub
team
agile
tech

この記事は、Akatsuki Advent Calendar 8日目の記事です。
前回は @AZQ1994 さんの、"RailsのAPIサーバーのレンダリングを速くしました" でした。

前置き

こんにちは。軍曹です。
私は普段、株式会社アカツキで、クライアントエンジニアとしてゲーム開発に携わっています。業務の中で、ふと思ったことがあるので投げかけさせてください。

「非エンジニアの皆さんにとって、Git/GitHub、難しすぎないでしょうか？？？」

前提、エンジニアと一緒に仕事をする上で、非エンジニアの方々がGit/GitHubを使う場面というのは多くあると思います。
そういった時の非エンジニアの方々は、会社やチームごとのドキュメント・世の中に蔓延る、Git/GitHubを解説した記事や書籍を参考にするのだと思います。
が、「これらはどうにもエンジニアでないと分かりにくそうだぞ」というのが、自分の所感です。

そこでこの記事では、「非エンジニアの方々に向けて、Git/GitHubの解説」をしていこうと思います。わかりやすさ命です。わかり辛かったら何度でも書き直す所存です。

Git/GitHubは理解が難しいものだと私自身考えています。理解が及んでいなかったり、わかりやすさを優先するあまり間違っていたりなどあるかもしれません。批評批判甘んじて受け入れてアップデートしていけたらと思っています。よろしくお願いします。

目次

  • [その1] 全体像 & Gitでできること をふんわり理解する (本記事)
  • [その2] GitHubを使ったチーム作業 をふんわり理解する (執筆中)

全体像の理解

ここまで、Git/GitHubと書いてきましたが、実はGitとGitHubは別物です。はい、既に分かりづらいですね。萎えるのもわかります。これに加えて、おそらくですがSourceTreeも使っているのではないでしょうか？余計わかりなくなってきましたね、はい。そこで、まずは一旦、全体像を把握しましょう。

Git、GitHub、SourceTreeとは？

  • Git
    みなさんのPCにエンジニアが無理やりインストールしたツールです。
    これによって、色んな便利なことができます。
    エンジニアのPCには必ず入っています。

  • GitHub
    他の人と一緒にGitを使うための便利機能を提供するWebサービスです。
    クラウド上で、個々人のPCで行った作業を合体する時に使います。

  • SourceTree
    Gitは、黒い画面にポチポチ文字を入力することで動くツールです(=CUI)。
    なので、非エンジニアにはとっつき辛いです。
    このGitを、視覚的にわかりやすく、ボタン操作などで使うためのツール(=GUI)がSouceTreeです。
    GitHubとの連携も行ってくれるので、大体これとGitHubで操作が完結しているのではないでしょうか？

操作フロー

まとめると、こういったフローになると思われます。

  1. 自分のPCにあるSourceTreeで、Gitを操作する
  2. 何かGitを操作したら、他の人と共同で使っているGitHubにそれを反映する
    (この操作にも、SouceTreeが使われる)
  3. 他の人がGitを操作したら、GitHubからその情報を取ってくる
    (更にこの操作でも、SouceTreeが使われる)
  4. 2と3を繰り返す

ではこうしたフローにおいて、

  • 手元のPCでGitは何をしているのか (本記事)
  • GitHubと連携するときは何をしているのか (執筆中)

これらを説明していこうと思います！

Gitは何をしているのか：バージョン管理

みなさんのPCにインストールされたGitが手元で何をしているのか？まずGitが最初に力を発揮するのは、「バージョン管理」が必要になってくる場面です。例を挙げて説明しましょう。こんな時、皆さんはどうしますか？

ミッション

Q. 取引先からの指示：次のドキュメントを完成させてください！

[ファイル名] 五十音.txt

あ行 | あいうえお
か行 | かきくけこ
  • ドキュメントは上記の黒い部分のことです
    • 現在は、あ行とか行しか書かれていません
  • 取引先とあなたの考える「完成」とは、五十音全てをドキュメントに書くことです
    • 細かい仕様は決まっていないので、取引先に何パターンか作って見せたいです

あるあるな対応

さて、皆さんこの課題にどう対処するでしょうか？
きっとあなたはまず、こんな風に「さ行」を書くでしょう。
とりあえずこの状態を五十音_ver1という名前で保存しておきます。

[ファイル名] 五十音_ver1.txt

あ行 | あいうえお
か行 | かきくけこ
さ行 | さしすせそ

では次に、残りの五十音をどう書いていきましょう？
仕様は曖昧ですので、一旦こんな風に進めてみます。
この状態を五十音_ver2という名前で保存しておきます。

[ファイル名] 五十音_ver2.txt

あ行 | あいうえお
か行 | かきくけこ
さ行 | さしすせそ
た行 | たちつてと
な行 | なにぬねの
.
.
.
わ行 | わいうえを

できる仕事人のあなたは「別の形の五十音も用意しておこう」と考えます。
そこで次のようなドキュメントも作っておきます。
この状態を五十音_ver3という名前で保存しておきます。

[ファイル名] 五十音_ver3.txt

あ行 | あいうえお
か行 | かきくけこ
さ行 | さしすせそ
た行 | たちつてと
な行 | なにぬねの
.
.
.
わ行 | わゐうゑを

あるあるな対応の課題

上の場面では、既にドキュメントが3つできましたよね。
これくらいなら管理可能ですが、これがこんな風になったらどうでしょう？

  • ver10, ver20...と五十音のパターンが増えていった
  • 五十音以外のドキュメントも10個, 20個...と必要になってきた
  • 管理が大変だからと、上のver2のようなドキュメントをこまめに保存しなくなった

こうした事態は、考えるだけで「ヤバいわよ！」となりますね。
ではこの事態にスマートに対応するには、どうしたらいいでしょう？

Gitを使ったスマートな対応

Gitを使うと、先の例がこんな風にスマートに対応できます。
ファイルをバージョン毎に保存しなくても、その情報をGitに保存しておくことができます。

  1. Gitに以下の情報を保存します
[セーブポイント名]　　　　　： セーブポイント①
[更新するセーブポイント]　　： なし
[現在のファイル状態]　     ： 五十音.txt
　　　　  　　　　　　　　　： あ行 | あいうえお
　　　　　　　　　　　　　  ： か行 | かきくけこ

※ 厳密には違います

Gitは、上の例で言う五十音.txtを保存している状態になります。

  1. Gitに以下の情報を保存します
[セーブポイント名]　　　　　： セーブポイント②
[更新するセーブポイント]　　： セーブポイント①
[現在のファイル状態]　     ： 五十音.txt
　　　　  　　　　　　　　　： あ行 | あいうえお
　　　　　　　　　　　　　  ： か行 | かきくけこ
　　　　　　　　　　　　　  ： さ行 | さしすせそ

Gitは、上の例で言う五十音_ver2.txtを保存している状態になりますね。

  1. Gitに以下の情報を保存します
[セーブポイント名]　　　　　： セーブポイント③
[更新するセーブポイント]　　： セーブポイント②
[現在のファイル状態]　     ： 五十音.txt
　　　　  　　　　　　　　　： あ行 | あいうえお
　　　　　　　　　　　　　  ： か行 | かきくけこ
　　　　　　　　　　　　　  ： さ行 | さしすせそ
　　　　　　　　　　　　　  ： .
　　　　　　　　　　　　　  ： .
　　　　　　　　　　　　　  ： .
　　　　　　　　　　　　　  ： わ行 | わいうえを

Gitは、上の例で言う五十音_ver3.txtを保存している状態になりますね。

  1. Gitに以下の情報を保存します
[セーブポイント名]　　　　　： セーブポイント④
[更新するセーブポイント]　　： セーブポイント③
[現在のファイル状態]　     ： 五十音.txt
　　　　  　　　　　　　　　： あ行 | あいうえお
　　　　　　　　　　　　　  ： か行 | かきくけこ
　　　　　　　　　　　　　  ： さ行 | さしすせそ
　　　　　　　　　　　　　  ： .
　　　　　　　　　　　　　  ： .
　　　　　　　　　　　　　  ： .
　　　　　　　　　　　　　  ： わ行 | わゐうゑを

Gitは、上の例で言う五十音_ver4.txtを保存している状態になりますね。

これによって、以下の状態が実現します。

  • 手元には、五十音.txtのファイルがただ一つのみです (スッキリ！)
  • その上で、各種セーブポイントのファイル状態にすぐに戻せます
    • セーブポイント①に戻せば ： 五十音.txt
    • セーブポイント②に戻せば ： 五十音_ver1.txt
    • セーブポイント③に戻せば ： 五十音_ver2.txt
    • セーブポイント④に戻せば ： 五十音_ver3.txt

この例における、Gitの便利な点

Gitは、こうした「バージョン管理」を楽にしてくれるツールです。
上の場面でGitを使えば、3つのバージョンそれぞれに1つ必要だったドキュメントは「ドキュメント自体は五十音ただ一つ」で済みます。
そして、1つのドキュメントの「ver1・ver2・ver3」の全ての状態は、Gitが別途記録しておいてくれるのです。そしてこれは、ドキュメントに限らずファイル全般に言えます。
つまり、Gitの便利な点の一つは「全てのファイルについて、(わざわざファイルを複製しなくても、)任意のセーブポイントを設定できる」ところにあるわけです。

魔法の呪文解説1：コミット

上記の例において、Gitに保存した一塊の情報を「コミット」と言います。
コミット、難しそうですよね、わかります。なので、非エンジニアの方は、こんな風に読み替えると良いと思います。

  • コミット (名詞)
    • [1] ある瞬間のファイル状況 = セーブポイント
      例文) このコミットに戻って確認して欲しい
      意味) このセーブポイントに戻って確認して欲しい
    • [2] 直前のセーブポイントからの変更
      例文) このコミットでプログラムが動かなくなったんだよね
      意味) このセーブポイントに加えた変更の影響でプログラムが動かなくなったんだよね
  • コミットする (動詞)
    • コミットを保存する = (変更を)Gitにセーブする
      例文) この変更をコミットしておいてください
      意味) この変更をGitにセーブしておいてください

なんと、使われ方がたくさんあります！だから難しいんですよね...
わからなかったら周りのエンジニアに聞きましょう！これが一番大切です！

更にすごいGit/GitHubの役割

こうした「バージョン管理」ツールとしてのGitは大変優れています。
他方で、Git/GitHubが更に力を発揮するのは、「チーム作業」においてです。
こちらについては、後日別の記事でまとめようと考えています。
個人的に、非エンジニアの皆さんは、後はこちらを学べば十分だと思います！

おわりに

本記事が、非エンジニアの皆さんにとっての役に立てば幸いです。
同時に、今回の記事はどちらかと言うとエンジニアから非エンジニアへの、一方通行な発信なように思います。ぜひ皆さんが本当にわからないこと・困っていること・知りたいことがあれば教えてください。

また、もしこの記事を読んでいるエンジニアの皆さん。
こうした方が伝わりやすいのではないか・理解が間違っている・説明が誤解を招く、などのご意見ご指摘は大歓迎です！ぜひお気軽にご連絡ください！

参考

Discussion