Tweet
Tweet

Slide 1

Slide 1 text

Subversion to

Slide 2

Slide 2 text

Git の基本とメリットをデモを交えて紹介します。 Git を知らない人が「Git って便利じゃね？」「Git 使いたい！」 と思ってくれることが目標です。 ※ 世の中には Git の情報が溢れているので, Git の基本について細かい説明はしません。 今日の目的

Slide 3

Slide 3 text

Eclipse の Git プラグイン。 最近では Git の基本機能をほぼ利用出来るようになっている。 開発が活発。 EGit GitHub が提供している Windows 向けクライアント。 （特に GitHub に限定したツールではありません） Git の機能を「簡単に」使えるような UI を備えている。 Git の Shell も付属するため、EGit で出来ない操作はコチラを使う。 GitHub for Windows 以下のツールを使います。

Slide 4

Slide 4 text

最初に：某さんの疑問 どう生産性が上がるのか？ → 履歴の参照や比較, マージが高速に動作するので待ち時間が減少する → ローカルリポジトリが使えるので作業単位が気軽に記録できる → 気軽にブランチが作成出来るのでリファクタリングの敷居が下がる どうプロジェクト運営が楽になるのか？ → 楽になるというよりも運用方法が大きく変わると思います → チームによって運用方法は変わってくると思いますが, 一例をあとで紹介します どう品質向上に役立つのか？ → コミット単位が整理され, 履歴がシンプルになる → チームで Pull Request を活用すれば, コードで会話出来る → GitHub を使えば意味のあるコードが共有出来るのでチーム全体のレベルアップに

Slide 5

Slide 5 text

#1 Git のキホン #2 GitHub のキホン #3 当社 での活用イメージ

Slide 6

Slide 6 text

Git 　キホン の

Slide 7

Slide 7 text

Git？ ・分散型 バージョン管理システム 　・分散 　・高速 　・強力な並列開発サポート ← git ← subversion ・デファクトスタンダード 　・Subversion の時代は終わりつつある

Slide 8

Slide 8 text

集中型 (Subversion)

Slide 9

Slide 9 text

分散型 (Git)

Slide 10

Slide 10 text

分散型 (Git)

Slide 11

Slide 11 text

分散型 (Git)

Slide 12

Slide 12 text

リポジトリが分散 記録と公開の分離 ローカルリポジトリを使うので高速 集中型 分散型 と

Slide 13

Slide 13 text

良いことばかりでもない・・・ ・ファイルがロック出来ない 　→ 設計書（バイナリ）の管理には向いてない ・Subversion と比べると複雑な操作 　→ チームメンバーの教育が必要 　→ エンジニアじゃない人が多いとツラい

Slide 14

Slide 14 text

基本的な使い方 リモート リポジトリ

Slide 15

Slide 15 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ

Slide 16

Slide 16 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ checkout ワークツリー

Slide 17

Slide 17 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ edit checkout ワークツリー

Slide 18

Slide 18 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add edit checkout ワークツリー

Slide 19

Slide 19 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add commit edit checkout ワークツリー

Slide 20

Slide 20 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add commit push edit checkout ワークツリー

Slide 21

Slide 21 text

基本的な使い方 clone ローカル リポジトリ リモート リポジトリ ステージ add commit push pull fetch edit checkout ワークツリー

Slide 22

Slide 22 text

Demo

Slide 23

Slide 23 text

リビジョン (SHA-1 ハッシュ) commit の コミットの作成者 (Author) コミットの適用者 (Committer) スナップショット (Tree) ひとつ前の Commit (リビジョン)

Slide 24

Slide 24 text

リビジョン (SHA-1 ハッシュ) commit の コミットの作成者 (Author) コミットの適用者 (Committer) スナップショット (Tree) ひとつ前の Commit (リビジョン) 特徴

Slide 25

Slide 25 text

リビジョン (SHA-1 ハッシュ) commit の コミットの作成者 (Author) コミットの適用者 (Committer) スナップショット (Tree) ひとつ前の Commit (リビジョン) 特徴 重要

Slide 26

Slide 26 text

commit 辿れる 辿れる NEW OLD ひとつの Commit から過去を辿ることが出来る！

Slide 27

Slide 27 text

commit master ← 辿れる 辿れる NEW OLD 実はブランチもただの Commit の別名

Slide 28

Slide 28 text

master ← 辿れる 辿れる NEW OLD この状態で Commit したら・・・

Slide 29

Slide 29 text

