Togetter/min.tを安心してお使い頂くためのガイドラインを公開しました。

テストとVCSのコミット

TDDな開発でテストコードのみ記述した状態はどうするのか、と気になったので。 後半は違う話になっていった。
3
ぬま @numa08

TDDやってて、テストだけ書いた状態(テスト、コンパイルは通らない)ってコミットする?しない?

2014-04-07 01:10:38

@a3geekさん の場合

あーさん @a3geek

@numa08 基本的にはしない それが目的ならする

2014-04-07 01:11:08
ぬま @numa08

@a3geek やっぱり、コミットはコンパイルやテストが通る物のみにするのが普通かな

2014-04-07 01:11:38
あーさん @a3geek

@numa08 だと思いますよ じゃないと諸々面倒な事が起きそうな未来が容易に想像つきますし それか、一旦コミットしてその後通るものをコミットして二つのコミット纏めてからプッシュならありかも?

2014-04-07 01:13:13
ぬま @numa08

@a3geek そうね 俺も、プッシュするやつは纏めてるな

2014-04-07 01:13:53
あーさん @a3geek

@numa08 あぁでもコミットしてない部分のテストが大きくなってきたらコミットします、怖いので でもそれをプッシュする時は必ず通るのと纏めます ただ、そこまで大きくなるのは稀ですけど…

2014-04-07 01:20:16
あーさん @a3geek

@numa08 そうですね、他人からきたissueを解決する時のテストのコミットは細分化が上手く出来なくてデカくなりがちですね ブランチの中で「テスト書いたコミット」と「テスト通ったコミット」の二つだけとかたまにあります…

2014-04-07 01:29:02
あーさん @a3geek

@numa08 Redmineはもうちょっと操作性なんとかして、あとはベースをもっとシンプルにしてプラグイン拡張前提くらいにした方が使いやすいかも

2014-04-07 01:41:32
ぬま @numa08

@vvakame ということは、master/developなブランチにあるものは全部コンパイル/テストに通るコミットのみってことですかね

2014-04-07 01:12:48
ぬま @numa08

@a3geek でかいコミットが発生してくると、今度はブランチの切り方の問題になってくるのかな issue毎にブランチ切るとしても、issueの分解がうまくなかったらでかいコミットになったりしそう

2014-04-07 01:23:06
ぬま @numa08

@a3geek issue管理ツールによりけりだけど、子issueみたいなのを作れるからそれである程度細分化とかはできるかもね あと、タスクやissueの作成って小さいチームだったら会話しながらやったほうが良いかもって最近思ってる。

2014-04-07 01:31:46
あーさん @a3geek

@numa08 そこらへんRedmine弱いイメージあります、つうかあれ使いづらい 小さいチームだったら口頭で伝えて管理ツールには必要な情報記載しておくのが良いと思ってます

2014-04-07 01:33:56
ぬま @numa08

@a3geek Redmineは遠隔地でやってるケースとかだと、ファイル管理とかもできてまぁ便利ではあるんだよね。ただ、小規模チームとか同じところにいるメンバだと、GitHub/Labのissueとホワイトボードで十分

2014-04-07 01:34:55
あーさん @a3geek

@numa08 うーん、個人的には遠隔でもGithubの方が良いと思います まぁ実際はGithubよりbitbucketの方をよく使ってますけど

2014-04-07 01:36:30
ぬま @numa08

@a3geek Redmineは、機能多すぎる感じがするよね プラグインで拡張できても、プロジェクト管理をあいつに任せるには操作が複雑

2014-04-07 01:38:18

@vvkameさんの場合

わかめ@毎日猫がいる @vvakame

@numa08 そこは他人が触る可能性があるブランチなので通らなかったら迷惑がかかるので絶対やらないように心がける。1人で開発する時も同様(急に飽きて2ヶ月ほっといて復帰した時になんで落ちるかわからなくてやさぐれるとかやだし)。

2014-04-07 01:13:54
ぬま @numa08

@vvakame なるほど確かに トピックブランチのはその限りではない感じなんですね

2014-04-07 01:15:02
わかめ@毎日猫がいる @vvakame

@numa08 わりと。トピックブランチでもテスト通らない場合はpushはしないかなー…。テスト追加する時は--amendするので、最終的にはテスト通るコミットしか存在しないようにしている(厳密にそうであることには拘らないけど)。

2014-04-07 01:16:12
ぬま @numa08

@vvakame なるへそ ちなみに、master/developブランチがあるってことは、git-flowなスタイルで運用ですか?

2014-04-07 01:17:00
わかめ@毎日猫がいる @vvakame

@numa08 わりとリポジトリによるかも… 会社のリポジトリはだいたいgit-flowかも。個人プロジェクトの場合はmasterとトピックブランチしかない構成のほうが多い気もする。現行リリースにパッチあてて緊急リリースがあるかどうかが分かれ目なのかな…?(わからん

2014-04-07 01:18:41
ぬま @numa08

@vvakame git-flowはなんか、手順多いイメージがあって会社でも個人でもmasterとトピックブランチのみの構成でやってますね。テスト落ちるコミットも割とあって、レビュー時にrejectはしますが、コミットは残り続けていてどうなんだろうと思った次第

2014-04-07 01:22:23
わかめ@毎日猫がいる @vvakame

@numa08 そこは自分の思想に基いてルール決めて強制すればいい気がするなー。めんどくさいことは続かないので、納得感あるテキトーな落とし所を用意してやるといいのでは。

2014-04-07 01:23:32
残りを読む(28)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?