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

261–270 of 342 posts

Re: GitFlow considered harmful

#261

Post by kiallmacinnes »

phs2501 wrote: post #110
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.…

The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…

Agreed, most people hear "rewrite history" and immediately assume "public history".

Rebase is a part of code review. If someone spots a typo and a "fix typo" commit follows it up as happens for a good proportion of GitHub model projects, I cringe. This information is uttery useless to the projects history, and should be rebased as a fixup. Only once code review is done, should a commit be considered for merge. It's at this point that rewriting becomes a problem.

I think most people forgot where Git came from, git is designed from the ground up for this! When someone emails a series of patches to the kernel mailing list for review, they iterate that series of commits over and over until its ready. They don't keep adding new patches on top like the Pull Request model proposed by GitHub/GitLab etc do.

Re: GitFlow considered harmful

#262

Post by jes5199 »

mmgutz wrote: post #32
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…

I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.

all code is release code

Re: GitFlow considered harmful

#263

Post by juandazapata »

It's not confusing, maybe it's not suited for your particular case, as any other tool. There's no magic tool/process/etc that does it all for everybody.

GitFlow has been working great for us. A team of 15 developers, working with feature branches, we have our CircleCI configured to automatically deploy the "develop" branch to our "QA environment", and our "master" branch to "production" environment.

The "hotfix" and "release" are proven to be useful to us too; we just need to have effective communication with our team, so everybody rebase their feature branch after a merge in our main branches.

Re: GitFlow considered harmful

#264

Post by mcv »

sbov wrote: post #163
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.

Does anyone advocate rewriting shared history? Oddly I see this "exception" a lot in reply to this person but I'm not sure I ever read anywhere anyone saying rewriting shared history is a good idea.

My rule of thumb is that rewriting shared history is always, always bad. There may be situations where the proper precautions can mitigate the risk, but I've never seen a good example where it's actually a completely good idea without downsides.

Re: GitFlow considered harmful

#265

Post by jes5199 »

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…

Those are good techniques and I advocate them strongly.

Even so, I see value in very short-lived branches for code review. Ideally a branch exists for about four hours before it is merged to master.

Re: GitFlow considered harmful

#266

Post by mcv »

platz wrote: post #127
ChrisMeek wrote: post #123

Earlier quoted context omitted.

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.

Absolutely. Though you can mitigate that by merging develop into the feature branch often. It makes the merge back pretty painless.

Of course if you've got two long-living, contradictory feature branches, merging develop is not going to be enough. I guess you still need some communication in the team. But it's also important to keep your branches as short as you can. If you got a really big feature, try splitting it up.

Re: GitFlow considered harmful

#267

Post by comex »

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"?

This is somewhat different from the parent's view, but personally, I try to turn the list of commits in a given PR into a readable, reviewable "story" of the general steps that need to taken to implement a feature or fix a bug. (This starts when first writing it, because splitting up changes after the fact is a nightmare.) However, I do not want to limit myself to finishing and polishing one step before proceeding to the next. For one thing, my intuition might turn out to be wrong and the overall approach I'm aiming for might not be a good idea at all, something which I might only figure out when trying to implement the final feature/fix on top of the foundations. Or it might be a good idea overall, but I might end up realizing later that, say, out of the code I was fixing up in a previous commit, a lot of it is going to be removed by a later step in the refactoring anyway, so I should probably merge those steps or otherwise shuffle up the order. For another, I will probably just end up making mistakes, some of which I'll notice myself and some of which may be noticed in code review; while the "story" is primarily for code review, it is also useful for bisecting, so even changes found in review are good to integrate into the story.

As a result, when working on the project I'm thinking of, I use git rebase -i constantly, as if each commit were a separate file and I were switching between them in my editor. However, I don't actually like that old versions of my code are being thrown away (aside from reflog); I'd prefer if Git had two axes of history, one 'logical' and one 'real' (even if that gives people who already don't like branchy histories nightmares). I hear that Mercurial has something like this called "changeset evolution", but I haven't tried it; wish someone would make a Git port.

Re: GitFlow considered harmful

#268

Post by girvo »

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?

I work on multiple machines. Pushing my branch up even if it's busted code means I can continue work easily on other computers.

Re: GitFlow considered harmful

#269

Post by timr »

sytse wrote: post #78
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.…

I totally agree with you, I don't get it either. My only explanation is that as a programmer you are trained to write clean and understandable code. I also try to apply this to my commit messages (with varying results). But rewriting history to make everything look clean and simple is the wrong this to do. The messier your history is the more likely you'll need to retrace your steps (and CI results) at some point. It…

"But rewriting history to make everything look clean and simple is the wrong this to do."

Absolute statements are always wrong.

There plenty of great reasons to re-write your local history, many of which have been explored by other comments on this thread. Moreover, Linus disagrees with you -- the rebase flow is the one used by the author of git.

My guideline is that commits that don't have semantic meaning for your team should be avoided. It's therefore perfectly okay (desirable, even) to drop a "wip" commit in your local repository, but that commit is semantically meaningless, and shouldn't make it into shared history. Rebase!

Merge commits, likewise, should be avoided unless they carry semantic meaning. It's semantically meaningless to note that you've merged master back into your working branch N times since the initial branch point -- that's a development detail that is irrelevant to your peers. It's semantically meaningful to note that you've merged a feature branch into master. Your peers care about that.

You couldn't re-write history at all with SVN, so it's kind of goofy to suggest that this is legacy behavior. If anything, SVN had a problem that every pointless brain-fart commit by anyone, ever had to be preserved in the history. This made the history useless.

Re: GitFlow considered harmful

#270

Post by jes5199 »

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…

no-ff is useful when you need to revert the whole merge - the merge commit delimits the boundaries of what used to be a separate branch. If you fast-forward, then you have to use your human brain to figure out how many commits to revert and when you're reacting to "augh I just broke master by adding these 12 commits" you might make a mistake.
Post reply on HN