A simple git branching model • Hacker News Board

Re: A simple git branching model

#141

Post by cshesse » Sat, Sep 28, 2013, 10:20 AM UTC

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…

I would take that one step further and never rebase any branch ever.

Re: A simple git branching model

#142

Post by timmow » Sat, Sep 28, 2013, 11:10 AM UTC

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…

If you want a completely accurate history I hope you have your editor set to commit after every character you type, in case you need to delete a typo.

Ok, thats slightly tongue in cheek, but I think its a subtle balance between clean and accurate history, some people are happy to use rebase to, some are not. In my view, rebasing is no different to using undo in your editor, but I appreciate some people feel differently.

Re: A simple git branching model

#143

Post by _prometheus » Sat, Sep 28, 2013, 11:25 AM UTC

lambda wrote: post #83

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.

Cleaning up your history before merging is important. For one, before you merge you should usually have someone do code review. No one wants to do a code review on a branch that has a bunch of false starts, typo fixups, debug print statements being added and removed, and so on. Code reviewing a branch that breaks something and then fixes it three commits later is a real pain; you sit there puzzling over the first com…

Precisely! This is a great explanation. I'll link to it in the future. :)

Re: A simple git branching model

#144

Post by _prometheus » Sat, Sep 28, 2013, 11:30 AM UTC

dreamdu5t wrote: post #128

sofal wrote: post #123

Earlier quoted context omitted.

No, you should never be afraid of committing anything you have at any point in time. Git works as a development tool as well as a central VCS. As long as you have committed something, it will be restorable in case you overwrite it or delete it. Telling someone to wait before committing is a bad idea. They may get a lot of work done and then inadvertently lose it somehow, permanently. Instead, you should commit often…

There's no need to squash commits with rebase. Ever. Whether you commit often or not does not change the fact that rebase is unnecessary to keep a clean history of features/releases and obscures real commit history. You can have a clean history of features and/or releases with tags, without destroying commit history.

> There's no need to squash commits with rebase.

Squashing is not the purpose of rebase. Rebase allows you to clean up history. Sometimes, that means _separating_ large commits into smaller, atomic ones. Sometimes that means re-ordering things to make more sense for the reader. And yes, sometimes, an atomic unit requires squashing two or more commits together.

Commits should be logical units of the codebase, not units of developer productivity over time.

Re: A simple git branching model

#145

Post by _prometheus » Sat, Sep 28, 2013, 11:33 AM UTC

lambda wrote: post #137

dreamdu5t wrote: post #133

Earlier quoted context omitted.

> Explain to me how tags get me to an understandable view of my DAG so that I can see clearly what has been happening to the code, by whom, and why. That's what the commit history is for. If you don't like seeing merges use git log --no-merges. You can use rebase to avoid seeing merge commits, but it's awfully unnecessary with the nasty side-effect of destroying history. I was suggesting tags as way to keep an altern…

The history of tags happens at the release level. That is not granular enough. The history of every last little typo fix is too granular; it's just worthless to preserve. Using tags for every merge isn't all that useful; you already have the merge commits for it. What you want is a logical sequence of correct changes (or, as correct as anyone could tell at the time; of course no one's perfect). If you you have to do…

> What you want is a logical sequence of correct changes

Precisely! :)

> make sure your commit message are actually good enough that someone doing a code review can actually follow what you're doing

Yes, this is a very important point for rebasing.

Re: A simple git branching model

#146

Post by _prometheus » Sat, Sep 28, 2013, 11:38 AM UTC

sanderjd wrote: post #71

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

> I think this whole debate hinges on peoples' view of that sentence.

Prescient observation. How does clean history obscure things though? You mean as failed experiments get removed? Important things ought to be mentioned in commit messages. Relevant things to document can be showcased like "Tried X but it turns out Y is better because Z." I often find that code alone is not enough to describe why something did or didn't work. One ends up having to explain in commit messages anyway.

Re: A simple git branching model

#147

Post by _prometheus » Sat, Sep 28, 2013, 11:50 AM UTC

tootie wrote: post #100

crististm wrote: post #88

Earlier quoted context omitted.

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.

> When does the "next guy" ever look at revision history to see what's going on?

_All the time_. I read all the commits in the codebase I'm responsible for. I need to keep track of what people are doing and how the system is changing. This is also on top of the need for code review and ensuring each patch is correct.

Check out http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Con...

Re: A simple git branching model

#148

Post by _prometheus » Sat, Sep 28, 2013, 11:57 AM UTC

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…

I like jlgreco's answer to your this post.

Just wanted to point out that rebasing is not just to remove or squash commits. I use it to: - _separate_ large commits into atomic, logical units - fixup changes missed the first time around - rewrite commit messages to ensure they're clear - reorder commits

Re: A simple git branching model

#149

Post by _prometheus » Sat, Sep 28, 2013, 12:05 PM UTC

reconbot wrote: post #23

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.

My team of 6 handles this just fine, we try not to have many people on the same branch, nor do we like to have branches that live very long. Merges of branches that are old tend to cause more problems. Problems that would have fallen out on the developer side if they had rebased.

> nor do we like to have branches that live very long. Merges of branches that are old tend to cause more problems. Problems that would have fallen out on the developer side if they had rebased.

This is a great point. Keeping branches small avoids serious integration problems.

Re: A simple git branching model

#150

Post by _prometheus » Sat, Sep 28, 2013, 12:10 PM UTC

dvirsky wrote: post #110

reconbot wrote: post #23

Earlier quoted context omitted.

My team of 6 handles this just fine, we try not to have many people on the same branch, nor do we like to have branches that live very long. Merges of branches that are old tend to cause more problems. Problems that would have fallen out on the developer side if they had rebased.

I'm using this model in a team of 12, it works fine, except for: 1. needing to have reliable testing environments for QA/product people to try features, as many feature branches are worked on at once; and 2. new people having trouble with rebasing, or have to understand git just a little bit better than pull/push/commit.

> 1. needing to have reliable testing environments for QA/product people to try features, as many feature branches are worked on at once

Makes sense. Also, try using continuous integration (which should test every commit), and try teaching people to check out particular commits (by hash). I find that once people understand what "headless" means, and how to get out of it, `git checkout ` is a very useful way to test _specific_ things.

> 2. new people having trouble with rebasing, or have to understand git just a little bit better than pull/push/commit.

I think the lesson here is that spending a bit of extra time teaching your developers (not to panic,) how git works, and how more obscure commands work, goes a long way.