Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サルでもわかるgit
Search
takashabe
January 28, 2015
Technology
0
1.4k
サルでもわかるgit
とある勉強会で話したgitのブランチ戦略とかの資料です。
http://takashabe.hatenablog.com/entry/2015/01/28/215020
takashabe
January 28, 2015
Tweet
Share
More Decks by takashabe
See All by takashabe
より良いターミナルでの生活を求めて
takashabe
0
41
OpenCensusでcustom context propagationとexporterを書いた話 / OpenCensus with custom context propagation and exporter
takashabe
0
1.6k
pubsub with concurrent
takashabe
1
870
社内ISUCONを開催した話
takashabe
0
1.6k
ISUCON大反省会
takashabe
0
1.8k
gitのブランチ戦略
takashabe
8
5.8k
playで複数DBする
takashabe
0
1.6k
MySQLで高トラフィックに立ち向かう
takashabe
0
1.8k
GitHubの良さ
takashabe
2
2.2k
Other Decks in Technology
See All in Technology
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 / phper-kaigi-2025-ryu
carta_engineering
0
690
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
110
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
150
20250326_管理ツールの権限管理で改善したこと
sasata299
1
380
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略
ryu955
2
450
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
tarappo
4
940
Agile TPIを活用した品質改善事例
tomasagi
0
310
職種に名前が付く、ということ/The fact that a job title has a name
bitkey
1
240
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
140
グループポリシー再確認
murachiakira
0
170
バクラクでのSystem Risk Records導入による変化と改善の取り組み/Changes and Improvement Initiatives Resulting from the Implementation of System Risk Records
taddy_919
0
220
モンテカルロ木探索のパフォーマンスを予測する Kaggleコンペ解説 〜生成AIによる未知のゲーム生成〜
rist
4
1.1k
Featured
See All Featured
Facilitating Awesome Meetings
lara
53
6.3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
320
The Language of Interfaces
destraynor
157
24k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
28
2k
Testing 201, or: Great Expectations
jmmastey
42
7.4k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Transcript
サルでもわかるgithub Takashi Abe Mynet Inc. 28/01 2015
おまえだれよ @takashabe PHPでソシャゲ作ってます Scalaとかgolang,つけ麺が好き 社内ではgithubおじさんと呼ばれています 若手です
git移行時あるある
ブランチの子供が出来過ぎ てマージ困難
いつの間にかmasterに取り 込まれるコミット
None
ブランチ戦略決めましょう
メジャーなブランチ戦略 git-flow 5種類のブランチを使って機能開発、リリース、hotfix などの役割を明確に分けている 堅牢なモデルだが慣れないうちは煩雑 github flow masterと機能開発ブランチのみを持つ masterはすぐデプロイ対象するワイルドなモデル
git-flow
使用するブランチ develop 開発安定版ブランチ。featureブランチなどはここにマージされる feature 機能開発用ブランチ。機能開発やバグフィックスなどの開発を機能ごとに開発する ためのブランチ。最終的にdevelopにマージされる release リリース用ブランチ。リリース時にdevelopから作成される。リリース作業中でも developに対する変更を行えるようになる。 master
安定版ブランチ。リリースを終えたreleaseブランチからmasterにマージされる。 hotfix 緊急のバグ修正ブランチ。masterから作成され、releaseブランチを介さずにそのま まmasterにマージされる。
None
feature
release
hotfix
git-flowの特徴 releaseやhotfixのための手順が明確に定められていて プロダクションに上げるコードを堅牢に保つことが出来 る 使用するブランチが多いため手順が煩雑
github flow
使用するブランチ master 安定版、リリース用ブランチ。featureブランチは全て masterにマージされ、即座にデプロイ対象になる。 feature 機能開発用ブランチ。masterから作成され、そのまま masterにマージされる。
None
github flowの特徴 使用するブランチが最小限で理解しやすい masterを常にデプロイ可能な状態にしないといけない コードレビュー CI
弊チームのブランチ戦略
やりたいこと
やりたいこと 規模の大きい新機能など、複数人で1つの機能を作りた い リリースする機能は絞る場合がある リリース前にQA環境でQAしたい
git-flowのアレンジ
featureブランチの亜種を2 つ追加した
追加したfeatureブランチ feature-develop 1つの大きな機能における開発安定版。developから 作成され、feature-developから更にfeatureブランチ を作成する。featureブランチはfeature-developブラ ンチにマージされる。 QA QA用ブランチ。developから作成され、次回リリースに 盛り込むブランチを全てマージする。ここにはfeature- developブランチが含まれる。
機能開発フロー developブランチからfeature-developブランチを作成 feature-developブランチからfeatureブランチを作成 featureブランチをfeature-developブランチにマージ
リリースフロー feature-developブランチをQAブランチにマージ QA中の修正は全てQAブランチにマージ QAが完了したらreleaseブランチにマージ
None
GitHub導入時の話
GitHub導入時 メンバーのスキルセット 個人ではGit/GitHubを使っていた チーム開発でGitを使ったことはあるがGitHubは無し Git/GitHub共にそれほど使ったことがない
チーム開発でGitHubを使ったこ とがあるメンバーは居なかった
GitHubに慣れるために GitHubらしい開発フローの徹底 既存プロダクトはsvnでmasterブランチ1本運用だった Pull Request駆動開発の徹底 git-flowをベースにしたブランチ戦略の徹底
GitHubでの開発ってこんな感 じだということを浸透させる
GitHubについての社内勉強会やチームMTG Git自体は複雑なツールなので必要な機能だけつまみ 食いする 開発において最低限必要なフローをドキュメント化して 共有 機能開発〜Pull Requestを送るまでの手順 QA環境への適用手順 git rebaseとかgit
resetは使えれば便利だけど必須で はない
こんな時どうすれば良いの?ということを聞けるの超大 事 pull 出来ない! push 出来ない! コンフリクトした! 詳しい人が1人いると便利 仮に詳しい人がいなくてもGitHubの情報はググれば いくらでもある
それなりに開発が回るように なってきた
コミット粒度 Pull Request粒度 ラベルの運用
チームの習熟度によってフォーカス するレイヤを変える
tips
ブランチを作るとき ブランチ作成時は常にリモートブランチから作成するこ とを意識する git checkout -b feature/a origin/develop GitHubなどのGUIフロントエンドが使えればそれでも 古いローカルブランチから作成することによってリモート
の最新コミットが取り込まれない コンフリクトの原因になる
CUIでやる SourceTreeなど優秀なGUIツールを使うのもいいが、git の構造を知るにはCUIでやると捗る ローカル/リモートリポジトリの違い working copy,index,ローカルリポジトリの違い 慣れるとGUIでやるよりも捗る(と思う)