Antes de tudo, você precisa reconhecer que há dois fluxos de trabalho aqui: o seu e o do seu cliente.
Seu fluxo de trabalho
- Receber PSD
- Codifique HTML / CSS
- Modelo WordPress de código
- Implantar tema para viver no site do WordPress
O fluxo de trabalho deles
- Conceber as alterações necessárias e enviá-las por e-mail
- Escrever postagens
- Fazer upload de fotos
O problema
Implementar o controle de versão aqui não tem absolutamente nada a ver com o fluxo de trabalho de seus clientes. É tudo sobre como acompanhar o código que você usa para o tema WordPress. Todos os seus arquivos de tema, plugins personalizados, etc devem estar em um sistema de controle de versão (Git, Mercurial, Subversion, ou o que você escolher usar).
Seu fluxo de trabalho se torna:
- Escreva o código
- Confirmar alterações no sistema de controle de versão
- Enviar alterações para o site de produção
- Receber comentários do cliente
- Escreva o código
- Confirmar alterações
- Escreva o código
- Confirmar alterações
- Enviar alterações para o site de produção
Lembre-se de manter um histórico de controle de versão para o seu código . O código é algo que seus clientes não devem mudar - e você nunca deve alterar o código em um site de produção enquanto estiver em produção.
Mas as alterações no conteúdo (postagens, fotos, etc) estão fora do escopo do seu sistema de controle de versão. Em outras palavras, você não faz alterações no desenvolvimento e, em seguida, envia o banco de dados para produção. Essa é uma prática de desenvolvimento ruim. Se você precisa que os bancos de dados dev e prod estejam em sincronia, então você deve puxar rotineiramente um backup da caixa de produção e restaurar sua versão local a partir desse backup.
Alterações no código fluem do desenvolvimento para a produção.
Alterações no banco de dados fluem da produção para o desenvolvimento.