テストとVCSのコミット
@a3geekさん の場合
@numa08 だと思いますよ じゃないと諸々面倒な事が起きそうな未来が容易に想像つきますし それか、一旦コミットしてその後通るものをコミットして二つのコミット纏めてからプッシュならありかも?
2014-04-07 01:13:13@numa08 あぁでもコミットしてない部分のテストが大きくなってきたらコミットします、怖いので でもそれをプッシュする時は必ず通るのと纏めます ただ、そこまで大きくなるのは稀ですけど…
2014-04-07 01:20:16@numa08 そうですね、他人からきたissueを解決する時のテストのコミットは細分化が上手く出来なくてデカくなりがちですね ブランチの中で「テスト書いたコミット」と「テスト通ったコミット」の二つだけとかたまにあります…
2014-04-07 01:29:02@numa08 Redmineはもうちょっと操作性なんとかして、あとはベースをもっとシンプルにしてプラグイン拡張前提くらいにした方が使いやすいかも
2014-04-07 01:41:32@vvakame ということは、master/developなブランチにあるものは全部コンパイル/テストに通るコミットのみってことですかね
2014-04-07 01:12:48@a3geek でかいコミットが発生してくると、今度はブランチの切り方の問題になってくるのかな issue毎にブランチ切るとしても、issueの分解がうまくなかったらでかいコミットになったりしそう
2014-04-07 01:23:06@a3geek issue管理ツールによりけりだけど、子issueみたいなのを作れるからそれである程度細分化とかはできるかもね あと、タスクやissueの作成って小さいチームだったら会話しながらやったほうが良いかもって最近思ってる。
2014-04-07 01:31:46@numa08 そこらへんRedmine弱いイメージあります、つうかあれ使いづらい 小さいチームだったら口頭で伝えて管理ツールには必要な情報記載しておくのが良いと思ってます
2014-04-07 01:33:56@a3geek Redmineは遠隔地でやってるケースとかだと、ファイル管理とかもできてまぁ便利ではあるんだよね。ただ、小規模チームとか同じところにいるメンバだと、GitHub/Labのissueとホワイトボードで十分
2014-04-07 01:34:55@numa08 うーん、個人的には遠隔でもGithubの方が良いと思います まぁ実際はGithubよりbitbucketの方をよく使ってますけど
2014-04-07 01:36:30@vvkameさんの場合
@numa08 そこは他人が触る可能性があるブランチなので通らなかったら迷惑がかかるので絶対やらないように心がける。1人で開発する時も同様(急に飽きて2ヶ月ほっといて復帰した時になんで落ちるかわからなくてやさぐれるとかやだし)。
2014-04-07 01:13:54@numa08 わりと。トピックブランチでもテスト通らない場合はpushはしないかなー…。テスト追加する時は--amendするので、最終的にはテスト通るコミットしか存在しないようにしている(厳密にそうであることには拘らないけど)。
2014-04-07 01:16:12@numa08 わりとリポジトリによるかも… 会社のリポジトリはだいたいgit-flowかも。個人プロジェクトの場合はmasterとトピックブランチしかない構成のほうが多い気もする。現行リリースにパッチあてて緊急リリースがあるかどうかが分かれ目なのかな…?(わからん
2014-04-07 01:18:41@vvakame git-flowはなんか、手順多いイメージがあって会社でも個人でもmasterとトピックブランチのみの構成でやってますね。テスト落ちるコミットも割とあって、レビュー時にrejectはしますが、コミットは残り続けていてどうなんだろうと思った次第
2014-04-07 01:22:23@numa08 そこは自分の思想に基いてルール決めて強制すればいい気がするなー。めんどくさいことは続かないので、納得感あるテキトーな落とし所を用意してやるといいのでは。
2014-04-07 01:23:32