Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In a nutshell:

  1. All developers push to the remote master
  2. Acceptance testing is done against the master
  3. Once accepted, the release is tagged
  4. The release is exported to production
     with `git archive` or `git checkout-index -a`
For larger teams you might need fine-grained control, but it works great for our small team.


Thanks for the input. I've been noticing a pattern of "don't use version control in production" which makes complete sense with the export. Do you guys have any kind of staging environment where things get final approval from a third party? I'm in a situation where we have a client approval process which requires another intermediary to production. It basically sits on the same production box but is used for testing prior to going live.

If it helps with anybodies responses, my situation is particular to web development.


staging would fit well within the work flow outlined above: you just branch out a staging branch, and export that. If the client needs any fixes, you fix it on the stating branch, and merge it back to master.

That way, further development on master won't disturb staging.

Once the client is happy, tag staging and export it to production.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: