Live data from Hacker News

Why aren't you using git-flow?

jeffkreeftmeijer.com

51–55 of 55 posts

Re: Why aren't you using git-flow?

#51

Has anyone used git-flow with an existing repo? It seems like existing branches could just be renamed from "myfeature" to "feature/myfeature", etc. but I wonder if others have been down this road and have run into issues.

also, if you want to fiddle with the options after you set it up with git flow init, just go to the .git/config file and change it there :)

when in doubt, look at stuff in a repo's .git/ to find what you wanna fiddle with. unless of course you want to look at user wide config file at ~/.gitconfig

Re: Why aren't you using git-flow?

#52
post #20

You know you suffer from FOSS-culture-tunnelview when... ...you are "astounded" that some people never heard of some less-than-a-year-old add-on to a fashionable development tool.

And on a related note, You May Be Getting Old if you increasingly hear statements like, "I don't know how anybody ever did X without having Y!" and you have direct memories of having did X quite successfully for 10-20+ years without, as you may have guessed, having Y. Because Y didn't exist for most of that time!

Re: Why aren't you using git-flow?

#53
post #45
post #34

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.

No relevant information is lost. You're basically only deleting the reference, which is only a name. As long as you don't explicitly destroy the commits (eg. with a squashing merge or a rebase) the branch will still exist in the repository structure. The commits won't be GCd because they're merged to another branch which has an explicit reference (master).

You can at any time go back to it as long as you know the SHA-1 identifier for the head commit you want. Because of this, there's little reason to keep temporary refs cluttering the ref namespace.

If you really want to keep references to everything, a "git attic" tool exists which allows you to move branch refs out from the main ref namespace into a normally invisible (ie. doesn't show up in git branch etc.) namespace.

Post reply on HN