I think this article, A Successful Git Branching Model, is very well known among experienced DVCS users.
hg mostly, but I would argue this discussion is fine for any DVCS.
Our current workflow is each developer clones the master repo. We write code on our own local repo, runs tests, and if all goes well pushes to the master.
So we want to setup CI servers like Jenkins and improve our workflow with the future provisioning system (chef, puppet, ansible, etc).
Well, the model presents above works nice but branches can break CI. The feature branch should sync with the origin (according to the article, it would be
development branch) to make CI and merging smooth, right?
Say Alice and Bob are working on two features. But Alice is done the next day. Bob's feature takes a week. By the time Bob is done, his changes are out of dated (maybe Alice refactored/rename some classes).
One solution is each morning developers must pull
master/origin to check if there's any changes. If Alice commited, Bob should pull and merge into his workspace so his feature branch is up-to-date.
- Is this a good way?
- Should these branches exist in the master repo (not local clone?) Meaning should every developer has commit privilege to the master repo on GitHub/Bitbucket so they can create a new branch? Or this is done locally?
- Lastly, the model presents by the article should break CI if branches are not sync with the
origin/master. Since we want to do nightly build, should developers pull and merge before they leave work, and have CI runs on each feature branch as well?