master ← 辿れる 辿れる NEW OLD この状態で Commit したら・・・ こっち

Slide 30

Slide 30 text

ある Commit から過去（コミットグラフ）を辿ることが出来る commit の ブランチ = 最新の Commit の別名 git で大事なのは Commit よりも Merge

Slide 31

Slide 31 text

Fast-Forward（早送りマージ） merge の Non Fast-Forward（ちゃんとしたマージ） Squash（まとめてマージ） Rebase（歴史をやり直す）

Slide 32

Slide 32 text

Fast-Forward（早送りマージ） merge の Non Fast-Forward（ちゃんとしたマージ） Squash（まとめてマージ） Rebase（歴史をやり直す） 重要ですが 説明すると 長くなるので 今回は省きます

Slide 33

Slide 33 text

merge Local → Local に merge するなら Fast-Forward でも OK の Remote → Local に pull するときは rebase して履歴をシンプルに Local → Remote に push するときは rebase してから merge Remote → Remote に merge するときは Non Fast-Forward つかいかた の

Slide 34

Slide 34 text

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 だけで良いかもしれません。 色々な流派が あるので一概には 決められません

Slide 35

Slide 35 text

Subversion と比較してみる

Slide 36

Slide 36 text

Subversion あるある ① 履歴を参照するのが ツラい

Slide 37

Slide 37 text

履歴見せてよ

Slide 38

Slide 38 text

履歴見せてよ あとで仕事するわ〜

Slide 39

Slide 39 text

履歴見せてよ あとで仕事するわ〜 いやそろそろ見せてよ

Slide 40

Slide 40 text

履歴見せてよ あとで仕事するわ〜 いやそろそろ見せてよ 仕方ないなぁ・・・

Slide 41

Slide 41 text

履歴を参照するだけでも一苦労 Subversion では……

Slide 42

Slide 42 text

履歴を参照するだけでも一苦労 × Subversion では……

Slide 43

Slide 43 text

履歴を参照するだけでも一苦労 × 時間の無駄 Subversion では……

Slide 44

Slide 44 text

履歴を参照するだけでも一苦労 ×履歴を 見なくなる 時間の無駄 Subversion では……

Slide 45

Slide 45 text

履歴を参照するだけでも一苦労 ×履歴を 見なくなる 時間の無駄 品質の低下 Subversion では……

Slide 46

Slide 46 text

Git があるとき！ ローカルリポジトリが あるから高速だね！

Slide 47

Slide 47 text

Git があるとき！ ローカルリポジトリが あるから高速だね！ やっと気軽に 履歴を見れるわー

Slide 48

Slide 48 text

Subversion あるある ② レビュー対象が どれか分からない

Slide 49

Slide 49 text

「とりあえず」中央リポジトリにコミット Subversion では……

Slide 50

Slide 50 text

「とりあえず」中央リポジトリにコミット × Subversion では……

Slide 51

Slide 51 text

「とりあえず」中央リポジトリにコミット × ひとつのチケットに 大量のコミット… Subversion では……

Slide 52

Slide 52 text

「とりあえず」中央リポジトリにコミット ×履歴が崩壊 ひとつのチケットに 大量のコミット… Subversion では……

Slide 53

Slide 53 text

「とりあえず」中央リポジトリにコミット ×履歴が崩壊 ひとつのチケットに 大量のコミット… レビュー対象が散乱して 細かいレビューが 難しくなる Subversion では……

Slide 54

Slide 54 text

Git があるとき！ ローカルリポジトリに コミット出来るね！

Slide 55

Slide 55 text

Git があるとき！ ローカルリポジトリに コミット出来るね！ コミットはあとで 整理出来るよ。

Slide 56

Slide 56 text

Git があるとき！ ローカルリポジトリに コミット出来るね！ コミットはあとで 整理出来るよ。 コミットが整理されてるから レビューもしやすいわー

Slide 57

Slide 57 text

$ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト

Slide 58

Slide 58 text

$ touch sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト

Slide 59

Slide 59 text

$ touch sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする

Slide 60

Slide 60 text

$ touch sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット

Slide 61

Slide 61 text

$ touch sugoi.rb $ vi sugoi.rb $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット

Slide 62

Slide 62 text

$ touch sugoi.rb $ vi sugoi.rb $ git add -u $ git checkout -b sugoi-feature スゴイ機能開発用のブランチをつくってチェックアウト $ git add . スゴイ機能用のファイルをステージする $ git commit -m ‘とりあえずスゴイ機能のベースを追加 ’ スゴイ機能用のファイルを一旦ローカルリポジトリにコミット

