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

111–120 of 342 posts

Re: GitFlow considered harmful

#111

Post by sytse »

Mithaldu wrote: post #91
sytse wrote: post #88

Earlier quoted context omitted.

I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases. But there are certainly people that preferred having some commits rebased so it was easier to revert them (reverting a merge is possible but harder). Although I'm not an active developer myself I think my dislike of rebasing everything is shared.

> I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases. Would you elaborate on that please? I don't know what your situation is like that would cause rebasing to make spelunking harder. > reverting a merge is possible but harder Funny, someone else further down claimed reverting merges is easier. :)

Because you rewrote history it is harder to see what was written, tested by hand and tested with CI at what time.

Re: GitFlow considered harmful

#112

Post by Joky »

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

There is difference between rewriting a "published" history from your local repo. I am heavily relying the ability to rewrite history before pushing. I hate seeing people pushing a series of commits (in a single push I mean) where the two first ones introduces a big mess and the subsequents are tentative to fixup the mess.

Re: GitFlow considered harmful

#113

Post by [deleted] »

Mithaldu wrote: post #89
jrochkind1 wrote: post #84

Earlier quoted context omitted.

I tend to agree. One exception I think is rebase on a feature branch. If you rebase a feature branch onto master before merging it into master, I think you can get a cleaner history while achieving the linear history the OP wants -- and in this isolated case, I think you aren't losing any useful context by making it seem the feature commits were all done right before merge into master. Maybe. I'm not actually sure, t…

People who love rebasing and linear history tend to see feature branches, even if pushed to a public repository, as private to their creator and maintainer and fair game for any sort of rebase. In fact, we do consider rebasing of feature branches mandatory.

[deleted]

Re: GitFlow considered harmful

#114

Post by madeofpalk »

Touche wrote: post #81
Alexandervn wrote: post #48

Earlier quoted context omitted.

Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people. - Feature branch: do whatever you want - Develop: should be good enough for the client (product owner) to look at - Release branch: should be good enough to be tested by the test/QA team - Master: should be good enough for website visitors Branches are meant to be shortlived and merged (and code reviewed) into develop…

The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix…

I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.

Re: GitFlow considered harmful

#115

Post by Mithaldu »

sytse wrote: post #111
Mithaldu wrote: post #91

Earlier quoted context omitted.

> I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases. Would you elaborate on that please? I don't know what your situation is like that would cause rebasing to make spelunking harder. > reverting a merge is possible but harder Funny, someone else further down claimed reverting merges is easier. :)

Because you rewrote history it is harder to see what was written, tested by hand and tested with CI at what time.

Another social issue. In the projects i work with, it is commonly agreed upon and known that of course after a rebase every commit needs to be retested and reverified with CI. It is a bit of extra work, but as i mentioned in another commit: We do that extra bit of work now, to avoid having to analyze the cross-talk of a bunch of branch merges at a later point; mainly because that bit of later work often turns out to be considerably bigger. (Technical debt is a talking point here.)

Of course, this might be unviable when under unusual time pressures.

Re: GitFlow considered harmful

#116

Post by Mithaldu »

[deleted] wrote: post #113
Mithaldu wrote: post #89

Earlier quoted context omitted.

People who love rebasing and linear history tend to see feature branches, even if pushed to a public repository, as private to their creator and maintainer and fair game for any sort of rebase. In fact, we do consider rebasing of feature branches mandatory.

[deleted]

Yes, thank you for explaining this so well. I commented on that elsewhere, but didn't do it nearly as well as you did.

Re: GitFlow considered harmful

#117

Post by sytse »

darylteo wrote: post #98

Curious here: has anyone tried using GitLab + forks to replace development branches? Would it needlessly overcomplicated?

You can do it but at GitLab we advise against it if you can avoid it. Many things become harder, for example it is more work to to link merge requests to issues and you can't push a commit to help a person without them giving you access first.

Re: GitFlow considered harmful

#118

Post by ascendantlogic »

Joky wrote: post #112
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.…

There is difference between rewriting a "published" history from your local repo. I am heavily relying the ability to rewrite history before pushing. I hate seeing people pushing a series of commits (in a single push I mean) where the two first ones introduces a big mess and the subsequents are tentative to fixup the mess.

This. So much this. I hate looking through history and seeing crap like "lol forgot semicolon". Rebasing when you're still in your feature branch before the code hitting master to make your commits succinct, readable and above all not contain known broken code is a must.

Re: GitFlow considered harmful

#119

Post by kazinator »

Mithaldu wrote: post #101
jrochkind1 wrote: post #97

Earlier quoted context omitted.

The counter argument though is when your feature branch doesn't only have _one_ creator/maintainer. Mine often don't, especially on open source projects, two or three people can be working collaboratively, or others that aren't the lead on the feature can come in to make a helpful commit here or there. And when one person rebases the feature branch it wreaks havoc for collaborators on the feature branch. Which is why…

If you have a handful of people, you simply communicate with them, check that there's a good reason to rebase and that you're not creating unnecessary burden and do it when everyone is happy. When you have more than a handful of people, then your feature branch is not a feature branch, but a project, which should have feature branches of its own. Scale, dynamic adaption to it and situational awareness are a requireme…

Bingo! Recently I've been working on resolving a bug with a small group of coworkers. We created a repo in which we have been rewriting public branches all the time. You just send an e-mail. Everyone just has to know how to migrate their local changes.

   $ git fetch # the rewritten world
   $ git checkout
   Your branch and 'origin/foobar' have diverged,
   and have 13 and 17 different commits each, respectively.
   (use "git pull" to merge the remote branch into yours)
Now I happen to know that only 3 out of the 13 divergent commits on foobar are my local commits. I rebase my local foobar branch to the upstream one, migrating just those 3, and ditching the remaining ten:

   $ git rebase HEAD~3 origin/foobar
Easy.

This is all just test code people are trying in investigating the bug. Any permanent fixes arising are properly cleaned up, commented, and submitted via Gerrit to a whole other repo where they are cleanly cherry picked to a linear trunk which is never rewritten.

Re: GitFlow considered harmful

#120

Post by cletusw »

[deleted] wrote: post #113
Mithaldu wrote: post #89

Earlier quoted context omitted.

People who love rebasing and linear history tend to see feature branches, even if pushed to a public repository, as private to their creator and maintainer and fair game for any sort of rebase. In fact, we do consider rebasing of feature branches mandatory.

[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!
Post reply on HN