Skip to content

Instantly share code, notes, and snippets.

@udzura

udzura/yawaraka-github.md Secret

Last active Jan 1, 2016
Embed
What would you like to do?
やわらかGitHub

やわらかGitHub

今日説明すること

  • Pull Requestを使いこなす
  • GitHubとブランチングフロー

Pull Request

  • なぜ行うか?

メリット1:過去を振り返り道しるべ

  • プルリクを作ると、心理的に「切りのいいところ」でプルリクを出したくなるはず
  • 「切りのいいところ」の履歴が残る
  • あとから他人が見やすい、他人とは「未来の自分」を含む

メリット2:レビュー容易性

  • プルリクを活用する=レビューを開発のフローに組み込む
  • https://speakerdeck.com/hotchpotch/pull-request-woli-yong-sitakai-fa-wakuhuro
  • で言及されていない(小物ですいません)が、WEB†DB PRESS「実践コードレビュー入門」
  • レビューの段階
  • ピアレビュー=理想的
  • 他プロジェクトの人のレビュー
  • 自分レビュー
  • それぞれ、十分意味がある
  • レビューのタイミング
  • プレマージレビュー
  • ポストコミットレビュー
  • プレマージがもちろん理想とされるが、ポストコミットでも十分意味がある
  • まずは、レビューを開発のフローに組み込む

メリット3:Pull Request Builder

  • Pull Request=Jenkins的にも分かりやすいフックのタイミング
  • GitHubのプルリクはCIと統合されている、便利最高

最初にできること

  • 一人でも、切りよくプルリク=最近できてる
  • 「どうしてプルリク?」と言う意識が大事

GitHubとブランチングフロー

  • git-flow=プレギットハブ時代っぽい、一旦忘れてみる
  • master, develop,hotfix... 本当にこのフローが必要か考えてみる
  • リリースフローの手法を振り返る

cherry-pick

  • マジつらい(経験者談
  • プルリクベースのやり方とあんまり合わない。最悪、使うことはある

master一本

  • プルリクは全部masterに対して
  • まあ回る。リリースはタグ
  • ある機能を先に開発しておきたい。。。みたいなとき不利
  • 並行開発、複数人で不利
  • 運営の都合上リリースを後回しにしたい、とかは不利

当社のフロー

  • http://paperboy-all.github.io/docs/github/workflow.html
  • 一度は読んどいてくださいよ!!!
  • master一本前提のようだ
  • あと、Webアプリのように明確にアプリのバージョンを切らない場合のやり方に沿っている
  • minneの各アプリのように明確にバージョンを切っている場合はひと工夫が必要ではないかな
    • あと、iOSアプリは必ず「審査」がある。どこかでブレークポイントを入れないといけない訳で

GitHub flow

  • 当社フローの下敷き
  • https://gist.github.com/Gab-km/3705015
  • やはり大前提は「masterブランチのものは何であれデプロイ可能である」、
    • そしてマージ即リリース
    • 審査はどうしているのかギットハブ関係の人に本当に問いつめたいっちゃけど...
  • 「名前をつけたブランチに定期的にpush」大事、Gitならでは
    • 長ければpullも必要かも。コンフリクトの解消

うづらさんが経験したフロー

  • cherry-pick ... リーダーが死んでいたのですぐ辞めた
  • エーミンなんとかと言うアジャイルな会社の例です
  • master vs リリースブランチフロー
    • オンゲの伝統で定期メンテがあった=メンテ日ごとにブランチ
    • 検証の時間がないものはmaster行き、次回検証に持ち越し
    • 検証できそうなものはメンテブランチへ、ちゃんとQAに検証してもらう
    • リリースしたらmasterにマージし戻す
    • 次のメンテに向けて新たにブランチを切る→繰り返し
    • 緊急メンテ、とかでもブランチは切っていた。ただ、リリース後のブランチから直接切ることもあったり。
    • メリット?
      • cherry-pickよりはブランチの状態が分かりやすい、絵にしやすい
      • 何をリリースしているかはかなり明確になる、ユーザへ周知しやすい(Gerritだったので大変だったけど、GitHubなら問題は無い)
      • 同時に走っているブランチは基本的に2本に収まる
    • デメリット
      • 若干のcherry-pickからは逃れられないかも...
      • マージ仕返しは少し面倒、忘れたら... コンフリクトとか...
      • master一本の場合に比べて複雑、その複雑さは本当に必要か?

まとめ

  • 色々工夫するのは楽しいので、開発の合間に考えてみる、提案してみる
  • 先人に学ぶ
  • レビュー大事
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.