The inclusion of both PHP code and content in the pages has me a bit confused about the intended content management workflow in October.

Let's assume that I build an October site for my client on my local dev server: 1) My "pages" files include both PHP code and content. 2) I check all of my files into git and deploy to production. 3) My client logs into the October CMS on my production server and changes some of the content in the pages. 4) Now I want to change some of the PHP code in the same pages, but I have a race condition... 5) If I update the PHP code locally, check-in to git and deploy, I will overwrite my client's content changes.

This is what confuses me about intermixing php code and content. What is the recommended workflow to keep from stomping over my client's changes in this case?

Should I not allow my client to change any content in the "pages" files? Or, should I make sure all of the user-editable content is stored in the DB via custom models?

Thanks!

You can store any "contents" for pages within the CMS > Contents section (or use the Rainlab.Pages plugin), that way they will be separate from the pages themselves, and the pages can be used mainly for structuring your site - so if you we're to update your "pages" files locally and deploy via Git, the contents would remain untouched in the "contents" folder.

Putting PHP code inside the Pages in not the best practice, you should ideally be using Components for this purpose. PHP within pages is for "adhoc" coding, things like setting active menus and simple logic. Most professional websites do not use the PHP code section at all.

Regarding the client updating content on the server, this can be managed by git. If git is installed on the server, the theme can be cloned, and changes can be committed and pushed from the server to the git repo.