俺とGitHub 完成版

1. 俺とGitHub
2016-10-28 cafe? IKAGAWA DO GitHub勉強会
ふぁらお加藤

2. Profile
Name
ふぁらお加藤 / @PharaohKJ
Hobby
Camera / subculture
Job & Works
PhalanXware (Freelancer)
OCR system com / .NET
ISDB-T MFC / Linux C++
Social Game PHP / Java
ERP+CRM AngularJS / Cordova
Information App AngularJS / CakePHP
Factory Automation .NET

3. ゴール
• バージョン管理システムの仕組みが、いかに「人間によ
る手作業の更新・マージ」を手助けしているかを理解し
、安心してこの作業をツールにまかせることができる。
• git 及び GitHub がどのように運用され、マージ・更新時
に手助けしてくれる機能があるかを知る。
• さらに GitHub がどのようなことを提供しているのかを知
る。
• 今すぐGitHubを使いたくなる。

4. プログラミングをどう定義するか？

5. 書く > 試す > 書く > 試す … 繰り返し

6. 「プログラムを書く」とはどう定義できるか？

7. テキストファイルを追加・編集する

8. さらに単純化して考えると

9. 「新しい行を追加する」「余計な行を削除する」

10. この2つにまで単純に落とし込むことができる

11. 例: 削除行と追加行

12. 「新しい行を追加する」「余計な行を削除する」
これの記録をくりかえせば良い

13. これの記録 = コミット(commit)

14. 書く > 試す > 書く > 試す … 繰り返し
この中で「あ、これで区切りいいな」という
タイミングを記録する

15. さすがに自動で「今、タイミングいいよ」
とはならないので人間がタイミングを決める

16. タイミング
• 機能の実装が完了し、テストが通った。
• 製品としてリリースする。
• リファクタリング、最適化した。
• 見た目を整えた。
• 参照ライブラリを増やした。
• など

17. どうしてタイミングがいいの?
これも人間が文章で記録できる。

18. 改訂履歴、アップデートの記録として使える。
それがコミットメッセージ。

19. コミットの履歴が
たぐれる
ハッシュがついてるのにも注目

20. 「コミット単位」で「行の追加」「削除」を
確認することができます

21. コミットメッセージの利点
• どうして、更新し、タイミングよかったかを記録でき
る。
• コード自体にコメントを入れたら、コメント自体もメ
ンテしないといけなくなる！
• コード自体に改訂履歴を入れたら、改訂履歴だけでコ
ードがうまり、本質からかけ離れる！検索しにくい！
などデメリットだらけ。

22. ここまでのまとめ
• 「行の追加」「行の削除」を管理する。
• 管理するのは「コミット」という単位で管理する。こ
の単位で履歴を確認できる。
• この「コミット」のタイミングは人間が決める。
• 「コード」と「コミットメッセージ」を別に管理する
ことでたくさんのメリットがある。

23. 人間は協力しあわないと生きていけない
共同作業がしたい!

24. 複数人で作ったコードのマージ作業

25. マージをどう定義するか?

26. 共同作業者の「最新版」の「コード」を
1つにする作業?

27. 共同作業者αさんのディレクトリ
共同作業者βさんのディレクトリ
共同作業者θさんのディレクトリ
そして俺のディレクトリを比較すんの?

28. ・・・誰のどれが最新だっけ？

29. まぁ増えている分には問題ないか・・・上書き?

30. 減ってるのは対応できない・・・

31. 各位から「最新版」のファイルをもらって
まともに合成するのは至難の技

32. 各位から「最新のコミット履歴」を
1つにする作業! それが git のマージ (merge)

33. 3-way merge
• CからAのコミットログを取得し、
「増えた行」「減った行」を得る
。
• CからBも同様に。
• 「CからA」 + 「CからB」 = 「D
」とする
• 「D」は「A」+「B」ではない
• よって正しくマージできる

34. つまり、マージでハッキリさせて
おかなければならないのは「起点」

35. 「枝分かれ起点」を作る = ブランチ (branch)

36. コミットがブランチ
ごとに作られてる様子

37. 共同作業者αさんのディレクトリ
共同作業者βさんのディレクトリ
共同作業者θさんのディレクトリ
を比較

38. 共同作業者αさんのブランチ
共同作業者βさんのブランチ
共同作業者θさんのブランチ
の増減を足し合わせてくれるのがマージ

39. ここまでのまとめ
• 「マージ」というのはディレクトリ同士の単純な比較
では無理がある。
• 「起点」を決めて「ブランチ」を作る。
• 各自(自分ももちろん含む)ブランチでコミットしたもの
を「マージ」する。
• そうすれば履歴を足し合わせて新版を作ってくれる。

40. ここまでは基礎知識
やっと GitHub のお話

41. 「コミット」「ブランチ」「マージ」を駆使
しても、やっぱり無理があることがある

42. 単純な行レベルでの競合( conflict )
なのは git が教えてくれる。

43. 製品的、プログラム的におかしい場合、
やはり人間が話し合いで解決することになる。

