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

https://news.ycombinator.com/item?id=2210355

by robfitz • 15 years ago

2 1 15 years ago

news.ycombinator.com

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

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

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?

I should clarify that we don't 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?

Big thanks.

  [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

scorchin• 15 years ago

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/