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.5k
サルでもわかる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
53
OpenCensusでcustom context propagationとexporterを書いた話 / OpenCensus with custom context propagation and exporter
takashabe
0
1.7k
pubsub with concurrent
takashabe
1
910
社内ISUCONを開催した話
takashabe
0
1.6k
ISUCON大反省会
takashabe
0
1.9k
gitのブランチ戦略
takashabe
8
5.9k
playで複数DBする
takashabe
0
1.6k
MySQLで高トラフィックに立ち向かう
takashabe
0
1.8k
GitHubの良さ
takashabe
2
2.2k
Other Decks in Technology
See All in Technology
AWS環境のリソース調査を Claude Code で効率化 / aws investigate with cc devio2025
masahirokawahara
2
1.2k
バッチ処理で悩むバックエンドエンジニアに捧げるAWS Glue入門
diggymo
3
110
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
0
220
DDD集約とサービスコンテキスト境界との関係性
pandayumi
2
250
DevIO2025_継続的なサービス開発のための技術的意思決定のポイント / how-to-tech-decision-makaing-devio2025
nologyance
0
130
実践AIガバナンス
asei
3
330
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
2
720
おやつは300円まで!の最適化を模索してみた
techtekt
PRO
0
270
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
shibayu36
0
190
エラーとアクセシビリティ
schktjm
0
810
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
130
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
9
4k
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Speed Design
sergeychernyshev
32
1.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
Code Review Best Practice
trishagee
70
19k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
11
1.1k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
How to train your dragon (web standard)
notwaldorf
96
6.2k
How to Ace a Technical Interview
jacobian
279
23k
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でやるよりも捗る(と思う)