Awesome. Just this past weekend I've been working on something similar. It's never been more obvious that continuous integration was developed pre-git than today. Everything about our workflow is distributed, why is the thing that blocks our code from going to production so centralized? Heroku built a company out of using git post-receive hooks, I can only hope we will find other interesting ways of using git to solve integration issues. Maybe someday we will be overusing git, but I don't think we're even close to that yet.
I like the idea, except I'd prefer an option to rebase rather than merge when my code is out of date relative to upstream.
Merge is for when a major line of development departs. A minor feature written by a single developer is better as a rebase because it makes your history easier to understand.
Some people are purists who say "But that destroys history! It wasn't what actually happened!" Say that you implement Feature X. Six months later you want to implement Feature Y, and you say "I know that Feature X is similar enough to Feature Y, so I want to consult the patch for Feature X to see some working code that hooks into the interrupt vector table."
You don't want to see a sequence of six patches against different master commits, the first five of which don't even compile. You want to see a single clean patch. If you don't squash and rebase unclean patches, you're hobbling future maintenance that needs to look at that code.
You don't want to use Git to preserve what actually happened unless you're a historian. If you're a developer whose main goal is to get stuff done, you want to use Git in a way that makes the code as easy as possible for people unfamiliar with it to understand -- and months or years from now, your future self will probably be somewhat unfamiliar with the code you're writing today!
your last paragraph sums it all up the best it deserves more than just one +1. git is a tool to shape the codebase into a quality piece. i usually have about 8-12 private branches that needs others' commit before i can rebase and commit. in these branches i can test and play before anyone gets hurt.
3 comments
[ 3.2 ms ] story [ 21.9 ms ] threadMerge is for when a major line of development departs. A minor feature written by a single developer is better as a rebase because it makes your history easier to understand.
Some people are purists who say "But that destroys history! It wasn't what actually happened!" Say that you implement Feature X. Six months later you want to implement Feature Y, and you say "I know that Feature X is similar enough to Feature Y, so I want to consult the patch for Feature X to see some working code that hooks into the interrupt vector table."
You don't want to see a sequence of six patches against different master commits, the first five of which don't even compile. You want to see a single clean patch. If you don't squash and rebase unclean patches, you're hobbling future maintenance that needs to look at that code.
You don't want to use Git to preserve what actually happened unless you're a historian. If you're a developer whose main goal is to get stuff done, you want to use Git in a way that makes the code as easy as possible for people unfamiliar with it to understand -- and months or years from now, your future self will probably be somewhat unfamiliar with the code you're writing today!