Slide 63

Slide 63 text

$ 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’ 編集してから再コミット

Slide 64

Slide 64 text

$ git fetch origin origin と同期して……

Slide 65

Slide 65 text

$ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って……

Slide 66

Slide 66 text

$ git fetch origin origin と同期して…… $ git checkout -b topic origin/master マージ用のブランチを作って…… $ git merge --squash sugoi-feature $ git commit -m ‘added sugoi-feature’ sugoi-feature を merge して……

Slide 67

Slide 67 text

$ 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 して……

Slide 68

Slide 68 text

$ 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 して……

Slide 69

Slide 69 text

$ 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 する人が多いと思いマス

Slide 70

Slide 70 text

Subversion あるある ③ さっきのコミット、 ファイルが漏れてた……

Slide 71

Slide 71 text

Subversion では…… おもむろに漏れていたファイルをコミット

Slide 72

Slide 72 text

Subversion では…… おもむろに漏れていたファイルをコミット ×

Slide 73

Slide 73 text

コミットが分散 Subversion では…… おもむろに漏れていたファイルをコミット ×

Slide 74

Slide 74 text

履歴が崩壊 コミットが分散 Subversion では…… おもむろに漏れていたファイルをコミット ×

Slide 75

Slide 75 text

履歴が崩壊 コミットが分散 レビューしづらい Subversion では…… おもむろに漏れていたファイルをコミット ×

Slide 76

Slide 76 text

Git があるとき！ 前回のコミットを 訂正すれば良いね！

Slide 77

Slide 77 text

Git があるとき！ 前回のコミットを 訂正すれば良いね！ そもそも整理してから push するけどね

Slide 78

Slide 78 text

$ git add sugoi-spec.rb 漏れていたファイルをステージして……

Slide 79

Slide 79 text

$ git add sugoi-spec.rb 漏れていたファイルをステージして…… $ git commit --amend 前回のコミットを訂正！

Slide 80

Slide 80 text

$ git add sugoi-spec.rb 漏れていたファイルをステージして…… $ git commit --amend 前回のコミットを訂正！ やったね！

Slide 81

Slide 81 text

$ git add sugoi-spec.rb 漏れていたファイルをステージして…… $ git commit --amend 前回のコミットを訂正！ やったね！ ただし・・・既に公開している コミットを訂正してはいけません！

Slide 82

Slide 82 text

Subversion あるある ④ さっきのコミットに 関係の無い 修正が混じってた……

Slide 83

Slide 83 text

Subversion では…… コミットしちゃったし仕方ないよね……

Slide 84

Slide 84 text

Subversion では…… コミットしちゃったし仕方ないよね……

Slide 85

Slide 85 text

Subversion では…… コミットしちゃったし仕方ないよね…… ×

Slide 86

Slide 86 text

Subversion では…… コミットしちゃったし仕方ないよね…… × コミットが散乱

Slide 87

Slide 87 text

Subversion では…… コミットしちゃったし仕方ないよね…… ×履歴の崩壊 コミットが散乱

Slide 88

Slide 88 text

Subversion では…… コミットしちゃったし仕方ないよね…… ×履歴の崩壊 レビューしづらい コミットが散乱

Slide 89

Slide 89 text

Git があるとき！ 前回のコミットを 取り消せば良いね！

Slide 90

Slide 90 text

$ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき

Slide 91

Slide 91 text

$ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ……

Slide 92

Slide 92 text

$ git add . $ git commit -m ‘added sugoi-feature’ 例えば sugoi-feature.rb と sugoi-spec.rb がコミットされたとき spec は別のコミットに したいなぁ…… $ git reset HEAD^ sugoi-spec.rb インデックスの spec を HEAD のひとつ前の状態に戻して……

Slide 93

Slide 93 text

$ 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 前回のコミットを訂正！

Slide 94

Slide 94 text

$ 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 前回のコミットを訂正！ ワークツリーはそのまま なので……

Slide 95

Slide 95 text

$ 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 を再度ステージして

Slide 96

Slide 96 text

$ 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’ コミット！

Slide 97

Slide 97 text

$ 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’ コミット！ コミットが 分離出来たね！

Slide 98

Slide 98 text

Subversion あるある ⑤ ある機能の開発中に 別の作業を頼まれた……

Slide 99

Slide 99 text

Subversion では…… 今の作業が終わるまで待ってもらえます？

Slide 100

Slide 100 text

Subversion では…… 今の作業が終わるまで待ってもらえます？ ×

