サルでもわかるgit

Slide 1

Slide 1 text

サルでもわかるgithub Takashi Abe Mynet Inc. 28/01 2015

Slide 2

Slide 2 text

おまえだれよ @takashabe PHPでソシャゲ作ってます Scalaとかgolang,つけ麺が好き社内ではgithubおじさんと呼ばれています若手です

Slide 3

Slide 3 text

git移行時あるある

Slide 4

Slide 4 text

ブランチの子供が出来過ぎてマージ困難

Slide 5

Slide 5 text

いつの間にかmasterに取り込まれるコミット

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ブランチ戦略決めましょう

Slide 8

Slide 8 text

メジャーなブランチ戦略 git-flow 5種類のブランチを使って機能開発、リリース、hotfix などの役割を明確に分けている堅牢なモデルだが慣れないうちは煩雑 github flow masterと機能開発ブランチのみを持つ masterはすぐデプロイ対象するワイルドなモデル

Slide 9

Slide 9 text

git-flow

Slide 10

Slide 10 text

使用するブランチ develop 開発安定版ブランチ。featureブランチなどはここにマージされる feature 機能開発用ブランチ。機能開発やバグフィックスなどの開発を機能ごとに開発するためのブランチ。最終的にdevelopにマージされる release リリース用ブランチ。リリース時にdevelopから作成される。リリース作業中でも developに対する変更を行えるようになる。 master 安定版ブランチ。リリースを終えたreleaseブランチからmasterにマージされる。 hotfix 緊急のバグ修正ブランチ。masterから作成され、releaseブランチを介さずにそのままmasterにマージされる。

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

feature

Slide 13

Slide 13 text

release

Slide 14

Slide 14 text

hotfix

Slide 15

Slide 15 text

git-flowの特徴 releaseやhotfixのための手順が明確に定められていてプロダクションに上げるコードを堅牢に保つことが出来る使用するブランチが多いため手順が煩雑

Slide 16

Slide 16 text

github flow

Slide 17

Slide 17 text

使用するブランチ master 安定版、リリース用ブランチ。featureブランチは全て masterにマージされ、即座にデプロイ対象になる。 feature 機能開発用ブランチ。masterから作成され、そのまま masterにマージされる。

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

github flowの特徴使用するブランチが最小限で理解しやすい masterを常にデプロイ可能な状態にしないといけないコードレビュー CI

Slide 20

Slide 20 text

弊チームのブランチ戦略

Slide 21

Slide 21 text

やりたいこと

Slide 22

Slide 22 text

やりたいこと規模の大きい新機能など、複数人で1つの機能を作りたいリリースする機能は絞る場合があるリリース前にQA環境でQAしたい

Slide 23

Slide 23 text

git-flowのアレンジ

Slide 24

Slide 24 text

featureブランチの亜種を2 つ追加した

Slide 25

Slide 25 text

追加したfeatureブランチ feature-develop 1つの大きな機能における開発安定版。developから作成され、feature-developから更にfeatureブランチを作成する。featureブランチはfeature-developブランチにマージされる。 QA QA用ブランチ。developから作成され、次回リリースに盛り込むブランチを全てマージする。ここにはfeature- developブランチが含まれる。

Slide 26

Slide 26 text

機能開発フロー developブランチからfeature-developブランチを作成 feature-developブランチからfeatureブランチを作成 featureブランチをfeature-developブランチにマージ

Slide 27

Slide 27 text

リリースフロー feature-developブランチをQAブランチにマージ QA中の修正は全てQAブランチにマージ QAが完了したらreleaseブランチにマージ

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

GitHub導入時の話

Slide 30

Slide 30 text

GitHub導入時メンバーのスキルセット個人ではGit/GitHubを使っていたチーム開発でGitを使ったことはあるがGitHubは無し Git/GitHub共にそれほど使ったことがない

Slide 31

Slide 31 text

チーム開発でGitHubを使ったことがあるメンバーは居なかった

Slide 32

Slide 32 text

GitHubに慣れるために GitHubらしい開発フローの徹底既存プロダクトはsvnでmasterブランチ1本運用だった Pull Request駆動開発の徹底 git-flowをベースにしたブランチ戦略の徹底

Slide 33

Slide 33 text

GitHubでの開発ってこんな感じだということを浸透させる

Slide 34

Slide 34 text

GitHubについての社内勉強会やチームMTG Git自体は複雑なツールなので必要な機能だけつまみ食いする開発において最低限必要なフローをドキュメント化して共有機能開発〜Pull Requestを送るまでの手順 QA環境への適用手順 git rebaseとかgit resetは使えれば便利だけど必須ではない

Slide 35

Slide 35 text

こんな時どうすれば良いの？ということを聞けるの超大事 pull 出来ない！ push 出来ない！コンフリクトした！詳しい人が1人いると便利仮に詳しい人がいなくてもGitHubの情報はググればいくらでもある

Slide 36

Slide 36 text

それなりに開発が回るようになってきた

Slide 37

Slide 37 text

コミット粒度 Pull Request粒度ラベルの運用

Slide 38

Slide 38 text

チームの習熟度によってフォーカスするレイヤを変える

Slide 39

Slide 39 text

tips

Slide 40

Slide 40 text

ブランチを作るときブランチ作成時は常にリモートブランチから作成することを意識する git checkout -b feature/a origin/develop GitHubなどのGUIフロントエンドが使えればそれでも古いローカルブランチから作成することによってリモートの最新コミットが取り込まれないコンフリクトの原因になる

Slide 41

Slide 41 text

CUIでやる SourceTreeなど優秀なGUIツールを使うのもいいが、git の構造を知るにはCUIでやると捗るローカル/リモートリポジトリの違い working copy,index,ローカルリポジトリの違い慣れるとGUIでやるよりも捗る(と思う)