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
31
OpenCensusでcustom context propagationとexporterを書いた話 / OpenCensus with custom context propagation and exporter
takashabe
0
1.6k
pubsub with concurrent
takashabe
1
860
社内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
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
1k
サーバーレスアーキテクチャと生成AIの融合 / Serverless Meets Generative AI
_kensh
12
3k
Kubernetes x k6 で負荷試験基盤を開発して 負荷試験を民主化した話 / Kubernetes x k6
sansan_randd
2
730
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
450
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
190
事業継続を支える自動テストの考え方
tsuemura
0
300
技術的負債解消の取り組みと専門チームのお話 #技術的負債_Findy
bengo4com
1
1.2k
ハッキングの世界に迫る~攻撃者の思考で考えるセキュリティ~
nomizone
12
4.5k
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
130
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
130
アジャイル開発とスクラム
araihara
0
160
[2025-02-07]生成AIで変える問い合わせの未来 〜チームグローバル化の香りを添えて〜
tosite
1
290
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Visualization
eitanlees
146
15k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
The Cult of Friendly URLs
andyhume
78
6.2k
Fireside Chat
paigeccino
34
3.2k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
99
18k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Typedesign – Prime Four
hannesfritz
40
2.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
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でやるよりも捗る(と思う)