githubの社内外の一般説明会用

1. GitHubの入門
を読む前に読む入門書

2. この作品は非エンジニア向けに作られており、
複雑な内容はかなり省略しています。
この作品はノンフィクションであり、実在する人物、
団体等とは深く関係しています。

3. 最初に質問をします。
GitHubとはなんでしょうか？

4. GitHubとは
・ウェブベースのソース共有サービス（プロジェクト）
・gitによるバージョン管理できる。
・GitHub社によって運用される
・https://github.com/

5. ということはつまり
Git と GitHubは別物である。

6. ちくわとちくわぶほど違います！！

7. もっと砕いてみた
Git + Hub ＝ GitHub
・Git : バージョン管理システム
・Hub ：ネットワーク装置
バージョン管理＋ネットワークという英語的な語呂合わせ

8. gitとは
・分散型バージョン管理システム
・作成者 : linus torvalds
Subversionなんか使い物にならないから作ったよ

9. そもそもバージョン管理とはなに？

10. たとえばある学校に名簿があるとしましょ
毎年、学生が入れ替わるので
現在に在籍中の学生の情報が載っています
たとえば今は２０１６年なので
２０１６年に在籍中の学生情報が入ってます。
これを最新化と呼びます。

11. ところで
という要望があった場合にどうしますか？
２０１２年に卒業した学生一覧を出せますか？

12. 答えは（常に情報が最新化されているため）
「できません」

13. ここで毎年の名簿があれば
解決できます。
この過去分のことをシステムでは履歴と呼ぶ。
・ヒストリー、history、履歴

14. つまり
バージョン ＝ 履歴
バージョン管理 ＝ 履歴管理
である。

15. 用語説明：リポジトリ（repository）
・リポジトリとは履歴そのものを保持しているシステム
→ 各バージョンを持っているデータベース
・上記の学校から例えるなら
各年度別の名簿をもっている書庫

16. バージョン管理ができれば
・本番リリースでしくじった
→ 昨日の履歴に戻せばいい
・誰かが修正したのが間違った修正であった
→ 修正前のバージョンにもどせばいい
などなどができる。

17. バージョンの表記はシステムによって違う
名簿 CVS SVN GIT
年度表記 バージョン リビジョン ハッシュ
2016年度 1.1 1102 ee3301a
GitはHASHを表記する。

18. Gitは分散型バージョン管理システムです。
・バージョン管理はわかった。
・では、分散型とはなんでしょ？
ここで振り返り

19. 分散型の対義は集約型
集約型の代表格といえばSVN
SVNは以下の特徴を持つ
・リポジトリはサーバーのみ
・クライアントはファイルはあるが、
リポジトリはもってない。
・本体サーバーの影響をみんなが受ける
・ネットができないと履歴も見れない

20. 対して分散型とは
・みんながそれぞれのリポジトリを持っている
・特定サーバーに問題があっても
自身のリポジトリには影響しない
・ネットができなくても履歴が見える

21. 要約
メリット
・他人に影響せずに自身のバージョン管理できる
・ネットワークなしでも管理できる。
デメリット
・断片化により最新のソースがわかりづらい

22. くどいようだが
・Git と GitHubは別物
・GitHub上の共有されたソースコードは
Gitを使って使用することができる。

23. では、実際にGitHubでバージョン管理は
どんな感じでしょう

24. と詳細を見る前に
バージョン管理の基本知識に触れてみよ

25. 基本的な流れ
A君がいます。
リポジトリ
１.リポジトリから最新のファイルを取り出し て
A君がいます。
B君もいます。
ファイルA
３。システムに取り組む
2.ファイルを適宜に修正して
この最新のファイルをローカルに
取り出すことをgitではフェチ（fetch）と呼ぶ
この取り組む行為を gitではコミット
（commit）と呼ぶ

26. でも共同作業するので他の誰かも作業をする
リポジトリ
A君がいます。
B君もいます。
2.ファイルをコミットしようとしたら 誰かが修正していてそのまま
ではコミットできない 。
A君がいます。
１。この時に最新ファイルを取り出して修正した14:00
タイトル：出席確認
----
A君がいます。
16:00
タイトル：出席確認
----
A君がいます。
B君もいます。
3.変更内容を取り組んでファイルに反映し自
身の修正内容を追加する。
このお互いの修正内容を反映することを
gitではマージ（merge)と呼ぶ
4.これで無事にコミット

27. でもいつもうまくは行かない
リポジトリ
A君がいます。
B君もいます。
2.修正して反映しようとしたらまったく同じファイル、同じ箇所に
誰かが修正を加えている。
この場合もマージする必要があるが、
実は先ほどのシートでのマージは同じ箇所ではないので
gitが自動でマージをやってくれたが、
この場合は人間が手動でマージせざるを得ない。
A君がいます。
１。取り組んで
A君がいます。
C君がきたよ。
14:00
16:00
ああ、面倒くさいことになった
この場合をバージョン管理システムでは 競合（conflict)と呼びます。

