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

231–240 of 342 posts

Re: GitFlow considered harmful

#231

Post by grayclhn »

mikeash wrote: post #221
grayclhn wrote: post #213

Earlier quoted context omitted.

Or... rewrite history. :) All of these problems are trivial when the commits are right next to each other; they're less trivial when they're separated by other unrelated commits. "Don't make idiotic mistakes" isn't really advice that anyone can follow.

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?

Re: GitFlow considered harmful

#232

Post by dankohn1 »

Thrymr wrote: post #219
dankohn1 wrote: post #159

We use a more extreme version of rebasing feature branches before merging into master: we squash the features into a single commit when merging to master. The reason is that we don't care about the (sometimes hundreds of) commits that made up a feature. What matters is that it works as designed and passes tests. If we merge a feature to master and then need to revert it, we will revert the whole feature. This also al…

That loses a lot of information, though. If you want to bisect to find a particular bug, tracking it down to the merge is a good start, but I'd rather have the actual commit (from the maybe hundreds) that went into the merge. Sure, you can revert the feature, but what if you want to fix the bug? Git history has a lot of commits. That's OK.

Yes, the downside of a much more streamlined commit log is that we do throw out information.

Re: GitFlow considered harmful

#233

Post by pc86 »

atomicUpdate wrote: post #142
pc86 wrote: post #92

Earlier quoted context omitted.

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.

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?

Re: GitFlow considered harmful

#234

Post by sopooneo »

aoeuasdf1 wrote: post #205
Jacqued wrote: post #172

Earlier quoted context omitted.

We've been fine using rebase on already pushed branches. This comes from the understanding that a feature branch belongs to one developer, ever, and that no one else is supposed to work off of it (or at their own peril). Everyone knows that it's "my branch" and that they're absolutely not supposed to use it for anything until it's merged back into master or whatever authoritative branch.

Ok, that makes sense... but then why bother pushing the branch in the first place?

We have a rule that you never go home at night without pushing your work, even if it's garbage. Put it in a super-short-term feature branch if needed, and push that, but don't leave it imprisoned on your machine.

Re: GitFlow considered harmful

#235

Post by nickbauman »

mikeash wrote: post #72
sytse wrote: post #24

GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier. The power of git is the ability to work in parallel without getting i…

The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…

Remember Git was born in Linux. And in Linux, a commit is a political statement. Your need to be succinct (your commit must stand along with 2000 commits per day) and emphasize the "obvious" brilliance of what you're doing to overcome noise overrides the need for recording all the thought processes along the way.

In most organizations, we don't have anywhere near that number of participants and we don't want charismatic developers, we want something that works right now and we're confident that changing it is not merely a possible outcome but very very likely.

Re: GitFlow considered harmful

#236

Post by orbitur »

I can distill my thoughts down to this:

The time it takes to carefully rebase a branch onto another, and to compress commits for a feature into one, is still much longer than the time it takes for my eyes to pass over so-called "empty" merge commits.

If I want to look at when a feature entered a branch, I can look at its merge commit. And the feature branches are there to show how a feature was built; bugs could be the result of a design decision that happened in one of the midway commits.

I looked at OP's example pic in the blog, and I read all of his words, but I wasn't sold. His picture looks like a normal git history to me. It requires almost no effort to find what I'm looking for.

And that's not even touching his rage against the idea of a canonical release branch (master). But that's for another day.

Re: GitFlow considered harmful

#237

Post by nhaehnle »

twic wrote: post #189
dkubb wrote: post #144

Earlier quoted context omitted.

Another nice side benefit is that you are able to use git bisect to find bugs more easily. If some of the commits fail the build then it becomes difficult to separate commits that actually introduce a bug from those that are just incomplete. The team I work with has recently started making sure every commit passes the build and it's had some fantastic results in our productivity. We know every individual commit passe…

You don't have to rewrite history to do this. You just have to run your tests before committing. You know, like people used to in the old days. Indeed, i think the widespread rewriting of history that goes on in the Git world makes it more likely that there will be failing commits, because every time you rewrite, you create a sheaf of commits which have never been tested. Now, in your case, it sounds like you have se…

Running test before committing locally adds a lot of friction. It often happens to me that I work on a feature in component A, and in doing so, realize that it would be great to have some additional feature in component B (or perhaps there's a bug that needs to be fixed).

As long as the components are logically separate, it's usually a good idea to make those changes in separate commits. While you can do that using selective git add, I personally often find it more convenient to just have a whole bunch of rather small "WIP" commits that you later group and squash together in a rebase.

Not least of the reason is that I like to make local commits often in general anyway, even when I know that the current state does not even compile. It's a form of backup. In that case, I really don't want to have to run tests before making commits.

And obviously, all of this only applies to my local work that will never be used by anybody else.

Re: GitFlow considered harmful

#238

Post by Mithaldu »

to3m wrote: post #138
Mithaldu wrote: post #68

Earlier quoted context omitted.

Please tell me what company you work at so i can avoid it. There's no other way to say it other than that your ideas horrify me.

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.

Re: GitFlow considered harmful

#239

Post by yellowapple »

aoeuasdf1 wrote: post #205
Jacqued wrote: post #172

Earlier quoted context omitted.

We've been fine using rebase on already pushed branches. This comes from the understanding that a feature branch belongs to one developer, ever, and that no one else is supposed to work off of it (or at their own peril). Everyone knows that it's "my branch" and that they're absolutely not supposed to use it for anything until it's merged back into master or whatever authoritative branch.

Ok, that makes sense... but then why bother pushing the branch in the first place?

For me, it's because I hop between development machines, and pushing/pulling a branch is much easier than the alternative of synchronizing files manually among said machines.

Also, so that if something goes awry with my dev machine for whatever reason, at least my work is saved.

Also, to make it easier for a colleague to review my code before it gets merged into something.

Also, becuase it means I can use GitHub's PR system instead of doing it on my machine (thus providing some additional record that my code got merged in, and providing an avenue for the merge itself to be reviewed and commented on).

Re: GitFlow considered harmful

#240

Post by StavrosK »

techiferous wrote: post #168
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…

We follow a similar process where I work and it works really well. Something being merged into development means that it is 100% complete and ready to be deployed to production at any time. This means all QA and acceptance testing had to happen before merging.

What you're describing doesn't make very much sense. There are only two cases here:

1) A feature that's in develop may sometimes need to wait for something (QA, business validation, a go-ahead, whatever) to go to master, or 2) A feature that's in develop can ALWAYS go to master at any time.

In the first case, you can have feature X blocking all other features because it's in the same branch as them, which is the problem the GP is describing. In the second case, the two branches are the same, so why not just merge into master directly?

Post reply on HN