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

91–100 of 158 posts

Re: A simple git branching model

#91

Post by jlgreco »

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…

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

You could do exactly that; look into git-update-ref for how you could implement that so that garbage collection doesn't wipe out those dead ends (git-notes basically does what you would need to do).

Note that you would still be rewriting history, still rearranging the DAG, but you would have references to the old states. Basically like a permanent reflog, though perhaps with an interface tailored to this usage.

Re: A simple git branching model

#92

Post by crististm »

barrkel wrote: post #70
crististm wrote: post #34

Earlier quoted context omitted.

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

Besides the official repository, we have per-user backed-up repositories for this reason. People develop on their machines and publish/save on the git server finished/unfinished work. You can rebase at will and push --force as much as you want.

Rebases on the official repo are not allowed and the per-user repos are public and can be used also for collaboration.

Re: A simple git branching model

#93

Post by jlgreco »

barrkel wrote: post #70
crististm wrote: post #34

Earlier quoted context omitted.

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

Do they also force you to commit unfinished work frequently? Because in my experience devs would get around that "all branches are public" rule by just not putting things into a commit until they were confident something was complete. The end result is the same, except that devs don't get to enjoy using version control to its full extent.

Re: A simple git branching model

#94

Post by rsanheim »

Interestingly enough, most folks working on GitHub.com don't use this model. We actually use a simpler model, and usually merge to our feature branches rather than rebase. I'm not sure if Zach's latest talk(s) goes into this level of detail.

I think a big part of the reasoning is because we tend to push up branches really early to open PR's and get discussion going. And of course rebasing public branches generally leads to hell.

I know some other .com devs will rebase privately before pushing a large branch, but I would say 80% of work is just done with merging.

Re: A simple git branching model

#95

Post by jlgreco »

jamesrom wrote: post #14
Ygg2 wrote: post #8

Earlier quoted context omitted.

Because clean history is easier to bisect. It's easier to visually track problems, (aha so you changed thing A in branch br12 and thing B in branch br13 as opposed to wait so person A branched into br12, then person C branched into br23, then it got merged with br74, which was merged with person D on branch br84..). Less entagled workflow is easier to untangle and consequently understand even if it hides some stuff.…

I could just as easily say, if you are constantly using bisect on your master branch, then your project is probably a train wreck.

There is no reason not to enjoy the benefits of modern version control just because some code you inherited is utter shit.

On the other hand, being familiar with modern version control is a good idea, if only just in case you inherit code that will be shit.

On the other other hand, regressions occur and go unnoticed even on the best of projects.

Re: A simple git branching model

#96

Post by recursive »

nsfyn55 wrote: post #50
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…

I don't understand why people think rebasing destroys history. It doesn't "destroy" anything. Have you ever had an argument that was just mediocre? But later you think of a witty retort that would have been just perfect. Thats what rebasing is. Its re-structuring the conversation the way you would have liked it to go.

Re-structuring a conversation destroys the old bad conversation.

Re: A simple git branching model

#97

Post by e40 »

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…

I don't understand why people don't realize there is a place for rebasing and a time for merging.

untothebreach explains it well [1]. When you are working on changes which are not public yet, sometimes it's helpful to rebase them into a single or fewer number of commits. Period.

No one is arguing to always use rebase and never use merge.

[1] https://news.ycombinator.com/item?id=6456434

Re: A simple git branching model

#98

Post by e40 »

tootie wrote: post #31
untothebreach wrote: post #11

Earlier quoted context omitted.

When I am working on a feature branch, I often find myself committing experiments, that I possibly undo later in the branch. I don't always focus on making "incremental, atomic" commits, because I am usually focused on the code. When the feature is done (but before I merge it into master), I will usually go through and clean up my meanderings, and turn them into "incremental, atomic" commits, so that my teammates don…

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.

I like lambda's answer, to which I'll add:

You have NEVER finished work on a feature and you look at the history and there are 10's of commits with crappy commit messages and extremely minor changes? If so, good for you. Not so for me. I don't always squash ALL commits on my feature branch, but I often remove a good number, so the history looks helpful for my future self.

Re: A simple git branching model

#100

Post by tootie »

crististm wrote: post #88
tootie wrote: post #58

Earlier quoted context omitted.

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

What do you think is easier for the next guy? 1) three commits that do: - a = 1; - a = 7; - a = 3; or 2) one commit that says: a = 3; My point is that experimentation is slightly different from changing your mind about the whole implementation. It is the same as writing your homework. You have a separate piece of paper where you make your experiments.

When does the "next guy" ever look at revision history to see what's going on? I only ever look at the current state. If I want to see how it diverged from my last commit or the last commit before whatever milestone or release, I will diff the current version against that version ignoring every commit in between.
Post reply on HN