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

30

Sei que essa pode ser uma pergunta ampla na 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ões de arquivos editados em um site do WordPress. Por exemplo, ao desenvolver um site (e mesmo depois de ele estar ativo), muitas vezes faço alterações em arquivos CSS e PHP, mas não tenho uma maneira excelente de reverter para versões mais antigas desses arquivos. Para os meus propósitos, fazer alterações em uma instalação de desenvolvimento local e, em seguida, copiar essas alterações para o site ativo 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 acompanhar edições em arquivos em um site ativo?

    
por Travis Northcutt 12.08.2010 / 17:30
fonte

7 respostas

14

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

Embora dependa do servidor do seu site ao vivo, o GIT está instalado (ou permitirá que você). Eu tenho uma configuração do GIT no servidor live também, executando uma ramificação chamada algo como production . Sempre que eu termino de implementar / corrigir algo localmente, mescle-o na ramificação production , depois em SSH no servidor do site ativo e receba as alterações. Bate arrastando arquivos sobre FTP quando você nunca sabe se você está sobrescrevendo as mudanças, etc.

Eu recomendaria colocar algum tempo ficando aquatinted com GIT (se você não tiver já), acho muito mais fácil e menos incômodo do que SVN quando se trata de mudar / adicionar um monte de arquivos (e ao contrário do SVN não faz t coloque a pasta .svn estúpida em todos os lugares ).

Então:

Claro, estou em um Mac, desculpe se nada disso se aplica.

Editor de códigos: Coda GIT Instalado através de Portas (usando Porticus) Git: GitX

Se eu tivesse que configurar tudo, eu faria:

  1. Instale Coda

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

  3. Uma vez que você tenha instalado o Porticus, abra-o, procure por "git-core" e instale-o.

  4. Baixe e instale GitX 7-5

  5. Há um bom guia sobre como configurar um repositório de git aqui , mas no básico: 1. Abra o Terminal . 2. cd para onde você deseja que seu site resida. $: mkdir mysite && cd mysite 3. $: git init e pronto! Se você adicionar arquivos a esta pasta, continue na próxima etapa

  6. Uma vez que você tenha configurado um repositório GIT localmente (acima do artigo), então se você abrir esse diretório no GitX, você poderá cometer coisas, etc. etc.

Configurar tudo no servidor pode ser um pouco complicado, eu tenho um MediaTemple e uma conta Dreamhost que ambos têm o GIT fora da caixa. O link em 5. diz-lhe como adicionar um repositório remoto, você não tem que fazer isso até que você queira trazer o seu site ao vivo para a equação. Eu recomendaria fazer com que tudo funcionasse localmente primeiro (ao contrário do SVN, o GIT não requer um repositório remoto, por isso você pode ter tudo em sua máquina por enquanto)

    
por Joe Hoyle 12.08.2010 / 17:43
fonte
8

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

Plug-ins

Como os plug-ins já estão hospedados no servidor do WordPress, eu apenas verifico um plug-in diretamente para o diretório /wp-content/plugins/ da minha instalação local do WordPress (eu executo o WAMP na minha caixa de desenvolvimento). Em seguida, faço alterações em minha cópia local e, quando estiver pronto para o showtime, confirme no 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, especialmente ao criar um cliente. Eu crio um repositório local (eu tenho uma partição R no meu disco rígido especificamente para este propósito) e confiro o repositório vazio diretamente no meu diretório /wp-content/themes . Então eu faço alterações conforme necessário e desenvolvo até que esteja pronto, comprometendo as revisões conforme eu for.

Quando eu estiver pronto para publicar o tema no servidor de produção de um cliente, exporte o repositório, compacte-o e use os temas nativos > > Adicione nova funcionalidade no WordPress. Isso funciona também com plug-ins personalizados (que não são hospedados pelo WordPress).

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 permite que eu execute quantas instâncias do WordPress forem necessárias para um projeto em particular.

Para o SVN, eu uso o Tortoise SVN . É grátis, incrivelmente fácil de usar e se integra com a estrutura de arquivos e comandos do Windows. Atualizar, confirmar e exportar são simples, clique com o botão direito e selecione operações de comando. Usar "Exportar" permite que você envie a pasta inteira (sem as pastas .svn ) diretamente para qualquer local de sua escolha - eu exporto frequentemente para a área de trabalho. Fechar a pasta também é uma operação de clique com o botão direito, e o WordPress lida com o upload.

