これだけは押さえておきたいGitHub Flowの基礎 | Think IT（シンクイット）
連載第三回は「これだけは押さえておきたいGitHub Flowの基礎」と題して、GitHubを使う上での基本的な部分について解説したいと思います。 と言っても、Git自体の利用方法については既に書籍もたくさんありますし、Web上にも記事が多数ありますので、ここでは特に触れないことにします。これからGit自体を学習する場合に有用なリンク集は、下記のブログ記事にまとめてありますので参考にしてください。 GitHubのトレーニングに役立つリンク集 今回のこの記事では、GitHub Flowについて解説します。 GitHub Flowについて改めておさらい GitHub Flowというのは、GitHub社が提唱している効果的なワークフローのことです。この言葉は2011年に発表されたこの記事が起源だと思います。 当時Web上で話題になったGit Flowというワークフローに対して、もう少し簡単で理解
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
GitHub FlowでPull Requestベースな開発フローの進め方 - Qiita
弊社、日本CAWでの開発フローはGitHub Flowをベースにしてpull requestを活用したスタイルを採用しています。 最近、有志のチームでサクっと行きたいラーメン屋さんを見つけることができるアプリ「めんこれ」というのを開発しているのですが、そろそろ開発フローを整備しようという話になったので、今まではクローズドでやってましたが、公開しちゃおうと思ったわけです。 普段はdevelopブランチをメインブランチにしているんですが、スピード感あるデプロイサイクルにするためにmasterブランチをメインにします。 実装者のフロー GitHub Flowについてはこちらの日本語訳を参照のこと。 https://gist.github.com/Gab-km/3705015 GitHubのissueで開発タスクを管理していますので、開発対象のリポジトリで自分にAssignされているタスクを確認し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
