GitHub Flow (Japanese translation)

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

[snomof]

developブランチを使うと作業内容が中途半端でもシェアできるのでgit-flow式のmaster中心にはしようとは思わないけど、フィーチャーブランチを全部リモートに上げるのは良さげ

[elf]

#GitHub Flowについての #日本語訳

[Cherenkov]

日本語訳

[ymm1x]

git-flow と GitHub Flow

[kita-tuba]

GitHub Flow (Japanese translation)

[yamo3]

“さて、なぜGitHubではgit-flowを使わないのだろうか？ 私たちが常にデプロイをするから、というのが主な理由ではある。 git-flowのプロセスは主として「リリース」を中心に設計されている。 私たちはプロダクション環境へ

[ahoboketako]

github

[takaken1123]

[2016-04-22 14:17]

[takaesu]

github flow

[tmatsuu]

読み返してる。この手順ではマージしてからデプロイになってるけど、GitHub公式のドキュメントはデプロイしてからマージになってた。差し戻しを考慮するとデプロイしてからマージが良い気がしてきた。

[windish]

リリースサイクルの違いによってGit Flowとどちらが良いか決めるのがよさそう

[Nilfs]

前に読んだけど、一応メモ・・・

[Ashizawa]

GitHub Flow (Japanese translation) github-flow.ja.

[masaru_b_cl]

“masterブランチのものは何であれデプロイ可能である”

[zuborawka]

シンプルで良い

[aroma_black]

シンプルなワークフローにすることで頻繁にリリースができる、学習コストが少ないなどのメリットがある。

[motobrew]

[

[kfujii]

読もう。

[jazzanova]

ブックマークしてなかった。

[nacika_inscatolare]

読んでなかったことを今ものすごく後悔している。

[Sato_4tree]

ふむふむ。CVS使ってる時にやってたやり方と基本的には同じかな。今更git-flowやめようとは思わないけど、うちはfeature終わったらすぐreleaseブランチ切ってるから、それならこっちのやり方でもよかったかもな

[side_tana]

参考になる

[aetos382]

git-flow

[bufferings]

読んだー。うちのチームも自然とこんな感じにプルリクエスト中心になってるなー。がぶさんあざますー！

[darupants]

GitHub Flow翻訳

[ymkjp]

Github Flow よいですな

[mikage014]

「製品を毎日プッシュし、コンスタントにテストしデプロイするという、出荷の文化を作り上げてきたチームに対して、私はGitHub Flowのようなもっとシンプルな何かを選ぶことをお勧めする。」

[yuske711]

git-flowとの比較付き

[yysaki]

git-flowとの比較付き

[Mint0A0yama]

うちの体制的にGitHub Flowは向いてない…

[shin1x1]

master ブランチはデプロイ可能にしておく / feature ブランチは master ブランチから切る / feature ブランチを push して、PR を master へ投げる