Slide 101

Slide 101 text

チェックアウトしよう にも時間がかかる Subversion では…… 今の作業が終わるまで待ってもらえます？ ×

Slide 102

Slide 102 text

作業が遅延 チェックアウトしよう にも時間がかかる Subversion では…… 今の作業が終わるまで待ってもらえます？ ×

Slide 103

Slide 103 text

作業が遅延 チェックアウトしよう にも時間がかかる 忘れ去られるかも Subversion では…… 今の作業が終わるまで待ってもらえます？ ×

Slide 104

Slide 104 text

Git があるとき！ 今の作業内容を 一時的に待避すれば 良いね！

Slide 105

Slide 105 text

$ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！

Slide 106

Slide 106 text

$ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・

Slide 107

Slide 107 text

$ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！

Slide 108

Slide 108 text

$ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始

Slide 109

Slide 109 text

$ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ 緊急対応中・・・（少々お待ちください） $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始

Slide 110

Slide 110 text

$ git checkout -b bug-1 bug-1 の修正中に・・・別のバグ修正を緊急で頼まれた！ でも手元には 修正中のコードが ・・・ $ git stash save こんなときは現在の作業状態を一時待避！ $ git checkout bug-1 元のブランチに戻って・・・ 緊急対応中・・・（少々お待ちください） $ git checkout -b bug-2 別のブランチで bug-2 の対応を開始

Slide 111

Slide 111 text

$ 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 の対応を開始

Slide 112

Slide 112 text

$ 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 の対応を開始

Slide 113

Slide 113 text

ココまでまとめるとこんな感じ Subversion Git コードの共有 中央リポジトリを介する リポジトリ間で自由 履歴の参照 遅い 速い コミット先 中央リポジトリ ローカルリポジトリ コミットの整理 不可 可 コミットの公開 commit = 公開 push して初めて公開 ブランチの作成 リモートで作成するしかない ローカルで幾つでも作れる マージ 遅い 速い 作業内容の待避 不可 可 ファイルのロック 可 不可 操作 単純 複雑

Slide 114

Slide 114 text

ココまでまとめるとこんな感じ Subversion Git コードの共有 中央リポジトリを介する リポジトリ間で自由 履歴の参照 遅い 速い コミット先 中央リポジトリ ローカルリポジトリ コミットの整理 不可 可 コミットの公開 commit = 公開 push して初めて公開 ブランチの作成 リモートで作成するしかない ローカルで幾つでも作れる マージ 遅い 速い 作業内容の待避 不可 可 ファイルのロック 可 不可 操作 単純 複雑 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Slide 115

Slide 115 text

GitHub　キホン の

Slide 116

Slide 116 text

♥

Slide 117

Slide 117 text

Goldman Sachs だって使ってます

Slide 118

Slide 118 text

GitHub の代表的な機能 ① ・リポジトリの管理 　・高機能なリポジトリブラウザ 　・プロジェクト管理機能（Issue, Wiki） 　・プロジェクト情報の可視化（Network, Graphs） 　・Watch, Star（プロジェクトの注目度の指標） 　・Fork（その場で自分用に Fork 出来る） 　・Pull Request（パッチのやりとり）

Slide 119

Slide 119 text

GitHub の代表的な機能 ② ・ダッシュボード 　・News Feed 　・Notifications 　・etc, etc ... ・ユーザーページ 　・Activities 　・Repositories 　・etc, etc ... ・その他 　・Gist, GItHub Pages etc ...

Slide 120

Slide 120 text

GitHub の良いところ ・プロジェクトよりも「ヒト」にフォーカス 　・誰が何をしているのか可視化 　・ちょっとした書き捨てのコードも共有 ・開発者同士のコラボレーションの促進 　・手軽に Fork 　・手軽に Pull Request

Slide 121

Slide 121 text

$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ github:enterprise $21 / user / month

Slide 122

Slide 122 text

$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ github:enterprise $21 / user / month ×

Slide 123

Slide 123 text

$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ $12,000 / 500 user / one-time

Slide 124

Slide 124 text

$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$ $$$$$$ $$ $$ $$$$$$ $$$$$$$$$$ $$$$$$$$$$$$$$$ $12,000 / 500 user / one-time ○

Slide 125

Slide 125 text

