Subversion to Git

社内勉強会で使用した資料から一部社外に公開出来ないものを取り除いたものです。
間違い等あるかもしれません。

Transcript

1. Subversion to
2. Git の基本とメリットをデモを交えて紹介します。 Git を知らない人が「Git って便利じゃね？」「Git 使いたい！」 と思ってくれることが目標です。 ※ 世の中には Git の情報が溢れているので, Git の基本について細かい説明はしません。 今日の目的
3. Eclipse の Git プラグイン。 最近では Git の基本機能をほぼ利用出来るようになっている。 開発が活発。 EGit GitHub が提供している Windows 向けクライアント。 （特に GitHub に限定したツールではありません） Git の機能を「簡単に」使えるような UI を備えている。 Git の Shell も付属するため、EGit で出来ない操作はコチラを使う。 GitHub for Windows 以下のツールを使います。
4. 最初に：某さんの疑問 どう生産性が上がるのか？ → 履歴の参照や比較, マージが高速に動作するので待ち時間が減少する → ローカルリポジトリが使えるので作業単位が気軽に記録できる → 気軽にブランチが作成出来るのでリファクタリングの敷居が下がる どうプロジェクト運営が楽になるのか？ → 楽になるというよりも運用方法が大きく変わると思います → チームによって運用方法は変わってくると思いますが, 一例をあとで紹介します どう品質向上に役立つのか？ → コミット単位が整理され, 履歴がシンプルになる → チームで Pull Request を活用すれば, コードで会話出来る → GitHub を使えば意味のあるコードが共有出来るのでチーム全体のレベルアップに
5. #1 Git のキホン #2 GitHub のキホン #3 当社 での活用イメージ
6. Git
   　キホン の