A transferência manual de arquivos pode ser um problema, especialmente se você continuar alterando um arquivo, mas não todos. Se você, em vez disso, transferir o FTP por todo o diretório com "substituir tudo" selecionado, será muito mais fácil substituir os arquivos antigos (e não será necessário controlar quais foram alterados e quais não foram). É como a antiga instalação de 5 minutos que o WordPress costumava ter - basta substituir tudo pela nova versão.

    
por EAMann 12.08.2010 / 20:06
fonte
3
Pessoalmente, acho que é um exercício divertido instalar o SVN / GIT e gerenciá-lo, mas se você puder gastar US $ 15 por mês, o Beanstalk vale cada centavo. Eles gerenciam todo o servidor para você. enlace As ferramentas de implantação do FTP são impressionantes. O meu implanta automaticamente a versão para o meu servidor de temporariedade quando eu me comprometo por exemplo

Outra maneira de obter algumas versões de arquivos pessoais é usar a caixa suspensa. Toda vez que você salva um arquivo em sua caixa de depósito, ele rastreia a versão e você pode restaurar qualquer versão anterior mais tarde. Você e outro desenvolvedor ou grupo podem compartilhar uma pasta suspensa. Concedido isso não faz troncos, mescla, etc, mas torna muito fácil para uma equipe distribuída para trabalhar 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, depois eu confirmo os arquivos quando a hora é escrita. Meus designers não irão enviar arquivos ou lidar com o SVN, então esta é a compromisso.

Eu prefiro o SVN porque eu não preciso de todo o entroncamento que o GIT é tão bom e há melhores ferramentas de GUI disponíveis no SVN.

    
por Andrew 23.08.2010 / 15:10
fonte
2

Eu gosto Aptana muito, tem subversão integrada e você pode se conectar ao seu servidor com ftp / sftp facilmente e enviar arquivos up, outro grande recurso que tem é que, se você criar um novo projeto php e incluir a pasta "inteira" do WordPress (com wp-admin, wp-includes), você terá a conclusão de código nos arquivos do seu tema.

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

    
por Amit 12.08.2010 / 17:46
fonte
1

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ões de arquivos editados em um site WordPress", mas você também mencionou produtos:)

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

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

Para iniciantes: existem padrões CM, de forma independente do ferramental. Google no CM Patterns, muitos livros por aí, comunidades do wiki, por exemplo enlace .

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

Não acho que exista nada 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. É quase 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 (ferramenta independente). Os requisitos podem ser preenchidos, penso eu, com qualquer ferramenta.

Eu acho que o motivo pelo qual o 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 desenvolvimento de produção, não com vários desenvolvedores / designers na fase de construção tendo que implantar versões diferentes. executando no ambiente de teste, por exemplo.

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

Em seguida, decida o que causa alterações nesses ICs. uma chamada de cliente para uma correção de bug ou uma atualização necessária. Se feito corretamente, isso leva a uma situação em que você tem a sensação de que as coisas estão sob controle.

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

Somente depois procurar uma ferramenta para fazer CM em um lado (o que inclui o gerenciamento de versões como uma das ferramentas) e alterar o conjunto de ferramentas de gerenciamento no outro lado (o que o mantém saudável).

Acho que esse é o melhor fluxo de trabalho para começar, já que, até onde eu pesquisei, ninguém fez ainda. Eu acho que uma vez que a primeira pessoa tenha escrito um Plano CM WordPress (de acordo com o IEEE), qualquer outra pessoa do WordPress no mundo pode copiar esse plano e 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 um tempo para um bom plano de CM.

    
por edelwater 15.11.2010 / 00:38
fonte
0

Estou em um host compartilhado, por isso não posso instalar o SVN nem nada do tipo. Eu uso o Mercurial para controle de versão na minha máquina doméstica. Eu uso o FTP-sync do Beyond Compare para manter as pastas locais e remotas em sincronia.

    
por CAD bloke 14.08.2010 / 04:24
fonte
0

eu estou usando o git. é simples. você só precisa entender o comando simples como clone, comit, push, pull e está pronto para começar. é o básico.

mesmo assim, se você usar o git mais como coordenar uma equipe para trabalhar em um produto, então é outro nível. mas no final, valeu a pena usar o git ou qualquer controle de versão. há realiable quando a merda acontecer.

    
por justjoe 22.08.2010 / 20:07
fonte