This is typ­i­cal­ly how a project should flow in terms of how we devel­op and deploy the web­sites we work on. The web­site itself exists in a git repo some­where, whether you use GitHub​.com pri­vate repos, Beanstalk​a​pp​.com, Bit​Buck​et​.org, Git​Lab​.com, or your own pri­vate Git serv­er for your git repos, it does­n’t real­ly mat­ter. Just start using them.

This git repo serves both as a method to store your work in a col­lab­o­ra­tive, ver­sioned man­ner, and also as a flow con­trol device. All of the code you work on flows in and out of git.

Note that this is a one-way street: we devel­op and test in local dev, then we push our changes to the git repo, and then we pull them down to live pro­duc­tion and/​or staging . While we may pull changes from oth­er devel­op­ers into our local dev envi­ron­ment, changes are nev­er com­ing from live pro­duc­tion or staging .

Updates to Craft CMS itself, as well as any plu­g­ins you use should always be done only in local dev, and then pushed to git after they’ve been test­ed. You can ensure this hap­pens by set­ting 'allowAutoUpdates' => false in your craft/config/general.php file, so there’s no Update but­ton for peo­ple to push. For more infor­ma­tion, check out the Mul­ti-Envi­ron­ment Con­fig for Craft CMS article.