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
GitHubよちよち会#3
Search
はない
March 02, 2016
Technology
0
160
GitHubよちよち会#3
社内勉強会で使った資料(3回目/全3回)
はない
March 02, 2016
Tweet
Share
More Decks by はない
See All by はない
2018年目標を達成できなかった私が 今年こそ達成するためにしていること
hanahiroaze
3
500
組み合わせテストを簡単にするgemを作った話
hanahiroaze
0
230
MySQLとデッドロックの話
hanahiroaze
1
1.3k
ここが変だよ。このテスト〜テストケース爆発と戦う〜
hanahiroaze
1
1.5k
Symfony Best Practiceを読もう!(ついでに翻訳した話)
hanahiroaze
2
890
E2E Test Tips
hanahiroaze
0
160
テストことはじめ
hanahiroaze
0
450
Symfony2のi18n対応
hanahiroaze
0
780
開発合宿に行ってきました
hanahiroaze
0
140
Other Decks in Technology
See All in Technology
Datasets for Critical Operations by Dataform
kimujun
0
130
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
0
180
alecthomas/kong はいいぞ
fujiwara3
6
1.2k
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
210
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
100
ファインディにおける Dataform ブランチ戦略
hiracky16
0
230
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
120
LLM開発を支えるエヌビディアの生成AIエコシステム
acceleratedmu3n
0
350
【CEDEC2025】大規模言語モデルを活用したゲーム内会話パートのスクリプト作成支援への取り組み
cygames
PRO
1
520
Bet "Bet AI" - Accelerating Our AI Journey #BetAIDay
layerx
PRO
1
120
With Devin -AIの自律とメンバーの自立
kotanin0
2
930
OpenTelemetry の Log を使いこなそう
biwashi
5
1.1k
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
Producing Creativity
orderedlist
PRO
346
40k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Faster Mobile Websites
deanohume
308
31k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Automating Front-end Workflow
addyosmani
1370
200k
Thoughts on Productivity
jonyablonski
69
4.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Transcript
GGiittHHuubb よちよち会 第33回 ggiittの履歴を管理しよう!!
A.local R.local 前回のおさらい GitHub.com bugfix add_function bugfix # 忘れ物追加 てへぺろ(・ω<)
$ git push origin bugfix # 最新ソースの取得 $ git fetch $ git merge origin/bugfix $ git merge bugfix # conflictを直接編集して修正
rreebbaassee VVSS mmeerrggee。 TTooddaayy’ss GGooaall rreebbaasseeこわい。 ggiitthhuubb--fflloowwとggiitt--ffllooww。
rreebbaassee iiss…� rreebbaasseeの挙動をおさらいしよう! first release bugfix bugfix master commit 2
commit 1 commit 2 commit 1 $ git rebase master bugfix modify message 変更パッチ として適用 bugfix bbuuggffiixxブランチの差分コミットが、 mmaasstteerrブランチのHHEEAADDの後ろに追加されたよ。
rreebbaassee iiss…� ? WWhhaatt hhaappppeennee nneexxtt??
rreebbaassee iiss…� first release commit 2 commit 1 modify message
bugfix 差分コミットがmmaasstteerrの後ろに着いたので、 FFaasstt--FFoorrwwaarrddできるようになった! first release commit 2 commit 1 modify message bugfix master $ git checkout master $ git merge bugfix master
local wwhheenn yyoouu “ppuullll”…� ppuullllの挙動を確認だ! $ git pull $ git
pull --rebase $ git fetch $ git merge origin/branch_name $ git fetch $ git rebase origin/branch_name clone branch_name origin/branch_name clone mod merge local branch_name origin/branch_name add clone clone mod add add add
local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master
もうちょっと複雑な場合を考えよう。 merge commit merge modify master
local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master
mmeerrggeeコミットが残っちゃた。。。 履歴をきれいにするためにrreebbaasseeしたよー! merge modify merge modify rebase modify master 分岐元がなくなっちゃった。。。
rreebbaasseeこわい 全体像
local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master
mmeerrggeeするために、リモートをppuullllすると・・・ merge modify merge modify rebase modify master merge commit merge commit 消したかった履歴が 戻っちゃう。。。
同じタイムスタンプのコミットが 2つある・・・
((どうすればいいんだよぉ。。。))
local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master
mmeerrggeeするために、リモートをppuullll ----rreebbaassee すると・・・ merge modify merge modify rebase modify master 差分 patch ・ローカルにしかない ・mmeerrggeeコミット以外 を選んでppaattcchhにするよ
local GitHub.com rreebbaasseeこわい first release commit 1 master ただし・・・ merge
modify merge modify rebase modify master 差分 patch commit 2 差分が多いとうまくできないよ
((bbeesstt pprraaccttiicceeはあるの?))
公開リポジトリにプッシュしたコミットを リベースしてはいけない WWhheenn yyoouu uussee rreebbaassee プッシュする前の作業をきれいに整理する手段 としてだけリベースを使い、まだ公開していな いコミットだけをリベースすることを心がけて いれば、何も問題はありません。
「Pro Git」 p128~134 https://progit-ja.github.io/
あなたは[[コミットの歴史]]を どうとらえますか? rreebbaassee VVSS mmeerrggee 歴史の改�ざんは絶対しない! ログが汚く((読みづらく))なっても、起きたことは 全て記録するべき!! [[コミットの歴史]]はソフトウェア成長の物語! 将来のメンテナンスのためにログは読みやすい
状態に保つべき!!
あなたは[[コミットの歴史]]を どうとらえますか? rreebbaassee VVSS mmeerrggee ログが読みづらい原因は、mmeerrggeeコミットのせ いだとするなら、 を使えばいいじゃない! [[AAuuttoo MMeerrggee]]Œホfl゚¡チ∞ーがいいよね!
PPRRが綺麗になる!!! $ git log --no-merges git log よく使うオプションまとめ http://qiita.com/take4s5i/items/15d8648405f4e7ea3039
あなたは[[コミットの歴史]]を どうとらえますか? rreebbaassee VVSS mmeerrggee
あなたは[[コミットの歴史]]を どうとらえますか? rreebbaassee VVSS mmeerrggee ~pull-requestがconflictしているとき~ グリーンにするための主な選択肢は、二種類あります。 ひとつは、自 分のブランチを、プルリクエストの対象ブランチ (普通は、フォーク元の
リポジトリの master) の先端にリベースすること。 もうひとつは、その対 象ブランチを自分のブランチにマージすることです。 GitHub 上の開発者の多くは、後者を選んでいるようです。その理由 は、先述したとおりです。 重要なのは、そこにいたるまでの歴史と、最 終的にマージしたという事実だと考えているのでしょう。 リベースをす ると、歴史がすっきりするという以外の利点はありません。そして、リベ ースはマージに比べて ずっと 難しいし、間違いを起こしやすいもので す。 「Pro Git」 p228 https://progit-ja.github.io/
ggiitthhuubb--ffllooww ・masterブランチのものは何であれデプロイ可能である ・新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する (例: new-oauth2-scopes) ・作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも 定期的に作業内容をpushする ・フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト
を作成する ・他の誰かがレビューをして機能にOKを出してくれたら、 あなたはコードをmasterへマージすることができる ・マージをしてmasterへpushしたら、直ちにデプロイをする GitHub Flow (Japanese translation) https://gist.github.com/Gab-km/3705015
ggiitt--ffllooww ・developブランチ 開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。次に紹介する featureブランチなど、他のブランチで行った作業は、ここにマージされる ・featureブランチ 主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにfeature ブランチを作成し、作業を行う ・releaseブランチ リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブランチを作成し、微 調整を行う。releaseブランチを作成することで、リリース準備と次のバージョンに向けた開発の
コードを分けることができる ・masterブランチ リリースしたソースコードを管理するためのブランチ。リリース作業を行うと、releaseブランチは masterブランチへマージされて、リリースタグが打たれる。開発者は、このブランチへのコミット は行わない ・hotfixブランチ リリースされたソフトウェアに緊急の修正を行うためのブランチ。このブランチでの修正内容は、 すぐにリリースされるので、hotfixブランチはリリースを管理するmasterブランチへマージされる いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 http://www.atmarkit.co.jp/ait/articles/1311/18/news017_2.html
bbrraanncchh ppoolliiccyy ? WWhhaatt iiss ddiiffffeerreennccee??
ggiitt--ffllooww VVSS ggiitthhuubb--ffllooww ggiitthhuubb--ffllooww には、「リリース」の概念 がない。 ((mmaasstteerrへのmmeerrggee == 本番デプロイ)) ppuullll--rreeqquueesstt
による開発範囲の表明 $ git commit --allow-empty
HHaavvee aa GGoooodd GGiitt LLiiffee!! TThhaannkk yyoouu!!
AAnnyy qquueessttiioonnss??
Q.
卒業!!!