28. 先ほどはファイル１個を例えたが
実際にはいろんなファイルを修正して
取り込めないとか、手動マージで時間がか
かる場合などがあります。
→ そんなあなたのために

29. ブランチ(branch)を切りましょ
・ブランチとはリポジトリの中の流れの分岐である。
・Gitでリポジトリを作ると最初はmasterのみになる。
・ブランチを作ってそこにコミットすることで
masterには影響せずに変更ができる。
・ブランチによって自身の修正分が明確になる。
・ぶっちゃけブランチとはなにかあった時の保険（リスク回避）なのだ。

30. とまあ、これらのことを頭にいれて
GitHubでの作業に触れてみましょ

31. 一般的なワークフロー（作業者の環境で作業編）
本体のリポジトリ
作業者（自身）の
GitHubアカウント
作業者のPC
1.fork
2.clone
3.branch & checkout
5.commit6.push
4. 作業
ざっくりこんな感じで作業します。
ここまでは自身のアカウントまでしか影響しない。

32. 一般的なワークフロー（本体へ反映編）
本体のリポジトリ
作業者（自身）の
GitHubアカウント
作業者のPC
9.push
8. rebase
自身の作業分を本体のリポジトリに反映するフロー
ここからは他人のリポジトリにも影響 される。
7. pull
10. pull request

33. 1.fork
・これはGitHubの用語であり、Gitには存在しない機能。
・他人のGitHubアカウントから作られているプロジェクトを
自身のGitHubにコピーすることを意味する。
・リンクではなく完全なコピーなので
もはや本体とはまったく別のものになる。
（たからといって中身が変わるわけではない。
ファイルのコピーと同じ）

34. 2.clone
・Gitの機能
・生物学のクローンと意味的に同じ
・自身のGitHubアカウント上のリポジトリをベースで
ローカルに内容が同じのリポジトリを生成する。
・リモート上のリポジトリとローカルのリポジトリはリンクはされているが、
お互いに別のリポジトリとして存在する。

35. 3.branch & checkout
・両方Gitの機能
・branchを切ってcheckoutをする。
（Gitのcheckoutコマンドに-bオプションをつけることで両方同時にできる。)
・ローカルのリポジトリ上にブランチが切られる。
・checkoutはローカルのファイルをそのブランチの内容に変更すること

36. 4.作業
・ファイルの追加、修正、削除などなど
以上

37. 5.commit
・リポジトリにコミットする。
・ここでのコミットは自身のローカルのリポジトリにコミットするだけで
リモート上には反映されない。
・逆に言えばローカルに反映されるだけなので、
気にせずにガンガンコミットしよう
（変なことをやっても全部履歴に残るので安心だ！）

38. 6.push
・ローカルのコミット分を
自身のGitHubアカウントのリモートリポジトリに反映する。
・つまりpushする前まではコミットしても
サーバー側のリポジトリには反映されない
・というのはpushする前はソースの共有もできない

39. 7.pull
・pull とは fetch + mergeのこと
・forkして自身のアカウントにあるのは完全に別のものなので、
本体からの変更分など最新版を自身のリポジトリに取り組む必要がある。
（特に自分の修正分をpull request送る前には必ず必要）
・競合がなければ自動で終わるのでコマンド打って終了だが、
競合が出たら、、、多分地獄絵

40. 8.rebase
・rebaseも根幹はmergeではあるが、git上ではmergeとは扱いがちょっと違う
・普通にマージした場合はその分のコミットの履歴もすべて取り組む
リベースする場合は履歴が綺麗に一つにまとまって一つのコミット分で扱う
・システム的にはmergeでもrebaseでも結果的には同じである。
・ただ、github上でpull requestを送る場合、履歴が整理されることになるので
レビューしやすく、煩雑なコミット後でも見逃す心配がなくなる。

41. 9.push
・最新化したものと自身の修正分を反映して、
リモートリポジトリにプッシュする。
・プッシュの内容は上記シートと同様

42. 10.pull request
・これはgitではなく、githubの用語
・自身のリポジトリから他人のリポジトリに差分を取り組む依頼を出す。
・出したpull requestは自動でイシュー(issue)化されて処理される。
・レビューなどを行い、不備があれば差し戻したり、
無事に取り組めたらクローズされたりなど、issueの処理はredmineのに似てる

43. 大体は以上の手順で作業します

44. 省略したもの
・GitHubの初期設定
・詳細なGitのコマンド
・GUIツール（SourceTreeなど）の使い方
・競合が出た場合の実際の対応ノウハウ
・ほかにここで紹介してないgitのコマンド（cherrypickなど）
などなどは説明したいが、ページが足りないので省略する。
（フェルマーの最終定理か！！）

45. 番外編：forkせずにpull requestするには
・ここではforkする方法を紹介したが、実はforkせずにpulll reqできる方法もある。
・詳細はここを参考にする。
https://help.github.com/articles/using-pull-requests/
・いくつかの理由でプロジェクトで導入する気はないので説明も割愛する