３月から独学で勉強し続けて、最近やっとgitをチーム開発で扱うようになれたので、
もし自分が最初からgitを勉強しなおすとしたらどういう手順でやれば覚えやすいか、
抵抗感なく取り組めるかを記事に残しておこうと思ったのと、
初心者に教える予定のある方にどうやって理解したか聞かれたのがきっかけでこの記事を書くに至りました。
はじめに
学習したてのころは、gitとGithubってあるけど、
どうして二つも名前があるの？と疑問にすら思いませんでしたが、
完全に別物であるということを理解した上でgitの学習に取り組んだ方が
スムーズではないかと思います。
なのでざっくりでいいので概要を知り、二つの違いを知り、gitの重要性を知ってもらった上で、
実際に触るといった方が頭に入ってくると思います。
- Gitってなあに？
- GitとGithubの違い
- どうして履歴を管理するの？
- まずは一人でGitを使ってGithubにデータを上げてみましょう！
- ブランチを切るということを覚えよう！
- 今度は二人以上で練習をしてみよう！
- コンフリクト解消まで一通りできるようになってみよう！
というような目次の流れで紹介しようと思います。
■使用教材のおすすめ
サル先生のGit入門
https://backlog.com/ja/git-tutorial/
progate（有料）
https://prog-8.com/languages/git
チュートリアル（中級者向け）
http://k.swd.cc/learnGitBranching-ja/
1.Gitってなぁに？
Gitとは、プログラムのコードの変更履歴を管理する分散型のバージョン管理システムのことです。
分散型、難しそうな言葉が出てきました。
https://wa3.i-3-i.info/word12358.html
わかりそうでわからないによると‥分散型のシステムとは、
システムの分類の一つであり、
やるべきお仕事を複数のコンピュータで分担してやる形態になっているシステムのこと。
分散型の何がいいの？
分散システムのメリットは、チームプレーのメリットと同じです。
1. みんなで分担できるので、一人ひとりの負担が小さい
2. 仲間を増やせば、いろんなことができる
3. ケガをしても影響範囲が限定的
デメリットは
大人数でわちゃわちゃしているので管理が大変という事くらいです。
はい、ここまでで分散型のシステムについては理解が出来たかと思います。
バージョンってなあに？
説明しろといわれたら、知ってるようで知らないなぁと思う人もいると思います。
https://wa3.i-3-i.info/word11073.html
バージョンは、そいつの年齢みたいなものです。
変更前のやつと区別するために着ける数字や文字のことです。
まとめるとつまり何なの？
絵で例えますね。壁画などを想像してください。
膨大な線や色を、いろんな人で手分けして、
線を加えていき、段階的に色をどんどん塗り重ねていき、その塗られた状態（レイヤ）の履歴を
監督さんが管理しているんですね。
手戻りしたいよ～って時に監督さんに言うと、戻してくれたりします。
その監督がGitです。
プログラムのコードを複数人で作業し、その履歴を管理するのがGit。
これが分散型のバージョン管理システムというわけです。
ふわっとでもつかめて頂けると嬉しいです。
GitとGithubの違い。
Githubって何よ？
このGitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデザインデータなど)を保存、公開することができるようにしたウェブサービスの名称です。
GitHubはGitHub社という会社によって運営されており、
個人・企業問わず無料で利用することができます。
GitHubに作成されたレポジトリは、基本的にすべて公開されますが、有料サービスを利用すると、
指定したユーザーからしかアクセスができないプライベートなレポジトリを作ったりすることができます。
レポジトリという言葉が出てきました。
リポジトリレポジトリという言われ方がしますが二つは同じ意味です。
リポジトリは、プログラムなり設定情報なり、何等かの「保管場所」を
カッコつけていった表現です。
リポジトリという言葉が出てきたら、保管場所なんだなあと思ってください。
GitとGithubの違いは
Gitは管理システムで、Githubは「それをみんなでシェアできたらいいね！」というサービスです。
どうしてバージョン管理をするの？
詳しくはこちらの記事がおすすめです。
https://qiita.com/MasayaMizuhara/items/9503eb66d3125d8c5f41
１．以前の状態に戻る
間違えちゃった！というときは当然元に戻したいですよね。
バージョン管理ができるから、手戻りが可能になるんですよね。
２．変更履歴を調査する
せっかくここまで作ったのに１から作り直しかぁ‥
なんて経験をしたときはありませんか？
ある地点からやり直しが出来たら楽ちんですよね。
共同で誰かと何かを作っているとしてその人のやってる作業を、ずっと監視はできません。
バージョン管理システムでは、その誰かが「何をどう」変えたかがわかるわけです。
変更された各場所を確認して、「おっそこは違うよ！」と思えば、
そこだけを取り消したり、な～んてことも出来るようになるわけですね！
便利ですね！
３．プロジェクトを管理する、４．変更者と変更理由を知る
プロジェクト開発においてはファイルは一つではありませんよね。
複数のファイルやディレクトリが重なって一つのプロジェクトとなるわけです。
例えば、あるプロジェクトで問題が起こったとしましょう。
A君が任されたファイルの中に書いた一文、
例えば
system.out.println('こんにちは');
この文章が実は「こんにちは」ではなく「こんばんは」としたかった時に、
何も言わずに変えてしまっては、A君に何を変えたの！？といちいち聞かなくてはなりません。
それは面倒なのでＡ君は
"「こんにちは」から「こんばんは」に出力文字を変更しました。"
などを記録に残しておけば、Ａ君の上司は
ほうほう、ここ変更したのね、と知れるわけです。
まとめ
・以前の状態に戻る
・変更履歴を調査する
・プロジェクトを管理する
・変更者と変更理由を知る
これがバージョン管理をするための目的です。
まずは一人でGitを使ってGithubにデータを上げてみましょう！
ここで、やっとおすすめの教材の登場です。
https://backlog.com/ja/git-tutorial/intro/01/
こちらのGitの基本を読んでみましょう。
ふわっと概要を理解したあなたなら、
「ふむふむ、そういうことね」とすらすら読めると思います。
一通りサル先生を読み終わったら次は実際に手を動かしてみましょう。
ここでやっとコードに触れてもらいます。長かったですね。
はいここで、progateさんに登場して頂きます。
ここでgit init～git pushまでが出来れば、一人でGitにデータを上げるということはできたと言っても過言ではないでしょう。
以下おそらく出てくるであろうコマンド
git init
git add .
git status
git commit -m "index.htmlにheaderを追加しました"
git push -u origin master
コマンドの説明はprogateさんに預けます。笑
リポジトリにpush（ファイルを上げる）
リポジトリからクローン（ファイルをローカル上に複製する）
リモートリポジトリからプルする（ファイルの内容をリポジトリからそのまま上書きする）
ここまで出来れば一人でGitが使えるようになっています。
ブランチを切るということを覚えよう！
ブランチとは
ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。
その名の通り枝です。
あまり自分は覚えてはいないのですが、
progateでこんなコマンド出てきませんでしたか？
git branch
git checkout -b feature/add-header-logo
progateさんを非難するわけではありませんが、一人で上げるということを教えてくれましたが、
二人以上のgit操作にはあまり触れてくれていません。
共同開発となるとまた話が変わってきます。
共同開発において、
masterにいきなりpushしてはいけません
大事なことなのでもう一度言います。
masterにいきなりpushしてはいけません。
なんで～？って思いますよね。
共同開発におけるmasterブランチとは、成果品をつくる上流工程のことです。
たとえ話です、あなたが子供に料理をてつだってもらっているとします。
あなたはカレーを作りたいとしましょう。
カレーを作るのにも工程がありますね。
野菜を切る→野菜を鍋にいれる→野菜を煮込む（または炒める？）→ルー溶かし茹でる→完成！
マスターはこの全ての工程を管理してカレーを完成させます。
あなたはそれぞれの子供に作業を分担しています。
・野菜を切るかかりの子供（cut）
・野菜を鍋に入れるかかりの子供（through）
・みんながちゃんとできてるか確認する係の子供(attend)
（（）内をブランチ名としますね。）
この子供たちがそれぞれのブランチです。
確認係は当然野菜を切るかかりの子供を待っていますが、
野菜を鍋に入れるかかりの子供はわからずに、
切る前のそのままのにんじんをなべに放り込もうとしました。
確認係は止めるわけです。
「いきなり鍋に入れちゃダメだよ～」
野菜を切るかかりの子供が野菜を切れてるか確認してもらい、
それがOKなら野菜を鍋に入れるということが出来るようになります。
雰囲気だけでも伝わりましたでしょうか？
https://backlog.com/ja/git-tutorial/stepup/01/
サル先生にもう一度登場して頂きましょう。
この枝の図が分かりやすいです。
マスターから分岐し、それぞれの工程が終わったうえで再度マスターに合流しています。
ブランチを切ることが何となくお分かりになってくれていると嬉しいです。
6. 今度は二人以上で練習をしてみよう！
これは自分以外にもう一人登場人物が必要になってくるのですこし難しいのですが、
どうしてもという方はアカウントをもう一つつくって実際にやってみると分かりやすいかと思います。
マスターブランチと、デベロップブランチに分かれてやってみましょう。
ファイルは何でもよいです。
ここでやる練習は
・プルリクエスト
・マージ
になります。
チュートリアル
http://k.swd.cc/learnGitBranching-ja/
7.コンフリクトを解消しよう！
ここからは少し上級編になります。
のでたくさん良い記事があるので、気になる方はそちらをご覧になってください。
（短めになってしまって申し訳ないです。笑
おわりに
最後の方説明が雑になってしまいましたが、いかがでしたでしょうか。
Git、Githubの違いも理解し、二人以上での開発が出来るようになれば、
あとは細かいコマンド覚えていくだけで楽になります。
ここまで稚拙な文章を読んでいただいて有難うございました。