GitFlow considered harmful • Hacker News Board

Re: GitFlow considered harmful

#271

Post by isaacremuant » Fri, Jun 19, 2015, 10:52 PM UTC

LukeB_UK wrote: post #6

Anyone else fed up of articles using "considered harmful" in the title? Especially when it's just that the author doesn't like that thing.

I am. I resent such articles unless they come from a very clear eminence who has public and verifiable evidence to support his case.

This seems more of a: "This tool is popular but it doesn't work for me so it's bad".

In fact, as you say, he dislikes the tool (from the get go):

> I remember reading the original GitFlow article back when it first came out. I was deeply unimpressed - I thought it was a weird, over-engineered solution to a non-existent problem. I couldn't see a single benefit of using such a heavy approach. I quickly dismissed the article and continued to use Git the way I always did (I'll describe that way later in the article). Now, after having some hands-on experience with GitFlow, and based on my observations of others using (or, should I say more precisely, trying to use) it, that initial, intuitive dislike has grown into a well-founded, experienced distaste.

Throwing my two cents. There's no perfect methodology and teams that communicate and adhere to a set of standards will probably find a good way to work productively with git. They can always be helped with scripts like the gitflow plugin or some other helper if they think the possibility of human errors is big.

I also have anecdotal experience of working with and without and, being fine with either although I do appreciate git flow in any project that starts getting releases and supporting bug fixes, hot fixes and has been living for a while so it incorporate orthogonal features at the same time.

Re: GitFlow considered harmful

#272

Post by Skinney » Fri, Jun 19, 2015, 10:57 PM UTC

pc86 wrote: post #233

atomicUpdate wrote: post #142

Earlier quoted context omitted.

In your scenario, Feature B should not have been promoted into the development branch until everyone agrees it's going to be shipped. If it got into development without everyone's approval, then that is a business process problem, not a CVS tool problem. At my last job, we had a 'gorilla' that had to approve every commit, and it was his job to coordinate between the project managers and the developers as to what was…

In that scenario is everything in develop simply waiting to be pushed to master, with no additional testing/approval? At that point why not push directly from feature branches into master?

Because features are not always isolated, sometimes they change behaviour based on changes in other branches. Testing features in isolation is different from testing an entire release.

Re: GitFlow considered harmful

#273

Post by Skinney » Fri, Jun 19, 2015, 11:04 PM UTC

StavrosK wrote: post #254

maratd wrote: post #253

Earlier quoted context omitted.

It's always #2, but just because a feature has been approved for master, doesn't mean all the features approved for master are stable together . A feature might be stable as a standalone, but in virtually every software suite, features interact with each other. That is what develop is for. It's where all the feature branches meet and where any instability created by everything coming together is resolved. Master, on…

I've found that that generally leads to problems, so I prefer to have the feature that is going to be merged last be responsible for fitting in with the rest. That way, as described earlier, I don't have to wait for features that can't be merged now to merge the ones that can.

How do you know which feature will be merged last? In the teams I've worked in previously, everything happened in parallel. You had no way of knowing what feature was going to be merged when. So, essentially, we completed a feature-branch, tested it, and merged it into develop. Then, at set intervals, we did some heavy testing on develop and fixed any outstanding bugs, before creating a release by merging to master.

Re: GitFlow considered harmful

#274

Post by dekz » Fri, Jun 19, 2015, 11:11 PM UTC

pc86 wrote: post #92

maratd wrote: post #85

Earlier quoted context omitted.

I'm a bit confused, why are you merging things into develop if they're not ready? If Feature B isn't ready, it should stay in its own branch until it is. Develop is for code that the developers say is ready. You might have bugs, poor merge resolution, etc, but any fixes made should be quick and should pave the path toward code that can be merged into master. If the problems are major, revert develop. Master, on the o…

In the above example, say Feature A gets the go-ahead from the business user/product owner/whatever, and Feature B doesn't. From the dev standpoint both are complete but there may be some business reason to hold up Feature B. The owner(s) of Feature A are likely not going to understand why anything to do with Feature B has to hold up their release.

Wrap Feature B in a feature toggle if its development ready but not business ready. Then when it is business ready, flip that toggle.

Re: GitFlow considered harmful

#275

Post by JulianMorrison » Fri, Jun 19, 2015, 11:22 PM UTC

