This feels like the working with SVN/P4 again.
Main difference here is having your work in progress visible to others in a feature branch. Also rebase -i being less of a pain than svn update.
A simple git branching model
21–30 of 158 posts
Re: A simple git branching model
#22If 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 changes into a single commit). This is used successfully by cyanogen and openstack people at least. Those are fairly big teams.
Re: A simple git branching model
#23If 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.
Re: A simple git branching model
#24I never use rebase, but I don't see problems if your branch is local.
I would prevent rebasing after pushing the branch to remote.
Anyway this branching model doesn't looks so that simple.
Re: A simple git branching model
#25I 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 what to tell them.
Re: A simple git branching model
#26This is exactly how you do git. Sanity. Thank you.
Re: A simple git branching model
#27I 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…
Public history and private history. Or maybe changes to production vs changes as you developed.
I care more about the merge then the commits. (In github parlance, the Pull Request) This workflow turns commits throughout time into a single change against the master (while still preserving the commit history). Conceptually this is a lot easier for me to see what's changing, and to deal with issues. So I guess I disagree with point #1)
In a continues delivery environment this workflow makes sense because the log accurately shows the history of the changes to the app in production instead of the development environments. (Merge, Merge, Merge)
#2 doesn't make sense to me, if you rebase you're up to date with master as of the branching commit.
Whatever works best for your team!
Re: A simple git branching model
#28I 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…
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
Re: A simple git branching model
#29Earlier quoted context omitted.
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…
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.
Re: A simple git branching model
#30We used a very similar model to this at my last job, and I'm struggling to get my current team on board with this type of process. I think the main problem is that people don't trust continuously deploying master because there aren't enough tests. In my ideal world, every commit is tested (with Jenkins, Travis, Buildbot, etc), and then if the PR includes tests for the code and the build passes, the reviewer says LGTM and the committer presses the merge button on GitHub. Once the button is pushed, a build of master is triggered. If the build passes, the code is automatically deployed.