Gitの教え方に困った！非エンジニアにも「いい感じ」でわかるGitの解説

• Gitさえ使えたら…非エンジニアの悲劇
• 非エンジニアが「Git…怖い…」となる理由
• コマンドラインインターフェース（CLI）に慣れていない
• 専門用語を理解するための前提知識がない
• 結局何ができるのか？がわからない
• わかりやすかったGitの教え方
• 「使うとどうなるか？」を伝えてもらえた
• 個人PCのファイルを例に教えてもらえた
• Gitとは？
• Gitはまさに「バージョン管理システム」
• 「コミット」のことは「セーブポイント」と伝えてみよう
• GitとGitHubとの違いとは？
• Gitを使うメリット
• 非エンジニアがGitを使えるようにするまでの手順
• 1）リモートリポジトリのクローン（複製）を自分のパソコンにローカルリポジトリとして作る
• 2）プルをしてリモートリポジトリと同じ最新の状態を作る
• 3）ブランチを作成する
• 4）自分のパソコン（ワークツリー）で修正箇所を修正
• 5）修正したファイルをステージに上げる
• 6）コミットしてもう一度リモートリポジトリにプッシュする
• 7）Backlogでファイルをマージする
• 最後に

Gitさえ使えたら…非エンジニアの悲劇

はじめまして、HRテックプロダクトを開発しているエン・ジャパンにて、新人マーケターとして働く田渕と申します。私の部署ではエンジニアの他にも、PdM、データアナリスト、マーケターが働いており、AIやプログラミングを学ぶなど、テクノロジーの活用が活発な部署でもあります。エンジニアのみなさんとプロジェクトを進めることが多いのも特徴です。

とくに私自身の体験からお伝えすると、エンジニアの方から「Gitの使い方」を教えてもらったことで、仕事がすごく捗るようになりました。

はじめに、私がGitの存在を知ったのは「LPの修正をする」という仕事のとき。エンジニアの方から「Gitで（修正を）やります」と言われた時には、

• 「難しそう」
• 「マーケターである自分には不要」
• 「自分がやっても非効率なだけではないか」
• 「その都度、エンジニアの方にお願いすればいいか」

と「やらない理由」ばかりを並べて、覚えようとしませんでした。ただ、そこから悲劇は起こります・・・。

そのLPですが、細々と何度も修正が必要となり、毎回、修正をエンジニアにお願いしなければいけない状況に…。その方からすれば、いちいち対応が発生するわけですが、すごく丁寧に対応してもらえたことで、逆にすごく申し訳ない気持ちがMAXに…。

「Gitさえ使えたら…エンジニアの方とも、もっと気持ちよく仕事ができたのに…」

こんな気持ちがムクムクと芽生えてきました。同時に「もし、部署全体でもGitへの理解が深まれば、チームとしての業務レベルが向上していくはず」ということでした。

そこで、私自身、Gitを学ぶべく、エンジニアの方に指南いただくことに。いろいろと教わるなかで自分なりにですが、「わかったこと」「わからなかったこと」を整理してみました。

例えば、「非エンジニアを含むプロジェクトでGitを導入したいが、どう教えたものか」「一度教えたけど、伝わらなかった」そんな時の「Gitの教え方」として、ぜひ参考にしていただければと思います。

非エンジニアの立場からですが、精一杯まとめています。おそらく、足りていない部分、不十分なところもありますが、温かい目で見守っていただけると幸いです！

非エンジニアが「Git…怖い…」となる理由

コマンドラインインターフェース（CLI）に慣れていない

まず前提としてお伝えしたいことがひとつあります。
どうか優しい目で見てもらいたいのですが、私のGitへの第一印象は「ナニコレ…怖い…」でした。

エンジニアの方からGitを使う方法としてまず紹介されたのが、謎の「黒い画面」。後から「コマンドラインインターフェース」だと知ったのですが、画面いっぱいにコマンド（英語）の羅列。もう既に「ムリムリ…！自分には理解不能だ…」と距離を取ってしまっていました。正直「そのレベル？」と呆れられてしまうかもしれません。が、そのレベルなのです…。

じつは、プログラミングを学んでこなかった非エンジニアからすると「自分では手に負えないもの」という先入観、抵抗感を持つ人ばかり。ただ、学びたい姿勢があれば遅すぎることはないはず！どうか「怖がらなくていいんだよ・・・」と子犬をそっと見守るように接してあげてもらえるとうれしいです。

