Live data from Hacker News

Why aren't you using git-flow?

jeffkreeftmeijer.com

21–30 of 55 posts

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

#21

Earlier quoted context omitted.

I develop in master sometimes, but only check in small edits that are pushed immediately. If my edits grow to the point that I need to write tests or push to staging, I just checkout a feature branch before committing.

If you are using git-flow, this should probably be done in a hotfix branch, so that when you are done, finishing your hotfix merges directly to master and develop. Without a hotfix you would have to manually merge master back into develop.

It sounds like git-flow removes some hassle, can anyone answer the question about adding git-flow to an existing repo?

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

#23

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.

I've done some playing around with a dummy "existing" repo and it seems to adapt well. Upon "git flow init" it identifies existing branches and proceeds with the questionnaire in the article above associating.

Here's a gist I created showing how an existing repo (although very basic) can be adapted to use git-flow - http://gist.github.com/538326

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

#25

Earlier quoted context omitted.

If you are using git-flow, this should probably be done in a hotfix branch, so that when you are done, finishing your hotfix merges directly to master and develop. Without a hotfix you would have to manually merge master back into develop.

It sounds like git-flow removes some hassle, can anyone answer the question about adding git-flow to an existing repo?

Running `git flow init` in an existing repository will ask you which branches you want to use as master- and development branches. So, yes. :)

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

#26

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…

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…

There's a psuedo-branch in master, which is "everything since the latest commit that has been pushed out". (This is my own terminology, so don't go Googling for it.) This is the branch that becomes "real" once pushed to the public, and that's when you can no longer rewrite the history without hurting things.

If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in), it's really easy to deal with. You branch from master, re-checkout master, and git reset --hard back to the public psuedobranch. And it is as if you had a branch all along.

I play the same game with git svn sometimes, except the psuedobranch is the "stuff that has not yet been committed to SVN" and it's a lot more clear where the cutoff is. I won't pretend this is perfect, but it does work.

(The problem I have with branching off for absolutely everything is that I find it easy to end up with too many branches to remember what's what. Granted, I'm the team lead and I may be more prone to that than a team member with more defined tasks.)

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

#29

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…

Master exists as a pristine releasable code base. Develop is the main branch for working on things, and branching usually happens from there. Having master and develop lets you keep developing on your project while having a frozen deployable branch master in this case.

My question is, why is this (develop/master) better than master/release branches? Or master/qa/production? Or do you view that as just an arbitrary choice of names (since there's nothing special about the master branch in git)?
Post reply on HN