GitHub Stash リポジトリブラウザ ˕ ○ Issue ○ ˕ (JIRA と連携） Wiki ○ ○ 可視化 ˕ (Watch, Star, Network, Graphs） △ Fork ○ ○ Pull Request ○ ○ News Feed ○ ○ Notifications ˕ ○ ユーザーページ ˕ ○ スニペットの共有 ˕（Gist） × ホスティング ˕（GitHub Pages） × 参照権限の管理 ？ ○ API ˕ ○ 色々と細かいところのユーザビリティも含めると 全体的に GItHub の方が常に進んでいるのは否めない・・・

Slide 126

Slide 126 text

GitHub Stash リポジトリブラウザ ˕ ○ Issue ○ ˕ (JIRA と連携） Wiki ○ ○ 可視化 ˕ (Watch, Star, Network, Graphs） △ Fork ○ ○ Pull Request ○ ○ News Feed ○ ○ Notifications ˕ ○ ユーザーページ ˕ ○ スニペットの共有 ˕（Gist） × ホスティング ˕（GitHub Pages） × 参照権限の管理 ？ ○ API ˕ ○ 色々と細かいところのユーザビリティも含めると 全体的に GItHub の方が常に進んでいるのは否めない・・・ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Slide 127

Slide 127 text

GitHub Stash リポジトリブラウザ ˕ ○ Issue ○ ˕ (JIRA と連携） Wiki ○ ○ 可視化 ˕ (Watch, Star, Network, Graphs） △ Fork ○ ○ Pull Request ○ ○ News Feed ○ ○ Notifications ˕ ○ ユーザーページ ˕ ○ スニペットの共有 ˕（Gist） × ホスティング ˕（GitHub Pages） × 参照権限の管理 ？ ○ API ˕ ○ 色々と細かいところのユーザビリティも含めると 全体的に GItHub の方が常に進んでいるのは否めない・・・ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ͱ͸͍͑4UBTIͰ΋ ࠷௿ݶඞཁͳػೳ͸ଗͬͯ·͢

Slide 128

Slide 128 text

とりあえず GitHub / Stash を使うとどうなるのか考えてみる

Slide 129

Slide 129 text

ありませんかこんなこと ① コードレビューしたいから ひとまずコミットして〜

Slide 130

Slide 130 text

ありませんかこんなこと ① コードレビューしたいから ひとまずコミットして〜 コミットしました〜

Slide 131

Slide 131 text

ありませんかこんなこと ① コードレビューしたいから ひとまずコミットして〜 コミットしました〜 ・・・これ、 全部リファクタリングして良い？

Slide 132

Slide 132 text

事前にコードで話し合おう Pull Request を有効に使いましょう

Slide 133

Slide 133 text

事前にコードで話し合おう Pull Request を有効に使いましょう 議論するための Pull Request もアリだよ

Slide 134

Slide 134 text

ありませんかこんなこと ② ここの処理は面倒だから 他の PJ のコードをコピペしよう

Slide 135

Slide 135 text

ありませんかこんなこと ② ここの処理は面倒だから 他の PJ のコードをコピペしよう 他の PJ で作ったライブラリ にはどんなものがあるんだろう？

Slide 136

Slide 136 text

ありませんかこんなこと ② ここの処理は面倒だから 他の PJ のコードをコピペしよう 他の PJ で作ったライブラリ にはどんなものがあるんだろう？ この PJ で作ったライブラリ、 他の PJ でも使えそうだけど 共有するのが面倒くさい・・・

Slide 137

Slide 137 text

コードを共有しよう Pull Request を使えば上手く 共有出来るかも？

Slide 138

Slide 138 text

コードを共有しよう Pull Request を使えば上手く 共有出来るかも？ 共有ライブラリ をもっと作りたいな！

Slide 139

Slide 139 text

ありませんかこんなこと ③ もうすぐ評価レビューだ・・・

Slide 140

Slide 140 text

ありませんかこんなこと ③ もうすぐ評価レビューだ・・・ 開発チームのあいつ、 何やってるのか分からないんだよな

Slide 141

Slide 141 text

ありませんかこんなこと ③ もうすぐ評価レビューだ・・・ 開発チームのあいつ、 何やってるのか分からないんだよな 自分の成果が可視化されたら 良いんだけどな・・・

Slide 142

Slide 142 text

「ヒト」にフォーカスを当てよう Stashを使うと 「ヒト」の貢献が 見えてくるかも？

Slide 143

Slide 143 text

「ヒト」にフォーカスを当てよう Stashを使うと 「ヒト」の貢献が 見えてくるかも？ 個人のナレッジを 共有する文化も 産まれるかもね

Slide 144

Slide 144 text

「ヒト」にフォーカスを当てよう Stashを使うと 「ヒト」の貢献が 見えてくるかも？ 個人のナレッジを 共有する文化も 産まれるかもね モチベーションが上がって イノベーションが生まれそう

Slide 145

Slide 145 text

当社 での活用イメージ

Slide 146

Slide 146 text

基本は A successful git branching model を踏襲 ・中央リポジトリの master はマージ専用 ・中央リポジトリの develop で開発 ・各開発者が中央リポジトリの develop を fork して開発 ・fork → upstream（中央リポジトリ）に Pull Request ・担当者が Pull Request をレビューして Non Fast-Forward でマージ ・リリースしたら master に Non Fast-Forward でマージ

Slide 147

Slide 147 text

fork ベースでの開発フロー company/product master develop monzou/product topic upstream として参照 自分の fork から 本体の develop に Pull Request monzou/product:develop は company/product:develop と同期し, topic は develop で rebase してから push する

Slide 148

Slide 148 text

中央リポジトリのブランチで開発しても良いけど・・・ ・誤 push が発生する可能性があるので fork の方が安全 ・自分用のリモートリポジトリがある方が大きなミスは少なそう ・但し常に fork 元に同期しないといけないという手間が発生する ローカルの master を upstream の 追従用にして, 常に master で rebase するようにする

Slide 149

Slide 149 text

#1. Stash / GitHub で company/product を fork 開発者の作業フロー ①

Slide 150

Slide 150 text

#1. Stash / GitHub で company/product を fork #2. fork したリポジトリをローカルに clone $ git clone git://company.com/company/product.git 開発者の作業フロー ①

Slide 151

Slide 151 text

#1. Stash / GitHub で company/product を fork #2. fork したリポジトリをローカルに clone $ git clone git://company.com/company/product.git 開発者の作業フロー ① #3. 開発用のトピックブランチを作成 $ git checkout -b topic develop

Slide 152

Slide 152 text

#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’

Slide 153

Slide 153 text

開発者の作業フロー ② #5. fork したリポジトリの develop を fork 元リポジトリと同期 $ git checkout develop $ git pull upstream develop $ git push origin develop

Slide 154

Slide 154 text

#6. トピックブランチを develop で rebase $ git checkout topic $ git rebase develop 開発者の作業フロー ② #5. fork したリポジトリの develop を fork 元リポジトリと同期 $ git checkout develop $ git pull upstream develop $ git push origin develop

Slide 155

Slide 155 text

#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

Slide 156

Slide 156 text

#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

Slide 157

Slide 157 text

開発者の作業フロー ③ #9. Stash で Pull Request を送る monzou/product:topic → company/product:develop に Pull Request

Slide 158

Slide 158 text

開発者の作業フロー ③ #9. Stash で Pull Request を送る monzou/product:topic → company/product:develop に Pull Request #9b. Pull Request が却下されたら修正して再 push #9c. Pull Request が放置されていたら mention を書いてコメント @leader この Pull Request を確認してください

Slide 159

Slide 159 text

開発者の作業フロー ③ #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 を 飛ばすことが出来るよ

Slide 160

Slide 160 text

開発者が 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)’

Slide 161

Slide 161 text

開発者が 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

Slide 162

Slide 162 text

開発者が 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 ブランチをビルド

Slide 163

Slide 163 text

予想される問題 レビュー待ちの Pull Request が滞留する ・Pull Request が滞留するとコンフリクトがどんどん増える ・レビュー担当者を分散する ・mention を有効活用して早めに担当者に通知する ・細かい修正は最悪 Pull Request せずに直接開発者がマージしてしまう

Slide 164

Slide 164 text

予想される問題 レビュー待ちの Pull Request が滞留する ・Pull Request が滞留するとコンフリクトがどんどん増える ・レビュー担当者を分散する ・mention を有効活用して早めに担当者に通知する ・細かい修正は最悪 Pull Request せずに直接開発者がマージしてしまう Pull Request 送信時に検出されない不具合が増える ・Pull Request 送信時のブランチを事前にビルドしないと分からない ・でも Pull Request 毎に Jenkins にビルドさせるのは難しい・・・ ・こまめに対応するしかない

Slide 165

Slide 165 text

まとめ ローカルリポジトリ → 個人の生産性向上 Stash + Pull Request→ チームの生産性・品質向上 Stash で「ヒト」にフォーカス → エンジニアの交流活性化 Stash でコード共有の活性化 → 開発効率の向上

Slide 166

Slide 166 text

Any Questions ?