中の人に聞いたGitHub flowの本当の使い方 - Qiita

背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること

[fujiriko59]

本番で問題が起きてはいけないとかいってたら絶対実施できないフローだ。問題おきたらすぐ直せばおｋなノリで生きていきたい

[y-kawaz]

マージ前デプロイってPRブランチが勝手にデプロイされる環境があるって事ことなんじゃね？うちも https://{branch,commitid,tag}.repo.example.jp/ の好きなURLにアクセスすれば即時デプロイされてすぐ確認出来るようにとかしてるし。

[n314]

よく分からなかった。マージ前にデプロイする元は何なのだ。あと複数平行して開発が進むと思うんだけど、デプロイ後のマージでコンフリクトしないのか。

[ikeike443]

貼っておきますね http://githubengineering.com/deploying-branches-to-github-com/

[yojik]

mastar前にdevelopブランチを置いて、そこに各PRをマージしてテスト環境のデプロイ対象にしたいな(github-flowとgit-flowの中間というか)

[kuxumarin]

mergeの前にデプロイ王子するのか…

[ono_matope]

Githubはfeatureブランチをmasterにマージする前にデプロイしてるのか…下手に真似すると怪我しそう。

[naohero22]

“マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあることと記載が

[tri-star]

リリースブランチを作らない、github flowを選んだ場合の考え方。それでも参考になる。

[shifumin]

「ようはほとんどはbotにやらせて人間がやることはビールを飲むことということである」いい。

[zetfs]

GitHub flow

[fuktommy]

いろんなスタイルがあるけど、こういうルール設計は本当に難しいよな。 中の人に聞いたGitHub flowの本当の使い方 on @Qiita

[sky-y]

"なのでこれを読んでいただけた方は「バグは手作りの証」というのを世の中に広めていただきたい。" あれだ、「きゅうりに虫が住んでるのは無農薬の証拠です」みたいな感じで広めよう。

[jumperson]

作り手としてはmaterマージ前にデプロイが理想。

[tinsep19]

中の人曰くマージしてからデプロイではない。本当のGitHub-flowはマージ前にデプロイし、ユーザーに近いところでフィードバックを受ける。ダメなら直ちにmasterに戻す。なのでmasterは直ちにデプロイできないといけない。

[tyru]

確かにマージ前にデプロイして確認した方がずっといいよなぁ／マージ前デプロイの話に対して本番環境にデプロイすると思ってる人のコメントがちらほらあるっぽいけど、テスト環境でしょ？(たぶん)

[hamasyou_bot]

メモ: 中の人に聞いたGitHub flowの本当の使い方 on @Qiita

[satoshie]

[Qiita 「バグは手作りの証」

[yamitzky]

マージ前にデプロイするのか。確かに、テストとかが担保されていれば先にマージするか後にマージするかって割りとどうでもいい問題だもんなあ

[ktanaka117]

かんぱい

[kamip]

“マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。” なんか良さそう。

[YaSuYuKi]

マージの前にデプロイできるのは、デプロイ時点で既知の問題を全部クリア出来ている(十分な自動テスト)、全ユーザーに影響が及ばないようにできる(部分ユーザー向けリリース)、即戻せるのすべてがあるからだな

[golden_eggg]

良い "コミュニケーションには常にURLをつける"

[matsumoto_r]

なるほどね

[tmatsuu]

この差異が発生した原因は、2011年に紹介された時のGitHub Flowと今のGitHub Flowが異なることに由来するはず。ググッてでてくる日本語訳も前者を元にしててそれが広まってしまってる。

[masudaK]

マージ前にデプロイって、タイミング相当気をつけないと他の人とタイミング合わなそう。自分の認識が間違ってるのかもしれないけど、特定の機能指し戻ったりしないのかな。

[kasajei]

マージする前にデプロイする

[hiroomi]

”ユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態に”

[shiwork]

中の人に聞いたGitHub flowの本当の使い方 on @Qiita 良い

[narcissis_taa]

"中の人に聞いたGit Hub flowの本当の使い方 - Qiita" が気になった。

[macoshita]

このプロセスだとbranchがmasterのheadから生えてる状態を保たないとダメってことになるからツリーはめっちゃ綺麗になりそう

[toyama0919]

URLベースのコミュニケーション

[sonots]

弊チームもstagingにはbranch指定でデプロイして(๑˃̵ᴗ˂̵)و ﾖｼ!となったらmasterにマージしてproductionにまくフローにしている

[masatomo-m]

git-flowのreleaseブランチに近いのかな？

[koheisg]

masterにマージしてからデプロイで結構不自由したから、デプロイ後レビューとか、本当のgithub flowとか興味あるな。