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

251–260 of 342 posts

Re: GitFlow considered harmful

#251

Post by mikeash »

kansface wrote: post #228
mikeash wrote: post #146

Earlier quoted context omitted.

Doesn't the merge commit for a branch like that serve the same purpose as your rebased commit, but without destroying the underlying history?

Merge commits, particularly those that merged master multiple times effectively destroy history (by preserving it). For that matter, many projects maintain all commits to master should work! Unless you advocate only committing entirely working states (unlikely for large features), you'd have to rebase.

Can you explain what you mean by effectively destroying history by preserving it? That doesn't make any sense to me. And I also don't understand the link between merge commits and a failure to ensure that all commits to master should work. If you make changes in a branch, get everything up and running there, then merge to master, does that not ensure that everything on master works?

Re: GitFlow considered harmful

#252

Post by mbesto »

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?

Immediate backup

(I hope I'm not alone in saying this...)

Re: GitFlow considered harmful

#253

Post by maratd »

StavrosK wrote: post #240
techiferous wrote: post #168

Earlier quoted context omitted.

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 prob…

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 the other hand, is the product of that successful resolution after all the bug fixes.

Re: GitFlow considered harmful

#254

Post by StavrosK »

maratd wrote: post #253
StavrosK wrote: post #240

Earlier quoted context omitted.

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 prob…

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.

Re: GitFlow considered harmful

#255

Post by adekok »

ams6110 wrote: post #121
mikeash wrote: post #72

Earlier quoted context omitted.

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

Disclosure up front, I don't really use git myself. I have tried it and found it to be too confusing. I liked svn and these days use hg. I also tend to work on mostly solo and small projects. However in my observation I have found that more than any other revision control system I have used, the person ultimately responsible for the code spends far more time cleaning up history and recovering from developer mistakes…

> Disclosure up front, I don't really use git myself. I have tried it and found it to be too confusing. I liked svn

Oh dear, that's bad.

> and these days use hg.

That's better.

> I also tend to work on mostly solo and small projects.

Ah. You probably don't need git then.

I've used a number of systems (RCS, CVS, SCCS, svn, monotone, hg, git). Of them all, hg was the simplest to use. Git was the most powerful.

Everything else listed above is terrible for multiple developers.

But solo developers? "tar" is a reasonable system for small projects. By that standard, SVN is fine, too.

Re: GitFlow considered harmful

#256

Post by mrbobdobbs »

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…

At our offices we use Pull Requests and Rebase as a combined work flow to get mostly linear history. Before issuing a PR we get the latest master, rebase our branch onto that so that all commits in our branch are approximately at the same time stamp and then issue a PR. This creates a nicely linear history for the most part.

The only evil is a willingness to force push the updated history over our branches before the PR goes up. But no one shares branches usually. Or the collaborators on a branch are few and they agree when to rewrite history.

Re: GitFlow considered harmful

#258

Post by comex »

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…

Maybe, but testing does not prevent all bugs and what happens once bisecting is needed still needs to be considered.

Re: GitFlow considered harmful

#259

Post by mcv »

Advising rebasing over explicit merges is dangerous and foolish. Rebasing does have its place, but you really need to know what you're doing.

Also, I don't see his point about that messy history. I can see exactly what happened in that history (though the branch names could have been more informative). With multiple people working on the same project, feature branches will save your sanity when you need to do a release, and one feature turns out to not be ready.

Re: GitFlow considered harmful

#260

Post by jes5199 »

gingerlime wrote: post #80
realityking wrote: post #49

Earlier quoted context omitted.

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.

slightly OT, but I wonder if anyone has an answer for this. We use feature branches and rebase before merging to master (mostly for the reason stated above - keep things clean and treating the branch as a single logical unit, not caring about higher-resolution history within the branch). However, some times, especially since we typically merge on Github from a PR, it's easy to forget to rebase, or notice that there a…

when you look at the PR in github it doesn't look obvious that some of the commits are bad?
Post reply on HN