専門用語を理解するための前提知識がない

もうひとつ、これは独学しようとして挫折してしまったのですが、「専門用語を理解するための前提知識がない」という状況がありました。

例えば、「リポジトリ」と聞くとエンジニアの方であれば、すぐに概念を理解できると思います。
ですが、私の場合は、とにかくググって「リポジトリ」の意味を調べてみるわけです。

wikipediaによれば、

    “リポジトリ またはレポジトリは、バージョン管理システムでは、ソースコードやディレクトリ構造のメタデータを格納するデータ構造のこと。”
    

とあります。

ふむふむ、じゃあ「バージョン管理」「ソースコード」「ディレクトリ構造」「メタデータ」「データ構造」とは何か？と調べていくわけです。するとさらなる専門用語がどんどん出てきて、完全なるお手上げ状態に。そもそもの心理的ハードルがあがってしまいました。

結局何ができるのか？がわからない

なぜ、調べても調べても理解ができないのか。
それは「用語」や「概念」を頭で理解しようとしていたからでした。「結局、何ができるようになる？」「自分の仕事で必要な業務にどうGitを使うか？」をもとにして学ばなければ、入ってくるわけがありません。

じつは、エンジニアの方に「Gitとは何か」からすごく丁寧に説明をしてもらったのですが、恥ずかしい話「なんとなくわかった顔」しかできず、質問さえできずに、その時間が終わってしまった…という経験がありました。好意で教えてもらえて、さらに大枠の概念はイメージできていたものの「…で、どうしたらいいのだろう」と、肝心の使い方がわからず、手が止まってしまったのです。

Gitはあくまで手段なので、大切なのは、どんな目的を達成したいか。
私自身、目的を共有することが足りておらず、その方としては「きちんと概念から理解したいのかな？」とむしろ丁寧に伝えてくれた。そのために食い違いが発生してしまったのかなと思います。

こういった「非エンジニアがGitに抵抗感を持ってしまうあるある」を踏まえ、より理解が進んだケースを追って見ていければと思います。

わかりやすかったGitの教え方

「使うとどうなるか？」を伝えてもらえた

まず、とてもわかりやすかったのが、

「超ざっくり言うと、Gitを使えば、ファイルの変更が管理しやすくなります」

という説明をしてもらったこと。

定義や概念はもちろんとても大切ですが、私にとっては「複雑なファイル管理で困らなくなる」と「利便性」を教えてもらえたことで、Gitを身近に感じられました。前段でご紹介したようにググればググるほど遠い存在だと感じてしまったので・・・極論ですが、むしろググらせてはいけないのかもしれません。

個人PCのファイルを例に教えてもらえた

例えば、私の仕事ではよく、上司やクライアントに企画書をもとに提案するのですが、こういったファイル名で保存していました（どうか発狂しないでください）。

「ファイルの名前のつけ方」に命名規則、ルールがなく、軽微な修正をした時、好き勝手な名前を適当に付けていました。これでは膨大なファイルがあるなかで、どれが最新のファイルなのかわかりません。

• 一つのファイル管理でさえ、このようなことが起こる
• 複数人で複数ファイルを編集すること想像してみよう
• 共同編集できるファイルであれば、Aさんが作ったものを、Bさんが誤って消すことも
• ただ、無尽蔵にコピーしたらファイル数が増え、管理が複雑に
• こんな煩雑な状況を無くせるステキなツールがGitだ！

こう伝えてもらったことで、「Git、すごい！」とハードルがグッと下がりました。

Gitとは？

Gitはまさに「バージョン管理システム」

もうひとつ、Gitのことを身近に感じ、理解が進んだ解説が、こちらです。

Gitとは？

• HTMLやCSSなどが記録できる
• さらに「変更した履歴」を残して管理できる
• 共同編集できるファイルであれば、Aさんが作ったものを、Bさんが誤って消すことも
• だから「バージョン管理システム」と呼ばれる

もともと、LP作成などでHTMLやCSSなどを使う機会があったため、「おおお！それは便利だ！」と思うことができました。もちろん、もう少し厳密に「HTMLやCSSだけではなく、プログラムのソースコード、画像などのバイナリファイルも記録できる」「変更履歴ではなく、その瞬間のスナップショットを残している」なども教えてもらえたのですが、あくまで「業務として使う部分」にフォーカスをしてもらえたことでグンと理解度がアップしました。

「コミット」のことは「セーブポイント」と伝えてみよう

