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

221–230 of 342 posts

Re: GitFlow considered harmful

#221

Post by mikeash »

grayclhn wrote: post #213
mikeash wrote: post #188

Earlier quoted context omitted.

Well then, try to structure things so you're catching those idiotic mistakes before you commit them. The consequences you describe seem extremely mild. Cherry-picking now requires two cherry-picks instead of one, big deal. Git bisect has a "skip" command that solves this nicely. And I don't see how code review is at all impacted by this, unless you're using terrible tools that won't show a full summary of changes all…

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.

Re: GitFlow considered harmful

#222

Post by CrystalGamma »

adevine wrote: post #74
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 biggest disadvantage I see isn't in the branching model per se - it's that git itself does not record branch history. By "does not record branch history" I mean that branches are really just pointers to a specific commit in the commit history. However, git doesn't record where that branch pointed to IN THE PAST. So, when looking back in time and you look at a merge commit (say between a feature branch onto develo…

This is exactly what I like about git and don't like about Mercurial: keeping book about which was what does not matter IMO, and complicates (automatic) reasoning (e.g. bisect) about the development process. What does matter is that concurrent development took place, and that's exactly what git's commit DAG represents.

Re: GitFlow considered harmful

#223

Post by nijiko »

Do what is easiest for you.

1. Merging vs Rebasing

Open source projects should stick with Merging over cherry-picking and rebasing especially if you want others to contribute. Unless you feel fine doing all of the rebasing and cherry-picking for them. Otherwise, good luck gathering a large enough pool of people to contribute. Simplicity always wins here.

2. GitFlow vs X

Once again do what is good for your company and the people around you. If you have a lot of developers having multiple branches is actually /beneficial/ as Master is considered ALWAYS working. Develop branch contains things that are ready to ship, and only things that are READY TO SHIP. So if your feature isn't ready yet, it can't go to develop, and it won't hit master. Your features are done in other branches.

3. Rewriting history

Never do this. Seriously, it will come to bite you in the ass.

4. Have fun.

Arguing is for people who don't get shit done.

Re: GitFlow considered harmful

#225

Post by jamesmiller5 »

DougWebb wrote: post #160
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…

If you're using CI testing results and tying them to particular commits, you end up with the same problem whether you merge or rebase. If you test a commit and it passes, and then merge that commit into master, the merge may have changed the code that the commit modified, or something that the commit's code depended on . The green flag you had on the commit is no longer valid because the commit is in a new context no…

This is exactly how I setup our teams workflow. Private commits are pushed into gerrit run against the CI suite.

  1. If reviews + CI tests go well we fast forward merge onto master.
  2. If the commit's parent isn't the latest commit on master, it is automatically rebased and the CI suite is kicked off again.
  3. Upon successful fast forward merge into master, all in-flight reviews are automatically rebased on master's new head and CI's kicked off again.
  4. Any open commit can become the top of master without worry it will break the build.
For our team of ~10 this works exceptionally well with master not being a broken due to our code in the last ~6 months. (edit: formatting)

Re: GitFlow considered harmful

#226

Post by davidp »

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?

Code reviews -- you can create a PR on the pushed code, make fixes in response to the comments, rebase, and re-push.

Re: GitFlow considered harmful

#227

Post by slavik81 »

mikeash wrote: post #149
wylee wrote: post #125

Earlier quoted context omitted.

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

I'm talking about both public and private history. It's far more beneficial to just not make commits like "Derp" or "Whoops" in the first place. Think about your commits and your commit messages as you make them . No, you won't get it right all the time. And that's OK; nobody is perfect, and your history can reflect that you're not perfect. But if you're editing your commit history to fix idiotic commit messages, you…

One of the things I like about git is that I can make bad commits and fix them later. If I'm working on one feature and I'm interrupted by another task, I can commit "wip - blah", then check out a different branch and work on that. When I go back, I pick up exactly where I left off, and amend the half-finished commit into something that actually makes sense before pushing it out to the rest of the team.

In the past, I never made those sorts of commits, because I used VCSs in which you couldn't. Instead, I avoided committing by checking out a separate workspace for the new work. That's a lot slower, though, and it's easier to lose uncommitted changes. Committing incomplete, broken work allows you to leverage your VCS to manage even your unfinished code.

Re: GitFlow considered harmful

#228

Post by kansface »

mikeash wrote: post #146
jkyle wrote: post #132

Earlier quoted context omitted.

Say I create a feature branch, this is what a day's work might look like. 839a882 Fix bad code formatting [James Kyle] 6583660 Updated plugin paths for publish env [James Kyle] 847b8f3 First stab at a mobile friendly style. [James Kyle] a70d3f7 Added new articles, updated a couple. [James Kyle] b743ec3 format changes on article [James Kyle] 68231e7 Some udpates, added an article [James Kyle] 2a92c5e Added plugins to…

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.

Re: GitFlow considered harmful

#229

Post by Profan »

Mithaldu wrote: post #76
tokenizerrr wrote: post #73

Earlier quoted context omitted.

Wow, way to be literally the opposite of constructive. Grow up.

We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.

The constructive thing in this case would be to introduce your own solution to the problem and argument for it, not bring the level down to day-care level and go all "wow, i'm just gonna avoid you now.".

Re: GitFlow considered harmful

#230

Post by kansface »

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…

Stop merging from Github?
Post reply on HN