Introdução ao Subversion, Git ou sistema de controle de versão similar para manter um histórico dos meus arquivos? [fechadas]

Sei que essa pode ser uma pergunta ampla à superfície, mas estou procurando exemplos específicos de configurações / fluxos de trabalho que as pessoas usam para manter um histórico de versão dos arquivos editados em um site WordPress. Por exemplo, ao desenvolver um site (e mesmo após a exibição), geralmente faço alterações nos arquivos CSS e PHP, mas não tenho uma ótima maneira de reverter para versões mais antigas desses arquivos. Para meus propósitos, fazer alterações em uma instalação de desenvolvimento local e copiá-las para o site ao vivo geralmente é mais problemático do que eu gostaria. Alguma sugestão sobre como começar a usar uma ferramenta de controle de versão para rastrear edições em arquivos em um site ativo?

Não sei o quanto você sabe sobre o uso do controle de versão, mas recentemente mudei do SVN para o Git e achei ótimo!

Embora dependa de você, o servidor do site ao vivo possui o Git instalado (ou permitirá). Também tenho uma configuração do Git no servidor ativo, executando uma ramificação chamada algo como production. Sempre que eu termino de implementar / corrigir algo localmente, mesclo-o na productionramificação, depois SSH no servidor do site ativo e retiro as alterações. É melhor do que arrastar arquivos pelo FTP quando você nunca sabe se está substituindo alterações, etc.

Eu recomendaria dedicar algum tempo para familiarizar-me com o Git (se você ainda não o fez), acho muito mais fácil e menos problemático do que o SVN quando se trata de alterar / adicionar muitos arquivos (e, ao contrário do SVN, não é idiota). .svnpastas em todos os lugares ).

Estou em um Mac, desculpe se nada disso se aplica, mas uso o Coda como editor de código e instalei o Git por meio de portas (usando o Porticus).

Se eu tivesse que configurar tudo de novo, faria:

1. Instalar Coda

2. Instale o Porticus (que exigirá a instalação de portas, mas há informações nessa página)

3. Depois de instalar o Porticus, abra-o, pesquise "git-core" e instale-o.

4. Baixe e instale o GitX 7-5

5. Há um bom guia sobre como configurar um repositório Git aqui , mas é básico: 1. Abra o Terminal. 2. cdpara onde você deseja que seu site esteja. $: mkdir mysite && cd mysite3. $: git inite é isso! Se você adicionar arquivos a esta pasta, continue com a próxima etapa

6. Depois de configurar um repositório GIT localmente (artigo acima), se você abrir esse diretório no GitX, poderá confirmar coisas, etc.

Configurar tudo no servidor pode ser um pouco complicado, eu tenho uma conta MediaTemple e uma Dreamhost que possuem GIT fora da caixa. O link na etapa 5 mostra como adicionar um repositório remoto, para que você não precise fazer isso até que você queira colocar seu site ativo na equação. Eu recomendo que tudo funcione localmente primeiro (diferente do SVN, o GIT não requer um repositório remoto, para que você possa fazer tudo em sua máquina por enquanto).

Eu uso o SVN para controle de versão com tudo o que faço no desenvolvimento do WordPress. Na verdade, comecei dessa maneira porque precisava do SVN para o desenvolvimento de plug-ins ... assim que comecei lá, era uma extensão natural continuar usando o SVN para temas e scripts personalizados nos sites dos clientes.

Plug-ins

Como os plug-ins já estão hospedados no servidor do WordPress, basta verificar um plug-in diretamente no /wp-content/plugins/diretório da minha instalação local do WordPress (eu executo o WAMP na minha caixa de desenvolvimento). Depois, faço alterações na minha cópia local e, quando estiver pronta para o horário do show, comprometo-me com o repositório. É um processo tranquilo, sem upload / download e verificação instantânea de que minhas alterações funcionaram.

Temas

Os temas são um pouco diferentes, principalmente ao criar para um cliente. Crio um repositório local (tenho uma Rpartição no meu disco rígido especificamente para essa finalidade) e faço check-out do repositório vazio diretamente no meu /wp-content/themesdiretório. Depois, faço as alterações necessárias e desenvolvo até que esteja pronto, enviando revisões à medida que avanço.

Quando estou pronto para publicar o tema no servidor de produção de um cliente, exporto o repositório, zipo-o e uso a funcionalidade nativa Temas >> Adicionar nova no WordPress. Isso funciona com plug-ins personalizados (que não são hospedados pelo WordPress) também.

Ferramentas

Como eu disse, eu uso o WAMP na minha máquina local para executar uma instalação de desenvolvimento do WordPress. Ele funciona perfeitamente na minha caixa e me permite executar quantas instâncias do WordPress forem necessárias para um projeto específico.

Para o SVN, eu uso o Tortoise SVN . É gratuito, notavelmente fácil de usar e integra-se à estrutura de arquivos e comandos do Windows. Atualizar, confirmar e exportar são simples, clique com o botão direito do mouse, selecione operações de comando. O uso de "Exportar" permite enviar a pasta inteira (sem as .svnpastas irritantes ) diretamente para qualquer local de sua escolha - eu freqüentemente exporto para a área de trabalho. Fechar a pasta também é uma operação de clique com o botão direito do mouse, e o WordPress lida com o upload.

A transferência manual de arquivos pode ser um aborrecimento, principalmente se você continuar alterando um arquivo, mas não todos. Se você colocar o FTP em todo o diretório inteiro com "substituir tudo" selecionado, será muito mais fácil substituir arquivos antigos (e você não precisará controlar quais alterações foram alteradas ou não). É como a antiga instalação de 5 minutos que o WordPress costumava ter - basta substituir tudo pela nova versão.

