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

121–130 of 342 posts

Re: GitFlow considered harmful

#121

Post by ams6110 »

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

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 on projects using git than any I can recall, and that goes back to CVS and Visual Source Safe, also including svn and hg.

I know a lot of people use git and love it so I'm prepared to accept that they're all smarter than I am. But IMHO, the version control system should be incidental to my work. It should not demand any significant fraction of my brainpower: that should be devoted to the code I'm working on. 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 (which seems to happen to me when I use git) then it is a net negative. If I need to have a flowchart on my wall or keep some concept of a digraph in the front of my thinking or use a cheat sheet to work with the VCS, then it's just one more thing that gets in my way.

I think git probably has a place on very large codebases, with very distributed developers. For the typical case of a few developers who all work in the same office, I think in most cases it's overkill and people would be more productive using something simpler.

Re: GitFlow considered harmful

#122

Post by swsieber »

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

I usually use rewriting history to package the code I've worked on into logical commits that should be stable at each point when applied in order. That way, it's very easy to reverse a commit or cherry pick specific functionality into the production branch early (ie the main branch isn't the stable one).

Would I like to get away from that and do it from the get-go? Oh yes, it'd be great. But I'm not there yet and so re-writing history is nice. And doing so forces me to think about the code I've written and where the boundaries of the changes I've made are. Granted, I haven't done it on very long lived feature branches (or big ones) - that may be where most of the penalties are manifest.

Re: GitFlow considered harmful

#123

Post by ChrisMeek »

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…

I'm starting to think that part of the problem we are facing at the moment is that feature branching itself can be exceptionally harmful.

I see statements like "The power of git is the ability to work in parallel without getting in each-others way" and get really worried about what people are trying to achieve. I want my team's code to be continuously integrated so that problems are identified early, not at some arbitrary point down the line when two features are finished but conflict with each other when both are merged. We seem to be reversing all the good work the continuous integration movement gave us; constant integration makes integration issues smaller and easier to fix.

I personally prefer to use toggling and techniques like branch by abstraction to enable a single mainline approach. Martin Fowler has a very good article on it here http://martinfowler.com/bliki/FeatureBranch.html

Re: GitFlow considered harmful

#124

Post by krisdol »

Eridrus wrote: post #75
jaimebuelta wrote: post #28

The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct. That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness" - branches: Work in progress. - develop: Code ready to share with others. It can break the build (merge c…

Does having a lower level of quality on develop hinder your ability to actually release code? We have one particular repo at work that is just a pain in the ass to work with (Typescript analytics code that has to be backwards compatible to about forever), and we've pretty much abandoned the develop branch since releases got held up due to bugs in less important features that had been merged in without comprehensive t…

> We might have swung a little too far in the other direction

I think you're describing "GitHub flow", or how most people starting out with git would probably use it given no exposure to git-flow.

Github flow introduction: http://scottchacon.com/2011/08/31/github-flow.html

Documentation (it's really unnecessary if you get the idea): https://guides.github.com/introduction/flow/

Re: GitFlow considered harmful

#125

Post by wylee »

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

> The obsession of git users...

That seems overly broad. It seems to me that most people who use git agree that public history shouldn't be rewritten, especially on master.

> The whole point of history is to have a record of what happened.

On the other hand, a bunch of "Derp" or "Whoops" type commits aren't very useful. It's definitely beneficial to clean that sort of stuff up by rewriting local history before pushing.

Re: GitFlow considered harmful

#126

Post by kazinator »

cletusw wrote: post #120
[deleted] wrote: post #113

Earlier quoted context omitted.

[deleted]

I've always thought there had to be a way to solve the shared feature branch + rebasing problem! I'll have to try this out!

The only thing is, while it is easy from the downstream side, it's a little more tricky to prepare the new branch.

One thing you can do is actually do the regular rewriting rebase, install the result under the new name, and then throw the rewrite away.

Rebase our-topic.0 to its default upstream, thereby locally rewriting it:

   $ git rebase
(Precondition: no local commits in our-topic.0: it is synchronized with origin/our-topic.0, so they point to the same commit.)

Now, assign the resulting commit to the newly defined variable our-topic.1:

   $ git branch -t our-topic.1
Now, throw away the local modification to our-topic.0. We don't have to appeal to the reflog, because our-topic.0 is following a remote branch which we can reference:

   $ git reset --hard origin/our-topic.0
(Remember the precondition before all this: origin/our-topic.0 and our-topic.0 pointed to the same commit. Now they do again!)

Finally, push our-topic.1 for others to see:

   $ git push origin our-topic.1

Re: GitFlow considered harmful

#127

Post by platz »

ChrisMeek wrote: post #123
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…

I'm starting to think that part of the problem we are facing at the moment is that feature branching itself can be exceptionally harmful. I see statements like "The power of git is the ability to work in parallel without getting in each-others way" and get really worried about what people are trying to achieve. I want my team's code to be continuously integrated so that problems are identified early, not at some arbi…

Agree, avoid large merges at all costs. the longer a feature branch exists the more needless cost it incurs when trying to re-integrate it with the merge.

Re: GitFlow considered harmful

#128

Post by JanezStupar »

nsfyn55 wrote: post #102

I have had this ideological debate about "fast forwarding" more times that I can count. I agree with the author "no-ff" is silly. I've been working on professional software teams for over a decade. When I encountered fast forwarding/rebasing it was absolutely a breath of fresh air. I've been using git now for 5 years and I have not encountered a single instance where using either of these tools has presented any sort…

Because you do not need something, then it has to be useless.

> From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. Incredible irony.

Re: GitFlow considered harmful

#129

Post by Mithaldu »

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…

> 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 never flatten out and give way to easy and intuitive access to power.

Re: GitFlow considered harmful

#130

Post by aikah »

realityking wrote: post #49
chaitanya wrote: post #41

I have never understood why people hate merge commits so much. Their advantages are not insignificant: you know when a feature got merged in master, its much easier to revert a feature if you have a merge commit for it, much easier to generate a change log with merge commits, and you have none of the problems that pushing "cleaned up" histories will have: https://www.mail-archive.com/dri-devel@lists.sourceforge.net..…

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.

ask committers to use git rebase.
Post reply on HN