

Ask HN: practical git process for teams with frequent deploy? - robfitz

We've been creating branches for each feature and building it into a release-x.x branch every day to deploy, basically following the guide at [1].<p>We've got 2 new developers who haven't used git before, and I'm burning lots of time (and making lots of exceptions) trying to get them on this process. At the same time, I've heard that one of the mantras of continuous deployment is that you always work on the trunk and keep it stable[2,3].<p>Can anyone describe in a bit more detail why this is desirable and how it works, on a practical level? Do you still have developers creating individual feature branches for organization, or is it literally a single branch operation?<p>I should clarify that we <i>don't</i> have a full deploy system in place, and the releases, while daily, are still pushed manually. Does working off the trunk only make sense once every commit is being auto tested?<p>Big thanks.<p><pre><code>  [1]: http://nvie.com/posts/a-successful-git-branching-model/
  [2]: http://aptoma.com/select.star/2010/01/21/notes-on-continuous-deployment/ paragraph 2
  [3]: Ash Maurya's recent ebook</code></pre>
======
scorchin
On the whole you're on the right track, but I'd like to explain a little
further about what you're doing and the possible long-term implications.

Feature Branches can become corrosive. Any changes made on the mainline will
have to be merged with every feature branch. This is fine with small teams (<
3) but can become frustrating when you have a lot of feature branches or high
velocity on your trunk/master. Long-lived branches and refactorings must be
merged regularly to prevent merge conflict hell! A lot of this comes down to
having disciplined developers.

Why develop on mainline? A lot of this comes from the non-dvcs days. It was
expensive to make a branch/tag and they tended to be made when making a
release. The beauty of keeping mainline up-to-date (commits once per day) is
that you have a regular tracking point to revert changes back from on
production. Instead of trying to remember which feature branch was deployed,
you have a consistent (linear) timeline.

As you've said this becomes beneficial when you automatically test and deploy
your code. A lot of this is to enable best practices for when you decide to
setup a CI server like Jenkins to run your unit/integration tests and then
deploy automatically (maybe) on a clean run.

Regarding git, I'm going to assume that you've taught your devs enough to
follow good habits to keep them sane. Many find that learning git takes a
fortnight or so to fully understand. Still, it's always worth throwing a bunch
of resources their way. In no particular order:

<http://progit.org/book/> <http://www.gitready.com/> <http://book.git-
scm.com/>

For more on this kind of stuff and no doubt a better explanation, check out
Continuous Delivery by Jez Humble and Dave Farley. Link:
<http://continuousdelivery.com/>

