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

201–210 of 342 posts

Re: GitFlow considered harmful

#201

Post by jasode »

mikeash wrote: post #190
jasode wrote: post #181

Earlier quoted context omitted.

>Why are you committing code you haven't even tried to build? Because a DVCS tool like Git makes commits much less costly than older tools such as CVS or SVN. The dynamics (both social & personal) for commits are different. My guess is that you understand Git commands but you're using the SVN/CVS mental model of treating commits as "sacred" markers. If someone commits in those older centralized systems, they could po…

I wouldn't go so far as to say that they're sacred, but I do think you're right that a disagreement over their relative importance is probably at the core of this. However, I think the stuff about breaking the build is way off. If one were really fearful of any commit breaking the build, wouldn't one embrace rewriting history? You'd try to avoid making a breaking commit in the first place, but if you're fearful of br…

>, 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 builds. That's the nature of real-world work such as refactoring or experimental changes. There's no social penalty or stigma for broken builds in private repos. Therefore, if a programmer rewrites history to hide broken builds, it's not because of ego or image-consciousness but because of consideration for others to read a comprehensible story of the changes.

You made a commit that broke the build? Well, try not to do that, but as long as you don't push it, it's not a big deal. Fix it (in a new commit!) and you'll push both of them together. History is preserved, nobody's build actually broke, everybody's happy.

Not everybody's happy. If we conceptually treat git commits as a 2nd form of "ctrl+s", we don't want to see both commits. Instead, clean up your private history, then craft/squash/edit your commits into a logical story, then make sure your public history has a clean build, and then apply those commits to the public branch. That's the way Linus Torvalds likes it for Linux patches and many agree with him. We do want some history to be preserved but not all of it.

Re: GitFlow considered harmful

#202

Post by dicroce »

Even though I could frequently commit on feature branches, I usually don't. Hence, when I merge feature branches I don't have crazy messy histories that I feel it necessary to rewrite.... Works for me.

Re: GitFlow considered harmful

#203

Post by habitue »

rdsubhas wrote: post #196

A single eternal master works for a Continuously Deployed app/site. Not for any other project where maintenance releases are a norm. This includes stuff strict API compatibility projects, semantically versioned frameworks/plugins/libraries, many forms of desktop/offline apps, some android apps, most enterprise apps, etc - more or less where developers don't have the liberty to thrust the latest master on their users.…

Right, when you need to maintain (and patch) old versions of a piece of software, having eternal release branches is necessary. The fixes on those old versions often don't ever want to be merged back to master because the code is very different in more recent versions.

Re: GitFlow considered harmful

#204

Post by dkubb »

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…

Yeah, obviously we do that (well maybe not so obvious to some, but I never push unless the tests pass). We sometimes perform lots of other things like static analysis that get in the way of a rapid feedback loop. We also run mutation testing, which can sometimes take several hours for the whole codebase -- although we don't have this run on every commit, just ones that we merge into a specific branch.

The problem I have with non-linear commit history is that I find it impossible to keep all the paths straight in my head when I am trying to understand a series of changes. Maybe you can do that, and I think that's awesome, but I like to see a master branch and then smaller feature branches that break off and then combine back with master.

Re: GitFlow considered harmful

#205

Post by aoeuasdf1 »

Jacqued wrote: post #172
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.

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?

Re: GitFlow considered harmful

#206

Post by mikegerwitz »

chaitanya wrote: post #106
adevine wrote: post #74

Earlier quoted context omitted.

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…

The only solution I can think of is to write a prepare-commit-msg hook that adds a line like "On branch: " to the commit message. So when reading your commit history, every commit that was made on this branch would contain this message. You can also look up just commits made on a particular branch by doing `git log --grep="On branch: "` this way.

I wrote a `git-state` command for this:

  https://gitlab.com/mikegerwitz/git-supp/tree/master#git-state
At the very least, it may be useful as a starting point.

While I use it extensively on large projects, I find that the merge commit can do just as well. Of course, that doesn't help you outside context of the merge commit---bisecting, for example---unless you are okay with discovering the merge commit that introduced it into the mainline. That can still be scripted.

Re: GitFlow considered harmful

#207

Post by songshu »

I wish GitFlow had not called that branch "master", and had called it "released" or "production" instead. It's really useful to have a branch which you know always exactly represents the code running in production. You can keep an IDE pointed at somewhere and update when you need to without worrying about tags or whatever. This is the one part of it I've tried to sell to colleagues, which would have been easier if it had a better name.

Re: GitFlow considered harmful

#208

Post by npizzolato »

kazinator wrote: post #126
cletusw wrote: post #120

Earlier quoted context omitted.

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/o…

Seems like you could simplify this quite a bit by just creating our-topic.1 before rebasing. Given our-topic.0 == origin/our-topic.0, and our are currently at our-topic.0

    $ git checkout -b our-topic.1

    $ git rebase (-i) master

    $ git push origin our-topic.1
No need to modify and reset our-topic.0.

Re: GitFlow considered harmful

#209

Post by gouggoug »

GitFlow is also in my opinion a bad flow as it does end up with a merge commit spaghetti over time.

Merge commits are great. They are here to group a list of commits into a logical set. This logical set could represent one "feature", but not necessarily. It is up to you to decide whether commits A B C D should or shouldn't be grouped by a merge commit. Merge commits also make regression searchs (i.e. git bisect) a lot faster. And to top it of, they will make your history extremely readable, but that is granted you merge correctly... and that is where git rebase and git merge --no-ff come into play.

At my company, every developer must rebase their topical branch on top of the master branch before merging. Once the topical branch is rebased, the merge is done with a --no-ff. With this extremely easy flow, you end up with a linear history, made of a master branch going straight up and only everyonce in a while a merge commit.

Our commit history looks like this:

  *-------------*---------*---------*----------*----*------->
   \-----------/          \---------/           \--/
Following the simple rule "commit, commit, commit..., rebase, merge --no-ff" avoided the merge spaghetti a lot of people compain about. Although, I have to admit our repository is small (6583 commits to date).

This works even when multiple devs work on the same branch: they must get in touch on a regular basis, rebase the branch they are working on and force push it. Rewritting history of topical branches is only bad if it is not agreed on. As long as it is done in a controlled manner nothing's wrong with it.

Another rule we follow is to always "git pull --rebase" (or git config branch.autosetuprebase=true).

Our approach might not, however, scale for larger teams or open source projects.

Re: GitFlow considered harmful

#210

Post by zastrowm »

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?

It allows builds off of that branch, so you can get test feedback etc. It also acts as sort of a backup or a sync if you switch machines.
Post reply on HN