
Why aren't you using git-flow? - jkreeftmeijer
http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
======
KirinDave
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
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?

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

~~~
lnguyen
There's no need for any custom terminology: Your master branch isn't a pseudo-
branch. It's just another branch that happens to live in your local repository
and shares the same name as the remote repository's branch that it tracks.

------
brazzy
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
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!

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

~~~
bobbywilson0
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
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.

~~~
rlpb
Would a single member of the team (the release manager) be doing it all
though, and the rest of the team would only be pushing to the development
branch? The release manager would maybe pull for hotfixes, but it would always
be the release manager doing the work (or his proxy).

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

~~~
jsarch
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.

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

------
saurabh
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
Scrolling is much faster in Firefox 4, especially on pages with a background
image.

~~~
eru
Chrome is also bearable.

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

~~~
kevinold
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
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! :)

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

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

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

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

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

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

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

~~~
avar
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.

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

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

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

------
VMG
because I am still struggling to understand normal git

