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

71–80 of 158 posts

Re: A simple git branching model

#71

Post by sanderjd »

crististm wrote: post #35
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.

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.

I think this whole debate hinges on peoples' view of that sentence. Sometimes clean history helps comprehensibility and sometimes it obscures things. I think the amount to which each is true varies author to author, reader to reader, and project to project.

Re: A simple git branching model

#72

Post by coherentpony »

untothebreach wrote: post #11
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…

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…

>When I am working on a feature branch, I often find myself committing experiments,

That's exactly what `git branch` is for. For experimentation.

>that I possibly undo later in the branch.

That's exactly what `git branch -D` is for. Or even just `git checkout` and leave the branch there. That way if you ever change your mind you can revisit it.

Re: A simple git branching model

#73

Post by coherentpony »

Ygg2 wrote: post #8
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…

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

>Because clean history is easier to bisect.

While this is often true, `git rebase` changes your commits. Your history is now a lie. I've been in the situation where a `git rebase` ended up breaking commits. It's possible to merge broken history with `git rebase`. Only a `git merge --no-commit` will give you the opportunity to tweak the merge commit so that the resulting merge isn't broken.

Re: A simple git branching model

#74

Post by coherentpony »

calinet6 wrote: post #26

This is exactly how you do git. Sanity. Thank you.

Maybe it's just one point of view, rather than a clear-cut, 'this is how you do git.'

For example, my point of view is that master should never contain development work. master should always be stable. In this case, the post here does not jive with that point of view.

Re: A simple git branching model

#76

Post by sanderjd »

reconbot wrote: post #29
stevenashley wrote: post #17

Earlier quoted context omitted.

I'm not convinced on the bisect issue either. I've personally done a bisect spanning 10000 changesets with 50 concurrent branches at the widest point. Found the problem right away. We follow a similar branching model. Master is kept clean. We do all development on feature branches and merge when complete. History is fully preserved. History is a mess but it works well overall.

I would argue that you want to resolve conflicts in a rebase instead of a merge. This allows you to see where the branches diverge and fix it right away, closer to the offending commits, Preventing more work from piling up around the conflict making it harder to piece what's going on.

It can mean that you fix conflicts closer to the point where they first happened, or it can mean that you have to fix the conflict in a bunch of different ways as it propagates through each successive commit. I find myself trying to outsmart the conflicts: "Ok, I know I changed such-and-such in such-and-such a way here in a few commits, so if I fix this conflict like this, then hopefully I won't have to fix that commit later..."

Re: A simple git branching model

#77

Post by sanderjd »

a3n wrote: post #15
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…

Because no one cares about an individual's doodles and false starts on a feature branch, or an exploratory branch off a feature branch, they only care about the final difference between before and after merge. Explorations are an unnecessary distraction.

I disagree that categorically "no one cares": https://news.ycombinator.com/item?id=6457243

Re: A simple git branching model

#78

Post by jsaxton86 »

valtron wrote: post #62
DougWebb wrote: post #46

Earlier quoted context omitted.

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.

Git is designed so that branching is cheap. Why not create your own development branch off of the feature branch? Then use the feature branch as an integration-only branch?

Re: A simple git branching model

#79

Post by sanderjd »

jangel wrote: post #64
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…

Wow! I love this analogy! Allow me to disagree with you inside the premise of your own analogy. Visiting a museum is a much more useful way to understand past world history, but visiting your grandma's attic is a much more useful way to understand the little twists and quirks of your own family. In much the same way, I think a curated history is very nice for open source projects with lots of committers and constant newcomers, while a history that preserves foibles can be more useful for smaller and tighter teams. It is often very enlightening to see the missteps that were taken on the road to the eventual solution to a problem.

Re: A simple git branching model

#80

Post by nvarsj »

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…

It's pretty simple... readability triumphs. It's a hell of a lot easier examining the history of a project if a feature is condensed into a single or a few easy to read commits. Your personal struggle to implement a feature is far less important than having a clear, readable history. This becomes super important when bisecting, reverting, generating release notes, and a myriad of other things.
Post reply on HN