7. Git？ ・分散型 バージョン管理システム 　・分散 　・高速 　・強力な並列開発サポート ← git ← subversion ・デファクトスタンダード 　・Subversion の時代は終わりつつある
8. 集中型 (Subversion)
9. 分散型 (Git)
10. 分散型 (Git)
11. 分散型 (Git)
12. リポジトリが分散 記録と公開の分離 ローカルリポジトリを使うので高速 集中型 分散型 と
13. 良いことばかりでもない・・・ ・ファイルがロック出来ない 　→ 設計書（バイナリ）の管理には向いてない ・Subversion と比べると複雑な操作 　→ チームメンバーの教育が必要 　→ エンジニアじゃない人が多いとツラい
14. 基本的な使い方 リモート リポジトリ
15. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ
16. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ checkout ワークツリー
17. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ edit checkout ワークツリー
18. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add edit checkout ワークツリー
19. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add commit edit checkout ワークツリー
20. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add commit push edit checkout ワークツリー
21. 基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add commit push pull fetch edit checkout ワークツリー
22. Demo
23. リビジョン (SHA-1 ハッシュ) commit の コミットの作成者 (Author) コミットの適用者 (Committer) スナップショット (Tree) ひとつ前の Commit (リビジョン)
24. リビジョン (SHA-1 ハッシュ) commit の コミットの作成者 (Author) コミットの適用者 (Committer) スナップショット (Tree) ひとつ前の Commit (リビジョン) 特徴
25. リビジョン (SHA-1 ハッシュ) commit の コミットの作成者 (Author) コミットの適用者 (Committer) スナップショット (Tree) ひとつ前の Commit (リビジョン) 特徴 重要
26. commit 辿れる 辿れる NEW OLD ひとつの Commit から過去を辿ることが出来る！
27. commit master ← 辿れる 辿れる NEW OLD 実はブランチもただの Commit の別名
28. master ← 辿れる 辿れる NEW OLD この状態で Commit したら・・・
29. master ← 辿れる 辿れる NEW OLD この状態で Commit したら・・・ こっち
30. ある Commit から過去（コミットグラフ）を辿ることが出来る commit の ブランチ = 最新の Commit の別名 git で大事なのは Commit よりも Merge
31. Fast-Forward（早送りマージ） merge の Non Fast-Forward（ちゃんとしたマージ） Squash（まとめてマージ） Rebase（歴史をやり直す）
32. Fast-Forward（早送りマージ） merge の Non Fast-Forward（ちゃんとしたマージ） Squash（まとめてマージ） Rebase（歴史をやり直す） 重要ですが 説明すると 長くなるので 今回は省きます
33. merge Local → Local に merge するなら Fast-Forward でも OK の Remote → Local に pull するときは rebase して履歴をシンプルに Local → Remote に push するときは rebase してから merge Remote → Remote に merge するときは Non Fast-Forward つかいかた の
34. merge Local → Local に merge するなら Fast-Forward でも OK の Remote → Local に pull するときは rebase して履歴をシンプルに Local → Remote に push するときは rebase してから merge Remote → Remote に merge するときは Non Fast-Forward つかいかた の ※ トラッキング用のブランチを作るなら rebase する必要は無いですけどね。 ※ rebase は便利だけど落とし穴も・・・ 機能単位で commit を整理したいだけなら merge + squash だけで良いかもしれません。 色々な流派が あるので一概には 決められません
35. Subversion と比較してみる
36. Subversion あるある ① 履歴を参照するのが ツラい
37. 履歴見せてよ
38. 履歴見せてよ あとで仕事するわ〜
39. 履歴見せてよ あとで仕事するわ〜 いやそろそろ見せてよ
40. 履歴見せてよ あとで仕事するわ〜 いやそろそろ見せてよ 仕方ないなぁ・・・
41. 履歴を参照するだけでも一苦労 Subversion では……
42. 履歴を参照するだけでも一苦労 × Subversion では……
43. 履歴を参照するだけでも一苦労 × 時間の無駄 Subversion では……
44. 履歴を参照するだけでも一苦労 ×履歴を 見なくなる 時間の無駄 Subversion では……
45. 履歴を参照するだけでも一苦労 ×履歴を 見なくなる 時間の無駄 品質の低下 Subversion では……
46. Git があるとき！ ローカルリポジトリが あるから高速だね！
47. Git があるとき！ ローカルリポジトリが あるから高速だね！ やっと気軽に 履歴を見れるわー
48. Subversion あるある ② レビュー対象が どれか分からない
49. 「とりあえず」中央リポジトリにコミット Subversion では……
50. 「とりあえず」中央リポジトリにコミット × Subversion では……
51. 「とりあえず」中央リポジトリにコミット × ひとつのチケットに 大量のコミット… Subversion では……
52. 「とりあえず」中央リポジトリにコミット ×履歴が崩壊 ひとつのチケットに 大量のコミット… Subversion では……
53. 「とりあえず」中央リポジトリにコミット ×履歴が崩壊 ひとつのチケットに 大量のコミット… レビュー対象が散乱して 細かいレビューが 難しくなる Subversion では……
54. Git があるとき！ ローカルリポジトリに コミット出来るね！
55. Git があるとき！ ローカルリポジトリに コミット出来るね！ コミットはあとで 整理出来るよ。
56. Git があるとき！ ローカルリポジトリに コミット出来るね！ コミットはあとで 整理出来るよ。 コミットが整理されてるから レビューもしやすいわー
57. $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト
58. $ touch sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト
59. $ touch sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする
60. $ touch sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット
61. $ touch sugoi.rb $ vi sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット
62. $ touch sugoi.rb $ vi sugoi.rb $ git add -u $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット
63. $ touch sugoi.rb $ vi sugoi.rb $ git add -u $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット $ git commit -m ‘added sugoi-feature’ 編集してから再コミット
64. $ git fetch origin origin と同期して……
65. $ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って……
66. $ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って…… $ git merge --squash sugoi-feature $ git commit -m ‘added sugoi-feature’ sugoi-feature を merge して……
67. $ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って…… $ git push origin topic push ! $ git merge --squash sugoi-feature $ git commit -m ‘added sugoi-feature’ sugoi-feature を merge して……
68. $ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って…… $ git push origin topic push ! ※ squash でマージする場合です。 運用次第ですがチームで開発するときはこれじゃ駄目だと思いマス…… きちんとルールを決めて運用しましょう。 $ git merge --squash sugoi-feature $ git commit -m ‘added sugoi-feature’ sugoi-feature を merge して……
69. $ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って…… $ git push origin topic push ! ※ squash でマージする場合です。 運用次第ですがチームで開発するときはこれじゃ駄目だと思いマス…… きちんとルールを決めて運用しましょう。 $ git merge --squash sugoi-feature $ git commit -m ‘added sugoi-feature’ sugoi-feature を merge して…… 普通は master で remote を tracking しつつ、 branch を master で rebase する人が多いと思いマス
70. Subversion あるある ③ さっきのコミット、 ファイルが漏れてた……
71. Subversion では…… おもむろに漏れていたファイルをコミット
72. Subversion では…… おもむろに漏れていたファイルをコミット ×
73. コミットが分散 Subversion では…… おもむろに漏れていたファイルをコミット ×
74. 履歴が崩壊 コミットが分散 Subversion では…… おもむろに漏れていたファイルをコミット ×
75. 履歴が崩壊 コミットが分散 レビューしづらい Subversion では…… おもむろに漏れていたファイルをコミット ×
76. Git があるとき！ 前回のコミットを 訂正すれば良いね！
77. Git があるとき！ 前回のコミットを 訂正すれば良いね！ そもそも整理してから push するけどね
78. $ git add sugoi-spec.rb 漏れていたファイルをステージして……
79. $ git add sugoi-spec.rb 漏れていたファイルをステージして…… $ git commit --amend 前回のコミットを訂正！
80. $ git add sugoi-spec.rb 漏れていたファイルをステージして…… $ git commit --amend 前回のコミットを訂正！ やったね！
81. $ git add sugoi-spec.rb 漏れていたファイルをステージして…… $ git commit --amend 前回のコミットを訂正！ やったね！ ただし・・・既に公開している コミットを訂正してはいけません！
82. Subversion あるある ④ さっきのコミットに 関係の無い 修正が混じってた……
83. Subversion では…… コミットしちゃったし仕方ないよね……
84. Subversion では…… コミットしちゃったし仕方ないよね……
85. Subversion では…… コミットしちゃったし仕方ないよね…… ×
86. Subversion では…… コミットしちゃったし仕方ないよね…… × コミットが散乱
87. Subversion では…… コミットしちゃったし仕方ないよね…… ×履歴の崩壊 コミットが散乱
88. Subversion では…… コミットしちゃったし仕方ないよね…… ×履歴の崩壊 レビューしづらい コミットが散乱
89. Git があるとき！ 前回のコミットを 取り消せば良いね！
90. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき
91. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ……
92. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して……
93. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して…… $ git commit --amend 前回のコミットを訂正！
94. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して…… $ git commit --amend 前回のコミットを訂正！ ワークツリーはそのまま なので……
95. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して…… $ git commit --amend 前回のコミットを訂正！ ワークツリーはそのまま なので…… $ git add sugoi-spec.rb 手元の sugoi-spec.rb を再度ステージして
96. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して…… $ git commit --amend 前回のコミットを訂正！ ワークツリーはそのまま なので…… $ git add sugoi-spec.rb 手元の sugoi-spec.rb を再度ステージして $ git commit -m ‘added sugoi-spec’ コミット！
97. $ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して…… $ git commit --amend 前回のコミットを訂正！ ワークツリーはそのまま なので…… $ git add sugoi-spec.rb 手元の sugoi-spec.rb を再度ステージして $ git commit -m ‘added sugoi-spec’ コミット！ コミットが 分離出来たね！
98. Subversion あるある ⑤ ある機能の開発中に 別の作業を頼まれた……
99. Subversion では…… 今の作業が終わるまで待ってもらえます？
100. Subversion では…… 今の作業が終わるまで待ってもらえます？ ×
101. チェックアウトしよう にも時間がかかる Subversion では…… 今の作業が終わるまで待ってもらえます？ ×
102. 作業が遅延 チェックアウトしよう にも時間がかかる Subversion では…… 今の作業が終わるまで待ってもらえます？ ×
103. 作業が遅延 チェックアウトしよう にも時間がかかる 忘れ去られるかも Subversion では…… 今の作業が終わるまで待ってもらえます？ ×
104. Git があるとき！ 今の作業内容を 一時的に待避すれば 良いね！
105. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！
106. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・
107. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！
108. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始
109. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ 緊急対応中・・・（少々お待ちください） $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始
110. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ $ git checkout bug-1 元のブランチに戻って・・・ 緊急対応中・・・（少々お待ちください） $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始
111. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ $ git checkout bug-1 元のブランチに戻って・・・ $ git stash pop 一時待避していた作業内容を復帰させて bug-1 の対応を続行！ 緊急対応中・・・（少々お待ちください） $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始
112. $ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ $ git checkout bug-1 元のブランチに戻って・・・ $ git stash pop 一時待避していた作業内容を復帰させて bug-1 の対応を続行！ 緊急対応中・・・（少々お待ちください） 並行作業が しやすいね $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始
113. ココまでまとめるとこんな感じ Subversion Git コードの共有 中央リポジトリを介する リポジトリ間で自由 履歴の参照 遅い 速い コミット先 中央リポジトリ ローカルリポジトリ コミットの整理 不可 可 コミットの公開 commit = 公開 push して初めて公開 ブランチの作成 リモートで作成するしかない ローカルで幾つでも作れる マージ 遅い 速い 作業内容の待避 不可 可 ファイルのロック 可 不可 操作 単純 複雑
114. ココまでまとめるとこんな感じ Subversion Git コードの共有 中央リポジトリを介する リポジトリ間で自由 履歴の参照 遅い 速い コミット先 中央リポジトリ ローカルリポジトリ コミットの整理 不可 可 コミットの公開 commit = 公開 push して初めて公開 ブランチの作成 リモートで作成するしかない ローカルで幾つでも作れる マージ 遅い 速い 作業内容の待避 不可 可 ファイルのロック 可 不可 操作 単純 複雑 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
115. GitHub　キホン の
116. ♥
117. Goldman Sachs だって使ってます
118. GitHub の代表的な機能 ① ・リポジトリの管理 　・高機能なリポジトリブラウザ 　・プロジェクト管理機能（Issue, Wiki） 　・プロジェクト情報の可視化（Network, Graphs） 　・Watch, Star（プロジェクトの注目度の指標） 　・Fork（その場で自分用に Fork 出来る） 　・Pull Request（パッチのやりとり）
119. GitHub の代表的な機能 ② ・ダッシュボード 　・News Feed 　・Notifications 　・etc, etc ... ・ユーザーページ 　・Activities 　・Repositories 　・etc, etc ... ・その他 　・Gist, GItHub Pages etc ...
120. GitHub の良いところ ・プロジェクトよりも「ヒト」にフォーカス 　・誰が何をしているのか可視化 　・ちょっとした書き捨てのコードも共有 ・開発者同士のコラボレーションの促進 　・手軽に Fork 　・手軽に Pull Request
121. $$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ github:enterprise $21 / user / month
122. $$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ github:enterprise $21 / user / month ×
123. $$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ $12,000 / 500 user / one-time
124. $$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ $12,000 / 500 user / one-time ◦
125. GitHub Stash リポジトリブラウザ ˕ ◦ Issue ◦ ˕ (JIRA と連携） Wiki ◦ ◦ 可視化 ˕ (Watch, Star, Network, Graphs） △ Fork ◦ ◦ Pull Request ◦ ◦ News Feed ◦ ◦ Notifications ˕ ◦ ユーザーページ ˕ ◦ スニペットの共有 ˕（Gist） × ホスティング ˕（GitHub Pages） × 参照権限の管理 ？ ◦ API ˕ ◦ 色々と細かいところのユーザビリティも含めると 全体的に GItHub の方が常に進んでいるのは否めない・・・
126. GitHub Stash リポジトリブラウザ ˕ ◦ Issue ◦ ˕ (JIRA と連携） Wiki ◦ ◦ 可視化 ˕ (Watch, Star, Network, Graphs） △ Fork ◦ ◦ Pull Request ◦ ◦ News Feed ◦ ◦ Notifications ˕ ◦ ユーザーページ ˕ ◦ スニペットの共有 ˕（Gist） × ホスティング ˕（GitHub Pages） × 参照権限の管理 ？ ◦ API ˕ ◦ 色々と細かいところのユーザビリティも含めると 全体的に GItHub の方が常に進んでいるのは否めない・・・ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
127. GitHub Stash リポジトリブラウザ ˕ ◦ Issue ◦ ˕ (JIRA と連携） Wiki ◦ ◦ 可視化 ˕ (Watch, Star, Network, Graphs） △ Fork ◦ ◦ Pull Request ◦ ◦ News Feed ◦ ◦ Notifications ˕ ◦ ユーザーページ ˕ ◦ スニペットの共有 ˕（Gist） × ホスティング ˕（GitHub Pages） × 参照権限の管理 ？ ◦ API ˕ ◦ 色々と細かいところのユーザビリティも含めると 全体的に GItHub の方が常に進んでいるのは否めない・・・ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ͱ͸͍͑
     4UBTI
     Ͱ΋ ࠷௿ݶඞཁͳػೳ͸ଗͬͯ·͢
128. とりあえず GitHub / Stash を使うとどうなるのか考えてみる
129. ありませんかこんなこと ① コードレビューしたいから ひとまずコミットして〜
130. ありませんかこんなこと ① コードレビューしたいから ひとまずコミットして〜 コミットしました〜
131. ありませんかこんなこと ① コードレビューしたいから ひとまずコミットして〜 コミットしました〜 ・・・これ、 全部リファクタリングして良い？
132. 事前にコードで話し合おう Pull Request を有効に使いましょう
133. 事前にコードで話し合おう Pull Request を有効に使いましょう 議論するための Pull Request もアリだよ
134. ありませんかこんなこと ② ここの処理は面倒だから 他の PJ のコードをコピペしよう
135. ありませんかこんなこと ② ここの処理は面倒だから 他の PJ のコードをコピペしよう 他の PJ で作ったライブラリ にはどんなものがあるんだろう？
136. ありませんかこんなこと ② ここの処理は面倒だから 他の PJ のコードをコピペしよう 他の PJ で作ったライブラリ にはどんなものがあるんだろう？ この PJ で作ったライブラリ、 他の PJ でも使えそうだけど 共有するのが面倒くさい・・・
137. コードを共有しよう Pull Request を使えば上手く 共有出来るかも？
138. コードを共有しよう Pull Request を使えば上手く 共有出来るかも？ 共有ライブラリ をもっと作りたいな！
139. ありませんかこんなこと ③ もうすぐ評価レビューだ・・・
140. ありませんかこんなこと ③ もうすぐ評価レビューだ・・・ 開発チームのあいつ、 何やってるのか分からないんだよな
141. ありませんかこんなこと ③ もうすぐ評価レビューだ・・・ 開発チームのあいつ、 何やってるのか分からないんだよな 自分の成果が可視化されたら 良いんだけどな・・・
142. 「ヒト」にフォーカスを当てよう Stashを使うと 「ヒト」の貢献が 見えてくるかも？
143. 「ヒト」にフォーカスを当てよう Stashを使うと 「ヒト」の貢献が 見えてくるかも？ 個人のナレッジを 共有する文化も 産まれるかもね
144. 「ヒト」にフォーカスを当てよう Stashを使うと 「ヒト」の貢献が 見えてくるかも？ 個人のナレッジを 共有する文化も 産まれるかもね モチベーションが上がって イノベーションが生まれそう
145. 当社 での活用イメージ
146. 基本は A successful git branching model を踏襲 ・中央リポジトリの master はマージ専用 ・中央リポジトリの develop で開発 ・各開発者が中央リポジトリの develop を fork して開発 ・fork → upstream（中央リポジトリ）に Pull Request ・担当者が Pull Request をレビューして Non Fast-Forward でマージ ・リリースしたら master に Non Fast-Forward でマージ
147. fork ベースでの開発フロー company/product master develop monzou/product topic upstream として参照 自分の fork から 本体の develop に Pull Request monzou/product:develop は company/product:develop と同期し, topic は develop で rebase してから push する
148. 中央リポジトリのブランチで開発しても良いけど・・・ ・誤 push が発生する可能性があるので fork の方が安全 ・自分用のリモートリポジトリがある方が大きなミスは少なそう ・但し常に fork 元に同期しないといけないという手間が発生する ローカルの master を upstream の 追従用にして, 常に master で rebase するようにする
149. #1. Stash / GitHub で company/product を fork 開発者の作業フロー ①
150. #1. Stash / GitHub で company/product を fork #2. fork したリポジトリをローカルに clone $ git clone git://company.com/company/product.git 開発者の作業フロー ①
151. #1. Stash / GitHub で company/product を fork #2. fork したリポジトリをローカルに clone $ git clone git://company.com/company/product.git 開発者の作業フロー ① #3. 開発用のトピックブランチを作成 $ git checkout -b topic develop
152. #1. Stash / GitHub で company/product を fork #2. fork したリポジトリをローカルに clone $ git clone git://company.com/company/product.git 開発者の作業フロー ① #3. 開発用のトピックブランチを作成 $ git checkout -b topic develop #4. トピックブランチで開発・テスト $ git add . $ git commit -m ‘added topic’
153. 開発者の作業フロー ② #5. fork したリポジトリの develop を fork 元リポジトリと同期 $ git checkout develop $ git pull upstream develop $ git push origin develop
154. #6. トピックブランチを develop で rebase $ git checkout topic $ git rebase develop 開発者の作業フロー ② #5. fork したリポジトリの develop を fork 元リポジトリと同期 $ git checkout develop $ git pull upstream develop $ git push origin develop
155. #6. トピックブランチを develop で rebase $ git checkout topic $ git rebase develop 開発者の作業フロー ② #7. コミットを整理する（必要であれば） $ git rebase -i #5. fork したリポジトリの develop を fork 元リポジトリと同期 $ git checkout develop $ git pull upstream develop $ git push origin develop
156. #6. トピックブランチを develop で rebase $ git checkout topic $ git rebase develop 開発者の作業フロー ② #7. コミットを整理する（必要であれば） $ git rebase -i #8. トピックブランチをリモートに push する $ git push origin topic #5. fork したリポジトリの develop を fork 元リポジトリと同期 $ git checkout develop $ git pull upstream develop $ git push origin develop
157. 開発者の作業フロー ③ #9. Stash で Pull Request を送る monzou/product:topic → company/product:develop に Pull Request
158. 開発者の作業フロー ③ #9. Stash で Pull Request を送る monzou/product:topic → company/product:develop に Pull Request #9b. Pull Request が却下されたら修正して再 push #9c. Pull Request が放置されていたら mention を書いてコメント @leader この Pull Request を確認してください
159. 開発者の作業フロー ③ #9. Stash で Pull Request を送る monzou/product:topic → company/product:develop に Pull Request #9b. Pull Request が却下されたら修正して再 push #9c. Pull Request が放置されていたら mention を書いてコメント @leader この Pull Request を確認してください Stash も GitHub も コメント欄で @mention を 飛ばすことが出来るよ
160. 開発者が Pull Request を送ったら・・・ #1. レビュー担当者が Pull Request マージして内容を確認 $ git remote add monzou git://company.com/monzou/product.git $ git fetch monzou $ git checkout develop $ git merge --no-ff monzou/topic -m ‘Merged in topic (pull request #1)’
161. 開発者が Pull Request を送ったら・・・ #1. レビュー担当者が Pull Request マージして内容を確認 $ git remote add monzou git://company.com/monzou/product.git $ git fetch monzou $ git checkout develop $ git merge --no-ff monzou/topic -m ‘Merged in topic (pull request #1)’ #2. レビュー担当者がリモートにマージ結果を push $ git push origin develop
162. 開発者が Pull Request を送ったら・・・ #1. レビュー担当者が Pull Request マージして内容を確認 $ git remote add monzou git://company.com/monzou/product.git $ git fetch monzou $ git checkout develop $ git merge --no-ff monzou/topic -m ‘Merged in topic (pull request #1)’ #2. レビュー担当者がリモートにマージ結果を push $ git push origin develop #3. Jenkins がマージされた develop ブランチをビルド
163. 予想される問題 レビュー待ちの Pull Request が滞留する ・Pull Request が滞留するとコンフリクトがどんどん増える ・レビュー担当者を分散する ・mention を有効活用して早めに担当者に通知する ・細かい修正は最悪 Pull Request せずに直接開発者がマージしてしまう
164. 予想される問題 レビュー待ちの Pull Request が滞留する ・Pull Request が滞留するとコンフリクトがどんどん増える ・レビュー担当者を分散する ・mention を有効活用して早めに担当者に通知する ・細かい修正は最悪 Pull Request せずに直接開発者がマージしてしまう Pull Request 送信時に検出されない不具合が増える ・Pull Request 送信時のブランチを事前にビルドしないと分からない ・でも Pull Request 毎に Jenkins にビルドさせるのは難しい・・・ ・こまめに対応するしかない
165. まとめ ローカルリポジトリ → 個人の生産性向上 Stash + Pull Request→ チームの生産性・品質向上 Stash で「ヒト」にフォーカス → エンジニアの交流活性化 Stash でコード共有の活性化 → 開発効率の向上
166. Any Questions ?