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

241–250 of 342 posts

Re: GitFlow considered harmful

#241

Post by joshuacc »

mikeash wrote: post #211
jasode wrote: post #201

Earlier quoted context omitted.

>, but if you're fearful of breaking builds, then once you did make such a mistake, the ability to go back and rewrite it would surely look pretty good. But I was trying to emphasize that Git's "mental model" eases the burden breaking the build. If everyone buys into the concept that "git commits" are just another lightweight form of "Ctrl+S", we would expect for programmers' private branches to sometimes have broken…

When you say it's another form of ^S, how often are we talking here? I reflexively ^S every couple of words, are you literally talking about committing every couple of words? Every few lines? Less? What's the purpose committing more often than logical chunks of code which can be considered in some sense "done"?

Can't speak for the GP, but I often commit my changes every 3-4 minutes with messages like "Tweaked the padding." Then when my work is in a reasonable state to be viewed by someone else, I'll turn those 5-6 local commits into one coherent "feature commit" like "Redesigned the page header according to new brand guidelines."

Re: GitFlow considered harmful

#242

Post by 5outh »

On the main project I'm working on, the reason we have develop/master is mainly for hotfixes.

We deploy once a week, but if we need to get something out the door quickly, we make a hotfix branch off of master, then merge it into both develop and master. This way, if we find something that needs to be fixed before the next release, but don't want to push half-done updates, we can seamlessly do it.

Re: GitFlow considered harmful

#243

Post by Mithaldu »

Profan wrote: post #229
Mithaldu wrote: post #76

Earlier quoted context omitted.

We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.

The constructive thing in this case would be to introduce your own solution to the problem and argument for it, not bring the level down to day-care level and go all "wow, i'm just gonna avoid you now.".

I already introduced my own solution in: https://news.ycombinator.com/item?id=9744402

To which his only complaint was "this rewrites history", followed by "i'll rather fuck over future developers by throwing in a revert blob followed by a revert-revert blob followed by ANOTHER merge only this time slightly different".

There is no point in arguing with someone who thinks that is in any way reasonable. Additionally there is nothing day-care level about this. I've had clients like that, big companies too. Arguing for all sort of development horrors. I've fired those clients. I'd rather spend my time on companies that value the sanity of their people.

So, really, i don't give a fuck. And unless he comes back with something along the lines of "i've realized that what i've been doing is sheer insanity and torture of myself and fellow developers", i don't care to hear what he has to say, the same as i am sure he doesn't care what i have to say.

And really, i don't care whether you think what i am saying is constructive either. This factitious politeness that you and people like you insist upon is a blight on this industry. Please give me all the downvotes you can muster. It pleases me if i manage to upset people by being earnest, honest and direct, since it tells me more about their character than they're ever likely to realize themselves; and maybe, just maybe, they might end up wondering "Why is that guy so mean to me and doesn't even feel bad about it? What have i done wrong?"

And if you actually care to find out something, if a constructive dialogue is your goal, then don't start it out with statements borne of inexperience and lack of knowledge. Start it out with the only question that matters:

Why?

Re: GitFlow considered harmful

#244

Post by [deleted] »

Bahamut wrote: post #70

One thing that bothers me about GitFlow is that it mangles history with merges. Sometimes it becomes tricky to debug issues when history was created with GitFlow. I would rather branch off of master, bring changes in via git am or rebasing when ready, then tag a release when it is ready to be released. If there is something wrong with master, the tagged releases serve as easy points to branch off of.

[deleted]

Re: GitFlow considered harmful

#245

Post by pacquiao882 »

Bahamut wrote: post #70

One thing that bothers me about GitFlow is that it mangles history with merges. Sometimes it becomes tricky to debug issues when history was created with GitFlow. I would rather branch off of master, bring changes in via git am or rebasing when ready, then tag a release when it is ready to be released. If there is something wrong with master, the tagged releases serve as easy points to branch off of.

I think it depends on the project's structure and team discipline. I tend to prefer straight lines in the history where a single feature or a group of similar functions are linear.

Re: GitFlow considered harmful

#246

Post by Mithaldu »

ams6110 wrote: post #139
Mithaldu wrote: post #129

Earlier quoted context omitted.

> If I have to stop and THINK about the VCS every time I use it, or if it gives me some obscure "PC LOAD LETTER" type of response I'm sorry, there is no kind way to say this without spending too much time i don't have. You're making the same kind of argument i am hearing from older people in my family about newer hardware (tvs, phones, etc.). You see an initial learning curve and falsely assume that this curve will n…

spending too much time i don't have And yet here you are commenting on HN. Well, I am older, actually. Maybe it's just part of what happens. I still miss my flip phone too. So much simpler....

> And yet here you are commenting on HN.

In other words: I was close to leaving my upvote and walking away, but decided to not leave you wondering, since you DID spend some effort and thought in your post.

> Well, I am older, actually. Maybe it's just part of what happens. I still miss my flip phone too. So much simpler....

It's actually what happens. I'm feeling the same way about various things as i'm getting older. I can't be arsed to figure out what Docker is, for example. Ain't nobody got time for that. Otoh, i do realize that's just me and it's probably a great thing that i hope the sysadmins i work with will know to pick up and make use of its potential.

Re: GitFlow considered harmful

#247

Post by clinta »

geertj wrote: post #193
wylee wrote: post #134

Earlier quoted context omitted.

I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.

> Rewriting shared history is (almost) always bad. Agreed. The one counterexample that I have is Github pull requests. Those are actually branches in your fork, and you do want to rewrite those when you get feedback on a pull request. That makes it easier for the owner of the repo to do the merge later.

Why do you need to rewrite? If a pull request is not completed, you can continue to push it and the PR is updated to pull the latest commit.

Re: GitFlow considered harmful

#248

Post by talles »

CrystalGamma wrote: post #224
talles wrote: post #8

I second the feeling of GitFlow being over-engineering: http://blog.talles.me/that-git-flow.html

little typo: vMAJOR.MINOR.PATH => vMAJOR.MINOR.PATCH And I must say I agree with all you say in that post.

A downside of always typing, never copying and paste.

Thanks!

Re: GitFlow considered harmful

#249

Post by mikeash »

grayclhn wrote: post #231
mikeash wrote: post #221

Earlier quoted context omitted.

I think it depends on what kind of idiotic mistakes we're talking about. Stuff like forgetting a semicolon is completely avoidable with a disciplined approach of, "Always build before you commit." Other kinds aren't so nicely avoidable, but then I think the record should show them anyway.

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?

Re: GitFlow considered harmful

#250

Post by sorbits »

clinta wrote: post #247
geertj wrote: post #193

Earlier quoted context omitted.

> Rewriting shared history is (almost) always bad. Agreed. The one counterexample that I have is Github pull requests. Those are actually branches in your fork, and you do want to rewrite those when you get feedback on a pull request. That makes it easier for the owner of the repo to do the merge later.

Why do you need to rewrite? If a pull request is not completed, you can continue to push it and the PR is updated to pull the latest commit.

I will get pull requests where later commits fix bugs introduced in former commits.

I generally ask people to rewrite such PRs, as I’m not going to pull known buggy commits into master, even if they are followed by fixes. That is just noise.

It might also be that some commits in the PR has changed tabs to spaces or vice versa.

Post reply on HN