さらにわかりやすかったのが、「コミット」のことを「セーブポイント」と表現してもらえたこと。

「コミットするとセーブポイントの時点にあとから戻れる。ポ○モンやドラ○エのセーブに近い」という解説が非常に良くわかりました。また、「コミット」の表記ルールも、シンプルに「いつ、誰が、何の目的で作業したか？を記載する」ことを徹底するようにしました。たとえば、「イメージパネル画像に使うイラストを指差しポーズからガッツポーズに変更した」などです。

私が作成するLPでいうと、こういったイメージです。

Gitについて調べると「オープンソース」「分散バージョン管理システム」などの用語も出てきます。
…が、正直、私はどちらの意味も、なんとなくしかわかっていません。それでも、Gitは使えますし、ファイルの管理がしやすくなりました。「LPの修正を自分でやるぞ！」という目的にそって、まずは「できること」が知れたことで抵抗感が消えていました。

GitとGitHubとの違いとは？

もうひとつ、Gitを理解する上で、出てくる素朴な疑問・・・それが、

「Gitと、よく聞くGitHubは、何がどう違うの」

というもの。そこでわかりやすかった解説がこちら。

• Gitは「プログラム」、GitHubは「Gitを用いたサービス」のひとつ
• GitHubは、Gitを用いたソフトウェア開発プロジェクトのための共有サービス

ここで初めて「似て非なるものだったんだ…」と理解ができました。ちなみにGitHubについても補足をしておくと、わかりやすかった解説がこちらです！

GitHubとは？

• 複数人がGitで保存した変更履歴に触れられるようにしたいときになる
• そのためのファイル共有サーバーのようなものが要る
• つまり、複数人が触れるコンピューターの上にリポジトリ（変更履歴を含めたファイルのデータを置く場所）が必要
• インターネット上にそのためのサーバーを用意してくれている（ホストしてくれる）
• だから「バージョン管理システム」と呼ばれる
• 自ら共有のサーバーを立てる必要がない
• WebブラウザでGitHubに転送されたファイルを表示するなど、Gitだけではできない機能も提供してくれる

出典：GitHub

Gitを使うメリット

ここからは、実際に私がGitを使ってみたメリットについてご紹介します。

急な修正依頼にすばやく対応できる

兎にも角にもここに尽きます。そもそもの目的が「自分でLPを修正し、そのバージョンを自ら管理すること」にありました。

例えば、クライアントから「申し訳ないんだけど、一つ前のバージョンに戻してほしい」というオーダーが入った時、すぐに前のバージョンを確認してもらうことができるようになりました。当然、画像のクリエイティブだけを戻す、テキストだけを戻すといったこともできます。

ファイルの管理が簡単になる

もうひとつ、使ってみてとくに実感したのが、ファイル管理が圧倒的に簡単になった、ということです。
Gitを使うことで、サーバー上にデータを保存でき、変更前の古いファイルを自分のパソコンに別名で保存する必要がなくなりました（笑）最新ファイルの区別も簡単につくようになり、「あのファイル、、どこにいったっけ？」というストレスから開放されることができました。

エラーの原因が発見しやすくなる

最後に、「エラーの原因が発見しやすくなった」もメリットとして挙げておきます。
LPを作成しているとよく発生するのが「レイアウト崩れ」です。Gitを使うことで、区切りが良い作業ごとにコミット（保存）していく使い方をしているのですが、誰が、いつ、どの作業をした段階でエラーが起きたのか、ここがすぐに見つけられるようになりました。

このあたり使ってみたことで感じたメリットですが、ぜひ導入時にも伝えてみるといいはずです！

非エンジニアがGitを使えるようにするまでの手順

ここまで「どう概要を理解してもらうか」「使うことで非エンジニアに得られるメリット」をご紹介してきました。ここからは、私がやっているLP作成・修正を参考に、一つひとつ導入手順についてご紹介していきたいと思います。

まずツールですが・・・・私自身、はじめはコマンドラインインターフェース（CLI）¹を紹介されたのですが、冒頭でご紹介した通り、どうしてもハードルが高く感じていました。そこでおすすめされて使うようになったのが、直観的に操作できるGUIツールでした。

