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

101–110 of 158 posts

Re: A simple git branching model

#101

Post by denis1 »

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…

man, do I agree with you... I'm new to git, our whole company is... Every time I have to go through history, it is one big mess with a lot of intermediate stuff. It is a pain to work with.

Re: A simple git branching model

#102

Post by Daishiman »

sanderjd wrote: post #68
Daishiman wrote: post #59

Earlier quoted context omitted.

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

Then have them push the experimental branches and perform the rebase on a temporary branch, but it's still no excuse to have a clean feature history.

Re: A simple git branching model

#103

Post by wting »

rsanheim wrote: post #94

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

I think it depends on how public and how many contributors you have to a feature branch. I think author has the assumption that there is typically one dev per feature branch.

Once a feature branch is being worked on by multiple devs (and hence multiple feature branches forked off), it is a public branch and should use a merge based workflow.[0]

I personally use a rebase workflow on private branches before merging since it makes for a cleaner history. I've seen devs merge a branch with 100+ merge commits and it absolutely destroys git history.

[0]: http://lwn.net/Articles/328438/

Re: A simple git branching model

#104

Post by saraid216 »

Daishiman wrote: post #102
sanderjd wrote: post #68

Earlier quoted context omitted.

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

Then have them push the experimental branches and perform the rebase on a temporary branch, but it's still no excuse to have a clean feature history.

I used to do this, but I've started using

  git checkout master
  git diff master..featurebranch | git apply
instead.

Re: A simple git branching model

#105

Post by amboar »

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.

Given one of your other comments here, I get the impression you don't use code review tools much, eg Gerrit. Is that the case?

Re: A simple git branching model

#106

Post by crististm »

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.

I do that all the time with code that I don't understand. The commit message is the last resort of getting a human to talk to you when the comments are missing.

Re: A simple git branching model

#107

Post by tootie »

amboar wrote: post #105
tootie wrote: post #100

Earlier quoted context omitted.

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.

Given one of your other comments here, I get the impression you don't use code review tools much, eg Gerrit. Is that the case?

Not on most projects, no. We are on my current project and the review tool is based on tasks, not commits and can review multiple commits in a single session if they are all related to the same task. Regardless, I am only ever reviewing the end state.

Re: A simple git branching model

#108

Post by barrkel »

jlgreco wrote: post #93
barrkel wrote: post #70

Earlier quoted context omitted.

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.

Unfinished work is committed somewhat often, especially if it's complex. Commits are sometimes squashed once a pull request is approved (PRs being the code review gateway), more often if there are a lot of uninteresting commits.

Some people use git add -i to be very selective about what they commit, and deliberately increase the number of independent commits, rather than have a single commit that has unrelated changes in it.

Other people have a lot of WIP commits.

We started out doing more rebasing, but do a lot less now, after having run into issues with having e.g. branched off of a branch that has since been rebased and merged (e.g. front end / back end feature split). You try to rebase, but the replay of commits continuously hits merge conflicts, and you spend about 30 minutes repeatedly fixing the same conflicts. And then there's the risk of your force push accidentally chopping off someone else's commit (though that's never happened).

We had one PITA case where a profanity was checked into the codebase, and branches with the offending commit in the history lurked in various places surprisingly long after the commit had been excised from the main trunk lines. Since we're a startup in the financial sector, our code will be in escrow situations, potentially examined by humorless auditors, we don't want profanities in.

Re: A simple git branching model

#109

Post by jlgreco »

coherentpony wrote: post #73
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.…

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

Time is relative and history is only what has been observed. You only rebase code that has not been seen by others, so the code that was rebased was never history at all, as far as anybody else is concerned.

I don't think anybody ever recommends rebasing public code. There is a reason for that --force flag on git-push advises the user to use with care.

I mean, I could configure my development setup to automatically commit my persistent undo files so that every single keystroke I make is preserved for prosperity... but I don't do that of course. I could also configure my setup so that every time I write out a file it commits, preserving that history forever... but I don't of course. Why should a bunch of temporary local commits be preserved forever?

Using the terminology "rewriting history" to describe rebasing local commits is misleading. "deciding what history will be" is more accurate.

Re: A simple git branching model

#110

Post by dvirsky »

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.

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.
Post reply on HN