Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitFlow considered harmful

endoflineblog.com

Post reply on HN
Print view View original

11–20 of 342 posts

Re: GitFlow considered harmful

#11

Post by purephase »

Mithaldu wrote: post #4
tokenizerrr wrote: post #3

I like to be able to (temporarily) revert an entire feature branch, which merge commits help with. Is there a way to easily do this without them?

If i understand you right, you want to do this: - Checkout master. - Start an interactive rebase of master onto the last commit before the series of commits you wish to remove. - Mark all the commits you don't care about as "skip". - Let the rebase run and resolve conflicts on the way, the same as you'd do with your current work flow.

Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags.

While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway).

[1] http://scottchacon.com/2011/08/31/github-flow.html

Re: GitFlow considered harmful

#12

Post by matthiasv »

jacobparker wrote: post #9

> I thought it was a weird, over-engineered solution to a non-existent problem. To be fair, its a cookie-cutter approach that resonates with people unfamiliar with git but not ready/willing to invest the time to understand it deeply. That is understandable; a lot of people come from other systems and just need to get going right away and gits poor reputation for command-line consistency etc. is well-earned. (To be cl…

His point is that this cookie-cutter approach is more complex to the development model he presents (and is in fact pretty common among open source software). You don't need to understand Git deeply to realize that master is stable and merges in finished and cleaned up features.

Re: GitFlow considered harmful

#13

Post by giulianob »

ryanthejuggler wrote: post #7

> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful"…

Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.

Re: GitFlow considered harmful

#14

Post by omouse »

The only thing GitFlow had going for it is that it has a clearly written article about it with pictures that explain how it works. That's it; the freedom of git and being able to define what works for you is too much for people and they think they need to turn development back into Subversion-style or desktop-release style.

Re: GitFlow considered harmful

#15

Post by perlgeek »

A reason that we are switching from full git flow to a reduced model (basically one master branch + feature branches, occasional hotfix branches) is that git flow isn't compatible with continuous integration and continuous delivery.

The idea of CI is that you integrate all commits, so you must integrate the develop branch - build the software, run the tests, deploy it to a production-like environment, test it there too.

So naturally, most testing happens in that environment; and then you make a production release starting from the master branch, and then install that -- and it's not the same binary that you tested before.

Sure, you could have two test/staging environments, but I don't think I could get anybody to test their features in both environments. That's just not practical.

Re: GitFlow considered harmful

#16

Post by ryanthejuggler »

giulianob wrote: post #13
ryanthejuggler wrote: post #7

> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful"…

Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.

Ironically, for that reason, GitFlow would work better in Mercurial. Go figure.

Re: GitFlow considered harmful

#17

Post by jacobparker »

matthiasv wrote: post #12
jacobparker wrote: post #9

> I thought it was a weird, over-engineered solution to a non-existent problem. To be fair, its a cookie-cutter approach that resonates with people unfamiliar with git but not ready/willing to invest the time to understand it deeply. That is understandable; a lot of people come from other systems and just need to get going right away and gits poor reputation for command-line consistency etc. is well-earned. (To be cl…

His point is that this cookie-cutter approach is more complex to the development model he presents (and is in fact pretty common among open source software). You don't need to understand Git deeply to realize that master is stable and merges in finished and cleaned up features.

I should have been more clear - I agree that its more complicated. My point was that regardless, it seems to resonate. I believe its because the complications look useful at a glance and layering a rigid model on top of git frees you from having to consider its full scope of possible operation.

(I believe that git flow is definitely better than "everyone does things their way", and that's one competing "rule-book" for a team new to git.)

I'm pretty confident that understanding the tool better will help you to judge how to use it more effectively. The best way to understand git is to understand its data-model.

Re: GitFlow considered harmful

#18

Post by ninjakeyboard »

You don't need to implement ALL of gitflow - I see it as scalable.

Master should always be latest production code, development branch contains all code pre-release. That's the core.

The other branches let you scale gitflow - if you need to track upcoming release bugfixes etc, you can use a release branch. A team of maybe 6 or 7 would likely start to need a release branch. Feature branches at this point are best left local on the developers repository. They rebase to fixup commits, and then merge those into develop when they're ready.

If you get into bigger teams - like maybe 6 agile teams working on different larger features, then you can introduce feature branches for the teams to use on sprints to keep the work separate.

The issue with gitflow is the lack of continuous integration, so I personally like to get teams to work only on a develop branch during sprints and use feature toggles to commit work to the develop branch without breaking anything.

As I see it, gitflow and CI are at odds and that's my biggest gripe with integrating lots of feature branching for teams - everyone has to integrate at the end of the day.

So I believe the model can and should be scaled back as far as possible, using only develop and master and release as primary workflow branches, introducing the others when the need arises - doing it just because it says so in the doc isn't the right approach.

Re: GitFlow considered harmful

#19

Post by ryanthejuggler »

omouse wrote: post #14

The only thing GitFlow had going for it is that it has a clearly written article about it with pictures that explain how it works. That's it; the freedom of git and being able to define what works for you is too much for people and they think they need to turn development back into Subversion-style or desktop-release style.

I agree with you, with one addition in GitFlow's favor--it standardizes how your team works. When you have multiple team members collaborating on a project, a poor standard is better than none at all.
Post reply on HN