41–50 of 55 posts
Then everyone just used git. It's interesting to see this dream come to a small amount of fruition.
Our team uses this with great success. To take this a step further we name our features in conjunction with features in our project management tool. git flow feature start visitor_can_sign_in_812381 This gives us a nice mapping of feature branches to actual features. The one thing to be aware of with git flow is that the author is more on the merge side than on the rebase side. So closing features just involves mergi…
http://darwinweb.net/articles/the-case-for-git-rebase
Worth reposting here in case anyone missed.
Every time I visit your blog, I open up firebug and disable that background image. Scrolling is awfully slow. Please disable it, its annoying.
Earlier quoted context omitted.
If you develop directly in master, then how can you go back and fix a severe bug in the version of the code that is in your production site without having to revert all the in-progress development changes or risk introducing them into the bugfix? I believe this is the intent of not working in master. If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new b…
its actually very easy. You develop on master. if you need s 'stabilisation' phase, when you only do bugfixes you can do that on a release branch. Or if you usually deploy the latest you can just tag the version that you deploy. If you want to just fix something from the currently deployed version you can create a 'hotfix' branch out of the tagged release version, do the fix, deploy, merge the hotfix branch into mast…
Earlier quoted context omitted.
its actually very easy. You develop on master. if you need s 'stabilisation' phase, when you only do bugfixes you can do that on a release branch. Or if you usually deploy the latest you can just tag the version that you deploy. If you want to just fix something from the currently deployed version you can create a 'hotfix' branch out of the tagged release version, do the fix, deploy, merge the hotfix branch into mast…
Is there a reason to delete the branch? I don't think I've ever tried to delete a branch in subversion. I imagine it's possible, and can be reversed if necessary, but goes against my thinking of the repository as a canonical log of all development.
Commits are what's fixed. Branches are basically just mutable pointers to commits.
Earlier quoted context omitted.
If you develop directly in master, then how can you go back and fix a severe bug in the version of the code that is in your production site without having to revert all the in-progress development changes or risk introducing them into the bugfix? I believe this is the intent of not working in master. If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new b…
It's not hard (not claiming it's sensible, but still). Do gitk --all, walk back to the tag, right click and create a new branch. This is even possible if there was no tag (just a recognizable revision), or if you want to create a tag retroactively.
Git flow is a great tool as a starter to teach people what a reasonable git workflow is. Once you understand got better, you may find it a bit constraining. Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense. EDIT: Please not I am not suggesting that you not do fea…
git checkout -b hotfix master
The master/develop model gives you a pointer to the latest release for free. The pointer is called master.
Without the 'extra' develop branch, you have to remember or lookup the name of the latest release if you want to make a hotfix, or keep an extra tag for it, in which case the two models are the same.