44. git に話し合いの機能はありません。

45. どうやって話し合いするの？

46. 「メール」「電話」「会議」・・・
どれももちろんアリでしょう。

47. ここで出てくるのが GitHub

48. ユーザーごとに
リポジトリがある

49. プルリクエスト ( pull request )
略してプルリク

50. プル ( pull ) とは、インターネット上の
ブランチを自分のリポジトリにマージすること
( git の機能 )

51. プッシュ ( push ) もあります。
自分のブランチをインターネット上に
押し込むこと ( git の機能 )

52. プルリクの様子

53. このように議論できる

54. プルリクで話し合い超便利。

55. つまり、リポジトリを GitHub において
おけば、プルリクベースで
みんなで共同作業できちゃう。

56. それぞれのユーザーがリポジトリを持ち、
プルリクで共同作業していく。
これが GitHub、ソーシャルコーディング。

57. ここまでのまとめ
• マージがとっても賢くても「コミットログ」だけでは
結局どうしても無理がある。
• 無理を解決するには話し合いをする必用があるが、そ
の場は git は提供してくれない
• GitHubなら「プルリク」で提供してくれる。
• GitHub はユーザーごとにリポジトリをもてるので「プ
ルリク」で共同作業をしていける。

58. プルリクしなきゃ共同作業できないの?

59. そんなことはありません。

60. バグ報告所、ご意見箱、これからやろうとしてい
ること・・・など、置きたくなる。

61. それが GitHub issue

62. issue の様子

63. 便利機能として、プッシュするコミットログに
issue 番号を書いておくといいことがあります

64. close #xxx で
自動クローズもできる

65. issue をエクセルなどで管理してもいいですが、
GitHubを使うことでコミットと密接に自動で関
連できてとても手間がかからず、リンククリック
でコード参照できてとても便利。

66. 最近はこういったビュ
ーも作れてアジャイル?
D&Dで入れ替えできる

67. コードとタスク管理だけじゃなく
開発ドキュメントも置きたい

68. リポジトリごとに wiki が提供されています

69. この wiki もなんと git で管理されています!
履歴など手繰ることができて便利!
(コードとは別リポジトリ)

70. clone this wiki locally

71. ここまでのまとめ
• コードベースじゃない開発に必要なものも提供されて
いる。
• issue ( タスクリスト、ご意見箱みたいなの )が用意さ
れている。
• issue は コミットメッセージ と連携できる。
• wiki も用意されていて、それは git 管理されており、自
分の好きなエディタで書くことができる。

72. さらにさらに成果物をリリースする機能まである

73. リリースノートなども
かける。zipもDLできる
git のタグ ( tag )

74. リリースすると…その製品のウェブページ
作りたくなりますよね？

75. それもあります。
GitHub Pages

76. 特定のブランチが
ウェブページとして公
開

77. 静的なファイルだけで済むものはこれでOK

78. 5374.jp はこれを使って自分のサーバを持つこと
無く、サービスを提供しているようです。
すばらしい。

79. Jekyll ( static page generator )
を使えば凝ったこともできます。

80. でもお高いんでしょう?

81. いえ、無料です。

82. じゃあどうやって稼いでるの!?
エンプラ契約とかもありますが、我々からみると
「秘密のリポジトリ」を作りたくなったら課金
( 2016-10-28現在、 7$/month )

83. オープンな開発基盤としてこれほど
ありがたいものはないですね。

84. 議論もコードもリリースもすべてオープンで。
その文化がここに(現|表)れています。

85. 透明性、すなわち、オープンにしてすすめる文化
それが求められるものに波及していっています

86. 政治・法律もこれ?
http://developers.srad.jp/story/14/06/05/0548216/
より

87. 秘密に使う事例として、出版などにも活用されて
いる事例があります。

88. 他にも push があったら自動でいろいろやる
機能もついてるので、 pdf を作成してレビューを
まわしているとか

89. ここまでのまとめ
• リリースする機能や、pushされたページを表示する機能
もある。
• GitHub はそのオープンにすすめている限り無料で、その
文化を表している。
• このやり方は議論、その過程に透明性が求められる文章
管理にはとってもむいてる。
• 有料プランは秘密のリポジトリで、出版などでも使って
るらしい。

90. このほか
• push されたら自動で何かを動かす ( integrations )
• push されたことを外部サービスに通知できる (
Webhooks )
• コラボレーター、オーガナイゼーションなど共同作業
者を管理したりする機能
• git/GitHub が便利すぎてコミットやブランチが大量発生
し、煩雑にならないようなルール決め ( git flow )

91. まとめ
• git がコミット、ブランチ、マージを管理することを学ん
だ。
• GitHub が git では埋めてくれないコミュニケーションの
部分を担当する機能をたくさん提供してくれることを学
んだ。
• オープンな文化がここに現れていることを知った。
• 私も今日からGitHubを使ってオープンな開発をしたくな
った。

92. ご清聴ありがとうございました
ふぁらお加藤