Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A simple git branching model

gist.github.com

Post reply on HN
Print view View original

61–70 of 158 posts

Re: A simple git branching model

#61

Post by untothebreach »

Daishiman wrote: post #59
tootie wrote: post #31

Earlier quoted context omitted.

If you rebase aren't you destroying that history of experimentation? I feel like this is destroying the whole idea of a VCS as a safety net and making developers self-conscious about something that supposed to tolerant of mistakes.

Why do you care about the history of dead-end experiments polluting the history of the specific final features being implemented and incorporated into the mainline?

Exactly this. I don't mind leaving the history of experiments in if they lead fairly logically and cleanly to the final product, but sometimes I will have 2 or 3 "WIP" commits in a row, that turn out to be completely irrelevant to the final product.

Re: A simple git branching model

#62

Post by valtron »

DougWebb wrote: post #46
barrkel wrote: post #7

If you work with other people, this model doesn't work so well, IME. In particular, rebasing is very hazard-prone if someone else may have checked out your branch. If you're working on a feature that needs changes in multiple components and is broken without coordination, you may be working off the same branch, or have separate branches with inter-merges. Either way, rebasing will cause trouble.

In particular, rebasing is very hazard-prone if someone else may have checked out your branch. That's why you never rebase a published branch. This is easier to manage if your team uses a central repository as the 'official' repository and everybody pushes and pulls to that one. Then you know that your branches in your local repository are not public, not published, and safe for history-altering workflows like rebase…

> That's why you never rebase a published branch.

My problem with that is my coworkers and I usually work on our own feature branch. Ideally I wouldn't push mine to the central repository until I'm done, so I can rebase on master without changing the public history, but at the end of the day I don't like to leave code only on my computer (what if my hard drive blows up??) so I push everything I don't want to lose.

Re: A simple git branching model

#63

Post by wpietri »

shawnps wrote: post #30

We used a very similar model to this at my last job, and I'm struggling to get my current team on board with this type of process. I think the main problem is that people don't trust continuously deploying master because there aren't enough tests. In my ideal world, every commit is tested (with Jenkins, Travis, Buildbot, etc), and then if the PR includes tests for the code and the build passes, the reviewer says LGTM…

My world really changed once I started working with code bases that had excellent test coverage from the get-go.

At my last shop we combined that with pair programming, feature switches, and a few other tricks, and we basically never branched. You'd pull, work for a few hours, push, and 10 minutes later your code would be live. It was in one sense freeing: the release overhead of other shops was gone. And in another, it inspired more discipline. Knowing that everything you were writing would shortly be live kept you on your toes. You could never leave something for later; there was no later. I loved it.

Re: A simple git branching model

#64

Post by jangel »

jamesrom wrote: post #6

I still don't understand why everyone has this misguided quest for a clean history. An accurate history is much more important. Rebasing destroys historical information. I can't really see any advantages of rebasing when a merge does the same thing but leaves two things rebasing does not: 1) a point to rollback to if things don't work out, and 2) an explicit entry of when your branch was brought up to date with maste…

Much in the same way visiting a museum is much more useful for understanding the past than visiting your grandma's attic, I think a curated history is much more useful than an accurate history. When someone says a clean history, I think they're saying a well-curated history.

You don't submit your first draft almost anywhere else, why do you think nailed it the first time writing your commits? Sometimes you don't get things right, and rebasing is one of the tools that helps you make sure that the written record of your work is helpful.

Re: A simple git branching model

#65

Post by barrkel »

crististm wrote: post #55
barrkel wrote: post #47

Earlier quoted context omitted.

I'm assuming a GitHub / Stash / similar workflow. Branches are not private; they are not kept just locally. (By private, I mean unpublished, in such a way that someone may have merged or branched off my branch.)

If people pull from a random github branch I think it is their problem. They should pull only from what you declare as public branches with stable history. I keep on github only the master branch and publish the feature branch only when it is ready. After the maintainer merges the feature branch, I delete it from github.

I am, of course, talking about private GitHub repos used within a single company, and not about random people pulling down branches, but rather team development.

Re: A simple git branching model

#66

Post by MatmaRex »

tootie wrote: post #58
crististm wrote: post #35

Earlier quoted context omitted.

As long as your final commits are logical you don't lose anything. You need clean commits on the history to be able to understand the code later on. During code review at a later time, the history of the experimentation is useless once you find several commits that touch the same code before settling on a final version.

> You need clean commits on the history to be able to understand the code later on. Really? That seems like an extraordinarily obtuse way to understand code. I would think comments directly the source files would be more useful. Commit history shows how they arrived at that result and that's what I would rather see there.

Commit messages I write are often several paragraphs long (and sometimes that's for a one-line change). Including all of the information in comments is not always viable.

Re: A simple git branching model

#68

Post by sanderjd »

Daishiman wrote: post #59
tootie wrote: post #31

Earlier quoted context omitted.

If you rebase aren't you destroying that history of experimentation? I feel like this is destroying the whole idea of a VCS as a safety net and making developers self-conscious about something that supposed to tolerant of mistakes.

Why do you care about the history of dead-end experiments polluting the history of the specific final features being implemented and incorporated into the mainline?

I see both sides of this, but on my own team, where we are all meant to be experts on the project, I really like to be able to see the experiments, because there's a reasonable chance I'll be trying something similar to or perhaps inspired by those throwaway experiments at some point. I think there is a different trade-off in open source projects, where it's more helpful to have a history that isn't confusing to newcomers.

Re: A simple git branching model

#69

Post by barrkel »

Pxtl wrote: post #60
gutnor wrote: post #13

Earlier quoted context omitted.

Noise vs Information on a shared project ? Imagine we are both working on a project. I don't care to know that you merged 3 times from master yesterday before pushing your feature. Also I don't care to know details like you forgot to put a config file in your first commit and had to do a second one, or that it took you 3 commits to have the spelling alright in the UI. Mainly that information is useful to you. It is a…

I'm incredibly new to Git, but actually destroying the history seems like a crude solution for a sophisticated tool like Git. Couldn't there be some way to just tag the "main" commits and mark the dead ends as "extraneous" rather than destroying them? And then have your history-viewing tool hide/squash the unmarked "invisible" commits by default and only expose them when specifically requested? I mean, it seems to ma…

It could combine all consecutive non-merge commits; or, if you're rigidly adhering to the "never directly commit" model for master, collapsing everything down to just the merge commits would be enough.

Re: A simple git branching model

#70

Post by barrkel »

crististm wrote: post #34
gutnor wrote: post #13

Earlier quoted context omitted.

Noise vs Information on a shared project ? Imagine we are both working on a project. I don't care to know that you merged 3 times from master yesterday before pushing your feature. Also I don't care to know details like you forgot to put a config file in your first commit and had to do a second one, or that it took you 3 commits to have the spelling alright in the UI. Mainly that information is useful to you. It is a…

I silence the noise before merging on a public branch by squashing the "thinking commits" on my private branch. What remains is a clean history of commits. You will not find the oscillating commits on the public branch but you will find them on my private (local) branch. So you do commit early and often, just that nobody else sees your commits until the feature is complete and working. And then only after you rearran…

Company policy: you can't keep branches just private, locally, because they're not backed up.

(That's just how it is at my company. PCs aren't backed up, central repos are.)

Post reply on HN