Comments on: Git for code reviews https://gasparnagy.com/2014/02/git-for-code-reviews/ coach, trainer and bdd addict, creator of SpecFlow; owner of Spec Solutions Wed, 12 Feb 2014 14:36:14 +0000 hourly 1 https://wordpress.org/?v=6.9 By: Gáspár https://gasparnagy.com/2014/02/git-for-code-reviews/#comment-141 Wed, 12 Feb 2014 14:36:14 +0000 http://gasparnagy-com.lku.dkk.mybluehost.me/?p=356#comment-141 In reply to Jonas.

Well, I think the primary goal is not to be able to merge these ideas back without special considerations or following the project’s branching guidelines. A good example for this might be, that the reviewer points out a bug, even provides a proposed fix, but do not perform all necessary checks from the definition of done, like writing a unit tests.
Still, the review comment and a proposed fix is somehow has a live connection to the code base. By cherry-pickable, I was more referring to having isolated commits for the different review notes (only one note per commit).

]]> By: Jonas https://gasparnagy.com/2014/02/git-for-code-reviews/#comment-140 Wed, 12 Feb 2014 13:52:19 +0000 http://gasparnagy-com.lku.dkk.mybluehost.me/?p=356#comment-140 Interesting. I am still sceptical about this highly distributed model:
– Is it really practicable to make those commits isolated and cherry-pickable?
– Isn’t there still a big chance for semantic merge conflict with that many branches
– What about continuous integration (i.e. “advanced tests”): That is still happening on trunk?

]]>