Pessoalmente, acho que é um exercício divertido instalar o SVN / GIT e gerenciá-lo, mas se você pode trocar US $ 15 por mês, o Beanstalk vale cada centavo. Eles gerenciam todo o servidor para você. http://beanstalkapp.com/ As ferramentas de implantação de FTP são impressionantes. O Mine implanta automaticamente a versão no meu servidor intermediário quando eu confirmo, por exemplo

Outra maneira de obter algumas versões de arquivos pessoais é usar a caixa suspensa. Toda vez que você salva um arquivo na sua caixa de depósito, ele rastreia a versão e você pode restaurar para qualquer versão anterior posteriormente. Você e outro desenvolvedor ou grupo podem compartilhar uma pasta da caixa de depósito. Isso garante que não troncos, mesclagens etc., mas facilita muito o trabalho de uma equipe distribuída em um site. Você simplesmente não pode trabalhar exatamente nos mesmos arquivos de uma só vez.

Mantemos nossa cópia de trabalho do SVN na caixa de depósito e, em seguida, confirmo os arquivos quando a hora é escrita. Meus designers não confirmarão arquivos ou lidarão com o SVN, então esse é o compromisso.

Prefiro o SVN porque não preciso de todo o entroncamento para o qual o GIT é tão bom e existem melhores ferramentas GUI disponíveis do SVN.

Eu gosto muito do Aptana , ele tem um subversion integrado e você pode conectar-se ao seu servidor com ftp / sftp facilmente e enviar arquivos, outro ótimo recurso que ele tem é que, se você criar um novo projeto php e incluir o WordPress "inteiro" Na pasta (com wp-admin, wp-includes), você obtém a conclusão do código nos arquivos de tema.

Na minha configuração, o repositório é local.

Você pede "mas estou procurando exemplos específicos de configurações / fluxos de trabalho que as pessoas usam para manter um histórico de versão dos arquivos editados em um site WordPress", mas também menciona produtos :)

Você se destaca como resposta a uma lista de ferramentas e algumas práticas recomendadas, mas vou me concentrar aqui nos fluxos de trabalho: NÃO SÃO ESPECÍFICOS PARA WORDPRESS:

Mas para os exemplos gerais / configurações / fluxos de trabalho:

Para iniciantes: existem padrões de CM, independentes das ferramentas. Google on CM Patterns, muitos livros por aí, até comunidades wiki, por exemplo, http://www.cmcrossroads.com/forums .

Também existem guias sobre como configurar uma estratégia de fluxo válida (estratégia de fluxo do Google), etc.

Não acho que exista algo de especial nas implantações do WordPress em comparação com o CM Management, incluindo o desenvolvimento paralelo distribuído em grandes fábricas Siebel, SAP, Informatica, Java etc. É realmente quase padrão.

O que está faltando, eu acho, é que ninguém escreveu um CMplan para o desenvolvimento do WordPress (ainda) (IEEE). Uma vez que alguém tenha feito isso (independente da ferramenta). Os requisitos podem ser preenchidos, eu acho, com qualquer ferramenta.

Eu acho que a razão pela qual esse plano não foi escrito é que quase todas as implementações do WordPress ainda são feitas por uma pessoa com uma configuração simples de produção e desenvolvimento, portanto, não com vários desenvolvedores / designers na fase de construção que precisam implantar versões diferentes que estão sendo executadas no ambiente de teste, por exemplo.

o plano do CMP começa com a identificação de todos os ICs em outras palavras: faça uma lista de todos os tipos de ICs presentes em uma implementação do WordPress, incluindo aplicativos, plugins, banco de dados, documentação, ajuda, conteúdo, arquivos de configuração, notas de versão (!), etc. ..) Isso é um bom começo. Em seguida, decida quais você deseja incluir no CM.

Em seguida, decida sobre o que causa alterações nesses ICs, por exemplo, uma solicitação do cliente por uma correção de bug ou uma atualização necessária. Se bem feito, isso leva a uma situação em que você sente que as coisas estão sob controle.

Decisões como voltar da produção para o desenvolvimento e a maneira de lidar com isso fazem parte desse capítulo (2 padrões principais aqui) (embora você deva tentar minimizar esses hotfixes).

Somente posteriormente, procure uma ferramenta para executar o CM de um lado (que inclui o gerenciamento de versões como uma das ferramentas) e as ferramentas de gerenciamento de alterações do outro lado (o que o mantém saudável).

Eu acho que esse é o melhor fluxo de trabalho, pois, até onde eu pesquisei, ninguém o fez ainda. Acho que uma vez que a primeira pessoa tenha escrito um Plano de CM do WordPress (de acordo com o IEEE), qualquer outra pessoa do WordPress no mundo poderá copiar esse plano, fazer ajustes e implementar os padrões em suas ferramentas.

Não é muito trabalho / muito pesado: depende se você tem uma empresa ou não: pode economizar muito tempo um dia para ter um bom plano de CM.

Como estou em um host compartilhado, não consigo instalar o SVN ou algo assim. Uso o Mercurial para controlar a versão na minha máquina doméstica. Eu uso a sincronização FTP do Beyond Compare para manter as pastas local e remota sincronizadas.

Estou usando o git. é simples. você só precisa entender comandos simples, como clonar, cometer, pressionar, puxar e está pronto para começar. esse é o básico.

apesar de, se você usar o git mais como coordenar uma equipe para trabalhar em um produto, será outro nível. mas no final, valeu a pena usar git ou qualquer controle de versão. é realizável quando as coisas acontecem.