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

31–40 of 158 posts

Re: A simple git branching model

#31

Post by tootie »

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…

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.

Re: A simple git branching model

#32

Post by chmike »

praptak wrote: post #5

I would also add "commit often, squash later". I find frequent local commits useful for quickly rolling back mistakes but they'd just clutter the main history if they got there. Usually if a commit is important enough to end up in master, it is also important enough to do the merge so most of my changes are actually 1 commit (2 if you count the --no-ff merge.)

Learning git here. Could you please explain how rebase squashes commit ? Looking at man git-rebase it seam that it detaches a branch and attaches it to the current branch. From the documentation the chain of commits is preserved and simply moved in the graph. The sequence of commit nodes of the branch are not merged into one commit node.

Re: A simple git branching model

#33

Post by tootie »

crististm wrote: post #25
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…

Rebasing on a public branch is a big no-no. But rebasing on your private branch helps you catch merge problems early on. Except for the "merge --no-ff" I'm using exactly this model and I think it is great. It can't get any more simple than that and still have a working master. Regarding the "straight line, clean" history, I've found that most people think that a straight line is "the" history to have. I have no idea…

If it's a feature branch, doesn't that strongly imply that more than one developer might need to commit to it?

Re: A simple git branching model

#34

Post by crististm »

gutnor wrote: post #13
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…

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 rearranged and squashed your commits. From the outside it looks like you always commit top quality code from the first try.

$ git rebase -i

Re: A simple git branching model

#35

Post by crististm »

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.

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.

Re: A simple git branching model

#36

Post by a1k0n »

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.

You can always keep the un-rebased branch around if you want to preserve the history somewhere, and then squash the commits down to a smaller number on top of master. That solves the safety net problem, and master keeps its sanitized history.

This is what I do and it's kind of required when you're using e.g. gerrit code reviews.

Re: A simple git branching model

#37

Post by reledi »

tootie wrote: post #33
crististm wrote: post #25

Earlier quoted context omitted.

Rebasing on a public branch is a big no-no. But rebasing on your private branch helps you catch merge problems early on. Except for the "merge --no-ff" I'm using exactly this model and I think it is great. It can't get any more simple than that and still have a working master. Regarding the "straight line, clean" history, I've found that most people think that a straight line is "the" history to have. I have no idea…

If it's a feature branch, doesn't that strongly imply that more than one developer might need to commit to it?

> rebasing on your private branch

Which I assume means it's only you working on it. Not all topic branches have multiple committers.

Re: A simple git branching model

#38

Post by crististm »

tootie wrote: post #33
crististm wrote: post #25

Earlier quoted context omitted.

Rebasing on a public branch is a big no-no. But rebasing on your private branch helps you catch merge problems early on. Except for the "merge --no-ff" I'm using exactly this model and I think it is great. It can't get any more simple than that and still have a working master. Regarding the "straight line, clean" history, I've found that most people think that a straight line is "the" history to have. I have no idea…

If it's a feature branch, doesn't that strongly imply that more than one developer might need to commit to it?

I don't think a feature branch implies collaboration.

Even if more than one developer is involved, the model doesn't change: "master and feature" branches become "feature and developer-private-feature". The developer still relies on a (partial) working feature branch, and his contribution still has to be self-contained.

But since you have more developers you will have an out of band sync communication between them.

Re: A simple git branching model

#39

Post by Frostbeard »

In my team we do something superficially similar, but instead of rebasing we just merge changes from master into our feature branches whenever master is updated. This seems to result in fewer conflicts for us, despite what you might expect.

Also, when the feature branch is to be merged into master we do a squashed commit so that all changes from that branch show up as one commit in the main project history. The feature branch's commit history is preserved in the repository (thought not in the master branch), so it's not really any more difficult to roll back partial changes.

Our situation is likely different from many projects though, as we only ever have one developer working in a given feature branch.

Re: A simple git branching model

#40

Post by Ygg2 »

barrkel wrote: post #10
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.…

This is an artificial problem. Git has almost all the data needed to present a squashed view - all it's missing is an idea of what commit a branch pointed to throughout history, so that it can merge together commits in in the "bubbles" for presentational purposes. It would be better to fix this, so you get nice diffs, blame etc., than deal with all the other issues rebase causes. I'm not convinced on the bisect issue…

Again rebase is there to cleanup your work, to simplify your workflow so someone not necessarily something looking the code can make sense of it.

git bisect might work ok (I haven't used it extensively) but the more important is if you made a mistake and call someone to help, to ease that person's work by presenting a trimmed though more understandable tree. You should strive to keep the branching as simple as possible, but not simpler than that (to paraphrase an infinitely more smarter man).

Post reply on HN