The whole point of hotfixes is that they are relative to old code and that they alter what is considered the current version of that old release. Which is important when (as is typical in business) you have customers who are on specific releases and either haven't paid for the new hotness, or haven't integrated to it and don't yet want it.

So absolute minimum you need one persistent branch per old release, if you ever hotfixed it and still have it deployed in the field. GitFlow falls over here, because it only has one master. But at least it does recognize the fact that repairing released code is different from pushing the unreleased state of the art forward.

Re: GitFlow considered harmful

#276

Post by to3m » Fri, Jun 19, 2015, 11:23 PM UTC

Mithaldu wrote: post #238

to3m wrote: post #138

Earlier quoted context omitted.

What would your approach to this problem be?

I don't understand why you ask this. I already presented my solution to the problem in the post he was replying to. That one is still valid.

Surely it isn't a great idea once "the" repo has a copy of the dodgy commit, though? Because once everybody else has a copy of it, the history hashes will include it, and removing it with a rebase is going to become more bothersome.

(N.B., I am English - by "bothersome" what I suppose I actually mean is "a massive pain in the arse". Because everybody is going to have to take all their commits since the dodgy one and rebase them on top of the new history. Maybe I should rephrase that to "a massive pain in the fucking arse". But it's always possible there's some git magic I'm not aware of.)

Re: GitFlow considered harmful

#277

Post by glandium » Fri, Jun 19, 2015, 11:29 PM UTC

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.

Mercurial branches are not meant to be used for short-lived feature branches, though. As "hg branch" puts it: "branches are permanent and global, did you want a bookmark?".

Re: GitFlow considered harmful

#278

Post by grayclhn » Fri, Jun 19, 2015, 11:35 PM UTC

mikeash wrote: post #249

grayclhn wrote: post #231

Earlier quoted context omitted.

Fair enough. I agree that rewriting history shouldn't replace other good practices. But I don't really see the benefit of having an exact historical record of all the mistakes made when coding. What does it get you?

It's not so much what the true historical record gets you, but what you potentially lose with the fake one. Do the commits in your edited history actually work? If you go back to see why a given change was made, will you get an accurate picture of the state of the rest of the code at that time?

But one of the points of editing the history is to make sure that both of those are more likely to be yes -- it's to make the history easier to review historically than it would be unedited. (IMO, obviously).

And this is probably partly why there's what you originally called an "obsession" with rewriting history: retroactively rewriting something 5 months old is probably going to be a disaster. But rewriting 1 day's worth of commits to better express why a given change was made, to give a more accurate picture of the state of the rest of the code, and to make things in general easier for people to read in the future is pretty trivial. So why not do it?

Re: GitFlow considered harmful

#279

Post by ealloc » Fri, Jun 19, 2015, 11:36 PM UTC

kiallmacinnes wrote: post #261

phs2501 wrote: post #110

Earlier quoted context omitted.

The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…

Agreed, most people hear "rewrite history" and immediately assume "public history". Rebase is a part of code review. If someone spots a typo and a "fix typo" commit follows it up as happens for a good proportion of GitHub model projects, I cringe. This information is uttery useless to the projects history, and should be rebased as a fixup. Only once code review is done, should a commit be considered for merge. It's a…

In my Github experience, rebasing/tidying your commits is expected before a Pull Request is merged, just like your description of Linux development. Eg, the numpy/scipy/matplotlib projects.

Re: GitFlow considered harmful

#280

Post by hayd » Fri, Jun 19, 2015, 11:45 PM UTC

kiallmacinnes wrote: post #261

phs2501 wrote: post #110

Earlier quoted context omitted.

The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…

Agreed, most people hear "rewrite history" and immediately assume "public history". Rebase is a part of code review. If someone spots a typo and a "fix typo" commit follows it up as happens for a good proportion of GitHub model projects, I cringe. This information is uttery useless to the projects history, and should be rebased as a fixup. Only once code review is done, should a commit be considered for merge. It's a…

Then someone else rebases over that commit, there's a conflict and lo! the tests fail. Why? typo. It's fixed in the subsequent commit (which you can't see). Lovely.

There's something to be said for having every commit pass tests/work (or if it doesn't saying explicitly in the commit message), if anyone is ever going to step over this commit.