そのなかでも『Sourcetree』をおすすめされ、日々使っています。
Atlassian社が提供しているGUIツールで、何よりも便利なのが、CUIで必要なGitのコマンドを覚えなくても、マウスで操作できること。日本語に対応しているため、非エンジニアである私でも使うことができました。
なお、使いはじめは『非エンジニアに捧げるSourceTreeを使ったはじめてのGit』と『Gitなんて怖くない！超初心者向け、SourceTreeの使い方はじめの一歩！』の記事を参考にさせていただきました。

出典：非エンジニアに捧げるSourceTreeを使ったはじめてのGit

最初はGitを学習するのが億劫だと感じていましたが、いまではなくてはならないツールとなっています。
ここからは、ファイルを修正し、本番環境にアップロードするまでに行う実際の導入手順を解説します。

※Backlogにリモートリポジトリがある場合で解説します。Backlogアカウントを発行してください。
※Sourcetreeのダウンロードを終えた状態から解説します。Atlassian社提供のツールなので、Atlassianアカウントが必要です。私はインストールで特に困ることはありませんでした。

1）リモートリポジトリのクローン（複製）を自分のパソコンにローカルリポジトリとして作る

より簡単に言うと既にあるサーバのデータを自分のパソコンに持ってくる作業をします。

1.自分のパソコンにクローンするローカルリポジトリを作る。

任意の場所に、リモートリポジトリをクローンするフォルダを作成します。

ex）フォルダ名：「test-resource」など

※フォルダ名は気にしないで好きな名前を付けて良いです。
（ただし、リモートレポジトリの名前をそのまま使うのが、混乱がなくて良いです。）

2.Sourcetreeを開き、その後「Clone」をクリックする。

3.「元のパス/URL」に、複製したいデータ（ソースファイル）があるURLを入力する。

ex）https://test.backlog.jp/git/test/test-resource.git

その後ID/PASSの入力が必要になるので、BacklogのID/PASSを入力します。

4.「保存先のパス」に、ローカルリポジトリを作成する自分のパソコンのフォルダを指定します。

ex）/Users/hinato_tabuchi/test-resource

5.「名前」には、test-resourceを入力。

リポジトリ：

Gitで管理しているファイル・フォルダのデータやその変更履歴を入れている場所。

リモートリポジトリ：

複数人が共有できる外部サーバ上にあるリポジトリのこと。※GitHubのリポジトリはリモートリポジトリである。

ローカルリポジトリ：

自分のパソコンの中に作った、gitリポジトリ。ファイルを足したり消したり編集したりできる。
リモートリポジトリの複製(後述のクローン)としてつくることも、既にあるフォルダを新しいリポジトリにして、gitで管理することもできる。

クローン：

ローカルリポジトリがないときに、リモートリポジトリの内容をそのまま自分のパソコンにコピーすること

2）プルをしてリモートリポジトリと同じ最新の状態を作る

１）の作業は初回のみ必要ですが、２）の作業は何かを変更するときには毎回実施が必要です。

1.プルをクリック

2.プルするブランチが「master」であることを確認し、「プル」を押す。

※masterのことをmainと呼ぶこともあります。メインのブランチやデフォルトブランチとも呼びます。

プル：

リモートリポジトリから（他の人が）アップロードしたコミットをダウンロードして、ローカルリポジトリに取り込むこと
※プルをする理由は「リモートリポジトリとローカルリポジトリを同じ状態にしないと、ファイルを新たにアップロードした時に、他の人が上げたファイルが削除されたりする可能性があるため」です

☆ポイント 「クローンとプルの違い」
大雑把に言えば全てを複製するのか、一部をダウンロードするのかの違いです。
クローンは自分のパソコンにリモートリポジトリをそのまま複製することであり、それに対してプルはリモートリポジトリで変更されたものを自分の（クローン済みの）ローカルリポジトリに反映することです。
クローンは最初だけ作成するもので、プルは毎回修正するときに、他の人が更新したデータをローカルリポジトリにダウンロードし、リモートリポジトリとローカルリポジトリを最新の同じ状態にするとイメージすれば分かりやすいと思います。

3）ブランチを作成する

1.「ブランチ」をクリック

2.「新規ブランチ」に自分が作ったことがわかるような名前を入力して、「ブランチを作成」を押す。

ブランチ：

変更の流れを分岐させて名前を付けること。

☆ポイント 「なぜブランチが必要なのか？」
複数の作業者と別々の作業をしても、作業途中で干渉しないようにするため。
ブランチが一つだけだと、作業途中の変更を途中保存したのが、別の人の作業に影響したりします。あるいは逆に影響を受けたりします。

