自分はGitの運用フローについてなにもわかっちゃいなかった(結局いまもわかってない)
先日、社内ワークショップに参加したときにGitを使った運用フローの話になったんですが、「決まった形でブランチを切ることがGit-flow(Github-flow)の本質じゃない」みたいな感じのことを言われて、そういえば確かにそれぞれの運用フローを「どうブランチ切るか」でしか見てなかったなあと気がついたので、改めて調べることにしました。
結論から書くと、まだわかってないです(調べきってないので)。
A successful Git branching model » nvie.com
見えないチカラ: A successful Git branching model を翻訳しました
Gitブランチを使いこなすgit-flow/GitHub Flow入門(1):いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - @IT
Git flowの活用事例
git-flow cheatsheet
GitHub Flow – Scott Chacon
GitHub Flow (Japanese translation)
Gitブランチを使いこなすgit-flow/GitHub Flow入門(終):プルリクエスト/レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - @IT
誰得UNIX: git-flowでもgithub flowでもない、Git本家推奨のワークフロー
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
ブランチの構造だけみると、GitHub-Flowの方がシンプルで便利そう!とは思うけど、ここで「CI等を使った自動テストやリリース、ドッグフーディングをどう挟むか」になると、意味合いは全然変わってくるのかなと思いました。
GitHub-Flowは構造がシンプルな分、開発ブランチ作るたびに都度自動テストを行うブランチの向け先を変えないといけないのかな、という印象があって、複数の機能追加が行われる状態になると、交わる先がmasterになってしまうのもかなり危うい印象を感じます。
これはWebサイトみたいに1日に大量のデプロイを行うことが可能なWebサイトだからこそ可能なのかな、と思いました。あとテストがしっかり組まれてることが前提で。
逆にGit-Flowは基本master前に一つブランチを挟むので、「テストが甘いのである程度人の手によるテスト期間が必要」とか、「そもそもUIテストやリリース前のドッグフーディングが必要なのでテスト期間いるよ」、みたいなコードフリーズ的な要素がいる場合に有効な手段なのかな、と。
実際には各ブランチでどういう作業をして、CIやデプロイ、QAはどういう形で行うべきなのかっていうのまで調べないと意味がないだろうとはわかっているけれど、実際のコーディング以外のことを考えると、アプリ開発にはGit-Flowの方がやりやすいところは多いのかなと感じました。
develop ブランチなんてオワコン - Togetterまとめ
あとそれを考えた上で、やっぱりGit-FlowのDevelopブランチ不要論は、工場で言うところの「結局みんな怪我しないように気をつけて、実際に事故起きてないから指差し呼称点検は不要だよね」みたいな危うさを感じてしまいました。
自分は人の力を信じないので、あえて一手間かけて意識を向けさせることは重要だなと思っています。
結論から書くと、まだわかってないです(調べきってないので)。
A successful Git branching model » nvie.com
見えないチカラ: A successful Git branching model を翻訳しました
Gitブランチを使いこなすgit-flow/GitHub Flow入門(1):いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - @IT
Git flowの活用事例
git-flow cheatsheet
GitHub Flow – Scott Chacon
GitHub Flow (Japanese translation)
Gitブランチを使いこなすgit-flow/GitHub Flow入門(終):プルリクエスト/レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - @IT
誰得UNIX: git-flowでもgithub flowでもない、Git本家推奨のワークフロー
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
ブランチの構造だけみると、GitHub-Flowの方がシンプルで便利そう!とは思うけど、ここで「CI等を使った自動テストやリリース、ドッグフーディングをどう挟むか」になると、意味合いは全然変わってくるのかなと思いました。
GitHub-Flowは構造がシンプルな分、開発ブランチ作るたびに都度自動テストを行うブランチの向け先を変えないといけないのかな、という印象があって、複数の機能追加が行われる状態になると、交わる先がmasterになってしまうのもかなり危うい印象を感じます。
これはWebサイトみたいに1日に大量のデプロイを行うことが可能なWebサイトだからこそ可能なのかな、と思いました。あとテストがしっかり組まれてることが前提で。
逆にGit-Flowは基本master前に一つブランチを挟むので、「テストが甘いのである程度人の手によるテスト期間が必要」とか、「そもそもUIテストやリリース前のドッグフーディングが必要なのでテスト期間いるよ」、みたいなコードフリーズ的な要素がいる場合に有効な手段なのかな、と。
実際には各ブランチでどういう作業をして、CIやデプロイ、QAはどういう形で行うべきなのかっていうのまで調べないと意味がないだろうとはわかっているけれど、実際のコーディング以外のことを考えると、アプリ開発にはGit-Flowの方がやりやすいところは多いのかなと感じました。
develop ブランチなんてオワコン - Togetterまとめ
あとそれを考えた上で、やっぱりGit-FlowのDevelopブランチ不要論は、工場で言うところの「結局みんな怪我しないように気をつけて、実際に事故起きてないから指差し呼称点検は不要だよね」みたいな危うさを感じてしまいました。
自分は人の力を信じないので、あえて一手間かけて意識を向けさせることは重要だなと思っています。
by yamacraft
| 2014-06-06 22:45
| いろいろ