テストファーストなGitワークフローについて - kazuhoのメモ置き場

Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ

[kazuhooku]

blogged

[ruedap]

rebaseを使わない理由になるほどと思った

[kgrock]

kazuhoのメモ置き場

[haishi]

対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェク

[legoboku]

「まず、ゴールを明確化し（必要ならチームメンバーで共有した上で）、そのために最適な実装を行うということを繰り返す」

[speg03]

参考になる。

[Drunkar]

トピックブランチの最初のコミットは失敗するテストにして、目標を明確化する。後から見返しても分かりやすそうだ

[VoQn]

個人のプロジェクトだと git-flow も github-flow も合わないのでこれ参考にしてる。確かにブランチの最初のコミットでテスト書いて失敗させるの目的がはっきりする

[masaru_b_cl]

最初にredのコミットを入れるというのは、私もよくやる / お仕事だとセントラルリポジトリがSVNなので、git merge --no-ffが出来ないのがつらい

[t-wada]

“トピックブランチの最初のコミットは、「未解決の課題」を表すテスト（つまり失敗するテスト）次に、この「課題」を解決する（１つ以上の）コミットを実装する” rebase ではなく merge を行う理由も含め、明解

[mabots]

変更の主題を常に明確にする

[skit_n]

Github使った開発をし始める上の道標になりそう

[issm]

"トピックブランチの最初のコミットは、「未解決の課題」を表すテスト（つまり失敗するテスト）" / rebase ではなく merge を使う背景がなるほど．

[Nyoho]

基本GitHub Flowだけどそれにさらにトピック枝の最初コミットをそのトピックのためのテストだけにするということね。いいね!

[ryonext]

masterは本番とイコールじゃなくていつでも本番に出せるものなのか。捗りそうな気がしてきた。

[InoHiro]

failするテストをまず最初にトピックブランチにコミットする

[cats_nukui]

これはキレイだなぁ。

[kero_mi_chan]

これはキレイだなぁ。

[exactman]

あ

[sho-yamasaki]

これといった目新しさはないけれど、最初にテストを書いて、それを満たすコードを書く手順は目的が明確になってよいと思います。

[komagata]

failするテストを書いたことを他人にも見える形で表せるので良さそう！

[kasumani]

kazuhoのメモ置き場 Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 Tags: feedly, ifttt, recently read, saved for later from Pocket February 04, 2014 at 02:39PM via IFTTT

[nobusue]

シンプルだが見通しの良い運用

[kimihito]

参考にしよう

[lesamoureuses]

なるほど “なぜ、トピックブランチの最初のcommitを、「failするテスト」にするのか。それは、漫然とコードを書いてしまわないようにするためです。まず、ゴールを明確化し、そのために最適な実装を行う"

[nihen]

原則をみてsquashするのかと思ったけど1st parentという考えがあるのか、なるほど

[ryochack]

漠然とコードを書いてしまわないようにするために、トピックブランチの最初のcommitを「failするテスト」にする

[yukung]

"なぜ、トピックブランチの最初のcommitを「failするテスト」にするのか。それは、漫然とコードを書いてしまわないようにするため。まず、ゴールを明確化し、そのために最適な実装を行う"

[at_yasu]

ちょっとした変更でも初期化をミスってたりしてバグるときはバグるんですよウヘヘ…(｀；ω；´)

[asonas]

コミットの文脈を破壊しないためってのすごいわかる。けど「commit treeの綺麗さ」は、bisectするときにぐちゃってると困るので、なるべくrebaseするなぁ。でも、その時のコミットに依るのかも。

[naruoga]

ぼくの周りはテストファーストとはいってないみたいだけど、これはシンプルでわかりやすいルールだな。ふむふむ。