Why aren't you using git-flow?

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

by jkreeftmeijer • 16 years ago

215 51 16 years ago

I remember reading about this branching model and really liking the idea. The tools might actually motivate me to use it.

avar2• 16 years ago

Because most of us don't need a branching model this complex, and if we do doing the equivalent thing with "git checkout" is trivial compared to actually managing all those branches.

bobbywilson04• 16 years ago

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 merging on top of the develop branch. This hasn't raised many problems for our team though.

SkyMarshal• 16 years ago

Regarding rebasing, the first commenter at the bottom of the linked article mentioned he prefers rebasing to merging, and referenced a blog post of his explaining why:

http://darwinweb.net/articles/the-case-for-git-rebase

Worth reposting here in case anyone missed.

rlpb3• 16 years ago

I do the same thing without git-flow already. What will git-flow give me that I can't easily do or is awkward with using git directly?

someone_here• 16 years ago

I think this just gives a nicer interface to git's branching model by removing (excessive) flexibility.

bobbywilson04• 16 years ago

If you are doing this style exactly without git flow, you don't gain a whole lot. It is great if you are working with a team then it forces everyone to work the same way and is very clear what you do in each situation. One of my favorite features of git-flow is housekeeping, for features when you close them it merges to develop and destroys the branch, when you do a hotfix it merges to master and develop and destroys the branch. When you release it creates a tag with whatever version you specify, and you can work on that until you are happy with the state of release, then when you push tags you will have a nice snapshot of your last deploy.

tl;dr: good for teams, and housekeeping

swatermasysk• 16 years ago

I haven't used it yet, but I have to agree that forcing a team through the same general process would be a very big win.

grandalf• 16 years ago

This is interesting. Does anyone know if it introduces any other metadata or concepts that are annoying if one reverts back to plain git?

avar2• 16 years ago

It just appears to be a fancy-pants way of creating branches for you. Plenty of projects (e.g. Git itself) use a similar development model without using git-flow.

KirinDave• 16 years ago

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 feature branching. That is an awesome and compelling feature of git. I just don't see the need for a second branch just for developing in general in. That's what master has traditionally been for.

And yes, you can branch and redo tags at any time. If you don't know this, you probably don't understand git's underlying model very well. Time to read up: http://www.google.com/search?q=explanation+of+git+internals

brown9-2• 16 years ago

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 branch from it? I could be wrong but I thought tags in git were basically just read-only and informational - can you start work from them?

klochner2• 16 years ago

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.

drothlis• 16 years ago

Yes, you can create a new branch from any tag (or indeed any commit).

JulianMorrison• 16 years ago

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.

jerf• 16 years ago

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.)

Vitaly• 16 years ago

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 master and delete it:

    git branch hotfix v1.2.3
    git co hotfix
    # do the fix
    git tag v1.2.4
    # deploy
    git co master
    git merge hotfix
    git branch -d hotfix

bobbywilson04• 16 years ago

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.

kscaldef• 16 years ago

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)?

thomie• 16 years ago

what is your equivalent of:

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.

kevinold2• 16 years ago

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.

kevinold2• 16 years ago

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

mltsy• 16 years ago

This gist is literally the most helpful thing I have ever read in under 5 minutes :D Especially with all mistakes included and averted. Thank you! :)

carterschonwald• 16 years ago

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

ryanjmo• 16 years ago

We don't use git-flow because we don't have any problems managing our code.

waqf• 16 years ago

I don't use any language other than Blub, because Blub works just great.

brazzy• 16 years ago

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.

mkramlich• 16 years ago

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!

blaix• 16 years ago

I typically don't like tools like this. They hide too much of what is going on.

b0b0b0b• 16 years ago

git-flow reminds me so much of maven.

jsarch• 16 years ago

While I understand your concern, a feature of gitflow IMO is that you can switch between git and gitflow as you wish. Personally, I like the constraints that gitflow creates because it simplifies the process of pushing out releases.

Since time is my number one constraint right now, I'm taking advantage of every tool that makes me more productive. Yes, you can certainly implement the workflow with vanilla "git" but if you're going to follow the workflow model, why not use a tool that excels at that workflow? especially when said tool allows you to see what it's doing.

dlsspy• 16 years ago

Our workflow goes through gerrit. It's simple and I really like it that way.

I don't know that this could be added to it and not make it entirely more complicated.

saurabh• 16 years ago

Every time I visit your blog, I open up firebug and disable that background image. Scrolling is awfully slow. Please disable it, its annoying.

kinetik• 16 years ago

Scrolling is much faster in Firefox 4, especially on pages with a background image.

eru2• 16 years ago

Chrome is also bearable.

xiongchiamiov• 16 years ago

If you visit it more than once, you could add a rule to Stylish (or, I suppose, greasemonkey).

VMG• 16 years ago

because I am still struggling to understand normal git

steveklabnik• 16 years ago

One of the original intents of the git project was to create an "SCM toolkit" where other people would use git to build their own little interfaces on top of it.

Then everyone just used git. It's interesting to see this dream come to a small amount of fruition.

fedesoria• 16 years ago

This sounds like a great tool for developers who are starting out in git, but it is even better for those familiar to it because it makes our life easier.

ebneter• 16 years ago

If there's one thing I've learned in 15+ years of build/release/scm engineering, it's that there is no one-size-fits-all branching model or workflow. git-flow is a nice set of tools for one workflow/branching model, but it should not be confused with a silver bullet.

mml• 16 years ago

Because I use mercurial. Every commit is a branch if you want it to be. Also, task branching model is a bit heavy for my tastes.

Why aren't you using git-flow?

Related Stories