4）自分のパソコン（ワークツリー）で修正箇所を修正

ローカルリポジトリで自分が修正したい箇所を修正します。背景画像とイラスト画像、HTML・CSSファイルでできている簡易的なLPで説明します。
例えば、LPの人差し指を出している縁ゆかりの画像をファイトポーズの縁ゆかりの画像に変更したいとき。

画像が表示される場所は変えずに、画像だけを変更します。
そのため、HTMLを編集せず、画像の名前を元の画像と同じ名前にして上書き保存します。
※今回はHTMLを修正せず、画像だけを変更しますが、HTMLを修正して、変更後のファイルの名前が表示されるようにすることももちろんできます。

変更後は以下のような画面になります。

ワークツリー：

自分が作業をしているフォルダのこと。

5）修正したファイルをステージに上げる

ローカルリポジトリで修正したら、Sourcetreeに戻ります。

1.「コミット」を押します。

そうすると、自動的に「作業ツリーのファイル」に修正したファイルが表示されます。

2.「全てインデックスに追加」を押し、修正したファイルをステージにあげます。

ステージ（インデックスとも呼ばれる）：

リポジトリへコミットするファイルを仮置きする場所。ステージに上がったファイルがコミットの対象になる。

☆ポイント 「なぜブランチが必要なのか？」
複数の作業者と別々の作業をしても、作業途中で干渉しないようにするため。ブランチが一つだけだと、作業途中の変更を途中保存したのが、別の人の作業に影響したりします。あるいは逆に影響を受けたりします。

☆ポイント 「なぜコミット対象をステージする必要があるのか？」
一気に作業を進めたが、コミットをし忘れた時に、特定のファイルの変更だけをコミットできるから。テキストの変更もレイアウトの変更もしたが、テキストの変更の時点でコミットを忘れた。そんな時に、あとからコミットを分けてテキストだけコミットする、そのあとレイアウトの変更をコミットするなど柔軟に対応するため。

☆ポイント 「ファイルを削除するには？」
リモートリポジトリにあるファイルを削除する時は、ローカルリポジトリにあるファイルを削除したうえで、コミットします。ファイルの削除もリポジトリの変更の一部ととらえます。

6）コミットしてもう一度リモートリポジトリにプッシュする

1.「変更後すぐにプッシュする」に☑をつけ、「コミットメッセージ」に変更の詳細を書きます。

今回は「トップページの写真を変更：人差し指を出している縁ゆかり→ファイトポーズの縁ゆかり」と書きます。※後からみて誰もがわかる状態が望ましいです。

2.「コミット」を押します。

コミット：

セーブポイントを作ること。コミットするとセーブポイントの時点にあとから戻ることができる。

☆ポイント 「いつコミットするの？」
「作業単位」でコミットしてください。ざっくりというとキリが良いところです。
例えばLPの変更で以下のような作業が挙げられます。テキストの変更、トップパネルの写真を変更、レイアウトの変更(写真を縦並びから横に並べるなど) できるだけ細かく分けて作業ごとにコミットすると、レイアウトが崩れた時や何かの変更を戻したい時に作業の履歴が追いやすくなります。

次に、コミットメッセージに変更の詳細を書きましょう。 後から自分が変更を戻したい時や、他のメンバーがコミットで何を変更したか理解できるようにするためです。

7）Backlogでファイルをマージする

Sourcetreeでの作業は以上です。次にBacklogでの作業に移ります。
リモートリポジトリがあるBacklogにログインして、ファイルをアップロードしましょう。

1.画面左のバーから「Git」を選択​

2.「ブランチ」を選択​

3.名前をつけたブランチ名の横にあるプルリクエストの「追加」を選択

4.左を「develop」にして、「プルリクエストの追加」を選択​

5.「マージ」を2回選択​

マージ：

合流の意味で、ブランチを元のブランチにまとめること。メインブランチ（元のブランチ)があって、そこに加えた変更を合流させるイメージ

こうやって管理したファイルなどを、それぞれのお仕事の作法に則って、Webサイトとしてリリースしたりしていきます。全体像を改めて図にすると以下のようになります。

最後に

誰もが最初は初心者ですが、使い慣れてくるとだんだんと学び始めた時のことを忘れるものです。
Gitを使って日が浅い非エンジニアの立場からどこにつまづいたか解説しようと思い記事を作成しました。
Gitの教え方に困っているエンジニアにとって、少しでもお役に立てれば幸いです。