http://nvie.com/git-model Anything that interests me. Mon, 06 Sep 2010 13:45:00 +0000 hourly 1 http://wordpress.org/?v=3.0.1 http://nvie.com/git-model/comment-page-5#comment-3348 Jeremy Attali Mon, 06 Sep 2010 13:45:00 +0000 http://nvie.com/?p=323#comment-3348 Excellent tutorial. Now I have a very clear idea of how to work with branches in a real development environment. Thanks! Excellent tutorial. Now I have a very clear idea of how to work with branches in a real development environment. Thanks!

]]> http://nvie.com/git-model/comment-page-5#comment-3347 Glyn Normington Mon, 06 Sep 2010 12:41:00 +0000 http://nvie.com/?p=323#comment-3347 This is a really helpful article and would probably work fine in many environments. Our environment is application server software with multiple versions actively supported in the field, so we'd need a tweak which may interest others, so I thought I'd mention it. Rather than forcing each release into a linear time sequence (by merging back into a production branch, "master" in your case), we need to be able to fix old versions, so these are independent branches and the fixes must then be merged or cherry-picked back in to the mainline of development. An example use case to consider is ship 1.0, ship 2.0, fix 1.0 to produce 1.0.1 - we wouldn't want to merge 1.0.1 into master after 2.0 otherwise the version metadata would get bumped backwards. This is a really helpful article and would probably work fine in many environments. Our environment is application server software with multiple versions actively supported in the field, so we’d need a tweak which may interest others, so I thought I’d mention it. Rather than forcing each release into a linear time sequence (by merging back into a production branch, “master” in your case), we need to be able to fix old versions, so these are independent branches and the fixes must then be merged or cherry-picked back in to the mainline of development. An example use case to consider is ship 1.0, ship 2.0, fix 1.0 to produce 1.0.1 – we wouldn’t want to merge 1.0.1 into master after 2.0 otherwise the version metadata would get bumped backwards.

]]> http://nvie.com/git-model/comment-page-5#comment-3087 Magnus Wed, 01 Sep 2010 06:28:00 +0000 http://nvie.com/?p=323#comment-3087 Thanks, I didn't think so. Great read by the way. :-) Thanks, I didn’t think so. Great read by the way. :-)

]]> http://nvie.com/git-model/comment-page-5#comment-3049 Anonymous Tue, 31 Aug 2010 11:10:00 +0000 http://nvie.com/?p=323#comment-3049 I don't have any reason to think this shouldn't work for Mercurial. It's a general model with concepts and guidelines applicable to any DVCS. I don’t have any reason to think this shouldn’t work for Mercurial. It’s a general model with concepts and guidelines applicable to any DVCS.

]]> http://nvie.com/git-model/comment-page-4#comment-3048 Magnus Tue, 31 Aug 2010 10:58:00 +0000 http://nvie.com/?p=323#comment-3048 Is there any problem using this model using Mercurial? Is there any problem using this model using Mercurial?

]]> http://nvie.com/git-model/comment-page-4#comment-2914 Christian Romney Wed, 25 Aug 2010 21:42:02 +0000 http://nvie.com/?p=323#comment-2914 Fantastic post. It's very similar to what we do already with some minor branch naming convention differences. Can't wait to give git-flow a whirl. Fantastic post. It’s very similar to what we do already with some minor branch naming convention differences. Can’t wait to give git-flow a whirl.

]]> http://nvie.com/git-model/comment-page-4#comment-3338 Christian Romney Wed, 25 Aug 2010 21:42:00 +0000 http://nvie.com/?p=323#comment-3338 Fantastic post. It's very similar to what we do already with some minor branch naming convention differences. Can't wait to give git-flow a whirl. Fantastic post. It’s very similar to what we do already with some minor branch naming convention differences. Can’t wait to give git-flow a whirl.

]]> http://nvie.com/git-model/comment-page-4#comment-2885 Vincent Driessen Tue, 24 Aug 2010 12:07:32 +0000 http://nvie.com/?p=323#comment-2885 @Dom: Here, we pull locally, but if you have a Github-style repo with a separate public and private repo, there really is no difference. In that case, you'd have to "publish" all of your private work to Github to have other team members fetch your work, of course. @Dom: Here, we pull locally, but if you have a Github-style repo with a separate public and private repo, there really is no difference. In that case, you’d have to “publish” all of your private work to Github to have other team members fetch your work, of course.

]]> http://nvie.com/git-model/comment-page-4#comment-3337 Vincent Driessen Tue, 24 Aug 2010 12:07:00 +0000 http://nvie.com/?p=323#comment-3337 @Dom: Here, we pull locally, but if you have a Github-style repo with a separate public and private repo, there really is no difference. In that case, you'd have to "publish" all of your private work to Github to have other team members fetch your work, of course. @Dom: Here, we pull locally, but if you have a Github-style repo with a separate public and private repo, there really is no difference. In that case, you’d have to “publish” all of your private work to Github to have other team members fetch your work, of course.

]]> http://nvie.com/git-model/comment-page-4#comment-2884 Vincent Driessen Tue, 24 Aug 2010 12:01:30 +0000 http://nvie.com/?p=323#comment-2884 @Thilo: there is one now. @Thilo: there is one now.

]]>