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

41–50 of 158 posts

Re: A simple git branching model

#41

Post by reledi »

viraptor wrote: post #22
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.

It works well if you keep changes small. Basically if you're making a change that integrates with some other place that someone else needs to update, that looks like two separate changes to me. Of course you can do big feature branches that change a lot of things at the same time, but you're right - that won't work here. Regarding big projects -> gerrit works pretty much the same way (but also forces you to squash ch…

> gerrit works pretty much the same way (but also forces you to squash changes into a single commit)

That may explain why one of the committers I work with on an open source project heavily suggests squashing changes into a single commit when merging topic branches into master. He works with gerrit at his day job!

Personally, I think it's better to only squash experimental commits or minor stuff like removing a newline, and to keep development of a feature spread out over several commits if it makes sense. Makes it easier to revert back to a specific commit.

Re: A simple git branching model

#42

Post by crististm »

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.

Your branches are private. Only public branches should be a considered for check-out.

Private branches can be rebased at will but the public branches are off limits. A public shared repository may help in this case.

Re: A simple git branching model

#43

Post by reledi »

tlo wrote: post #19

What if you pushed your feature branch and then need to fix something in that branch later? How do you handle this case as you shouldn't rebase a pushed branch?

It's fine to force push to a remote branch if it's a personal branch, that is, no one else is working on it but you.

(Or it's fine if you've previously discussed with your team the implications of force pushing to shared branches, and they're okay with that because you all know what you're doing.)

Re: A simple git branching model

#44

Post by crististm »

chmike wrote: post #32
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.

If you work on a feature branch originating from master, what you do is "git rebase -i master" to squash your commits.

Re: A simple git branching model

#45

Post by Ygg2 »

chmike wrote: post #32
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.

If you use rebase interactive like this:

   git rebase -i HEAD~n
Where n is number of commits from HEAD, you can do ANYTHING to your branch. You can stop mid rebase to add some files that didn't exist before, squash, fix, execute commands, etc.

You can even change order of commits and delete commits from history. BE VERY, VERY CAREFUL!

https://www.kernel.org/pub/software/scm/git/docs/git-rebase.... (See interactive mode and splitting commits).

Re: A simple git branching model

#46

Post by DougWebb »

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. It's only the branches that you push that you're not allowed to rebase, at least not prior to the last push.

If your team doesn't use a central repository, and you're pushing and pulling between all of your local repositories, then I'd suggest using a naming convention for branches to distinguish public ones from private ones. Eg: start your private branch names with "DEV_". If someone else pulls a DEV_* branch, then they should expect that its history might change and they'll have to deal with that when it occurs.

Re: A simple git branching model

#47

Post by barrkel »

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

Your branches are private. Only public branches should be a considered for check-out. Private branches can be rebased at will but the public branches are off limits. A public shared repository may help in this case.

I'm assuming a GitHub / Stash / similar workflow. Branches are not private; they are not kept just locally.

(By private, I mean unpublished, in such a way that someone may have merged or branched off my branch.)

Re: A simple git branching model

#48

Post by reledi »

Frostbeard wrote: post #39

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

> The feature branch's commit history is preserved in the repository (thought not in the master branch)

This would require you not to get rid of the branches (remotely and locally), right? GitHub does allow you to undo the deletion of a branch, but is that only for a certain time period?

I like to delete my branches as soon as they've been merged in.

Re: A simple git branching model

#49

Post by unfletch »

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

O yes, one more thing: before merging back to master I squash the crap out of it's existence. It was invaluable once I've found out how to do it. I've learned about squashing here (the specific page is dead now): http://www.denx.de/wiki/U-Boot/CustodianGitTrees

The dead link, archived: http://web.archive.org/web/20110822174840/http://www.andrewm...

Re: A simple git branching model

#50

Post by nsfyn55 »

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.

Post reply on HN