it-swarm-pt.tech

Introdução ao Subversion, Git ou Sistema de Controle de Versão semelhante a um histórico dos meus arquivos?

Percebo que essa pode ser uma questão 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, quando desenvolvo um site (e mesmo depois dele ao vivo), geralmente 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?

31
Travis Northcutt

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

Embora dependa do servidor do seu site ao vivo, o GIT instalou (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, eu o mesclo na ramificação production, depois o SSH no servidor do site ao vivo e obtenho as alterações. Bate arrastando arquivos sobre FTP quando você nunca sabe se você está sobrescrevendo as alterações 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 cargas de arquivos (e ao contrário de SVN não coloca estúpido .svn folder everywhere ).

Assim:

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

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

Se eu fosse colocar tudo em um novo, eu faria:

  1. Instalar Coda

  2. Instalar Porticus (que requer que você instale 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 GitX 7-5

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

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

Configurando tudo no servidor pode ser um pouco complicado, eu tenho um MediaTemple e uma conta Dreamhost que ambos têm 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 na 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)

14
Joe Hoyle

Eu uso o SVN para controle de versão com everything eu 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, basta verificar um plug-in diretamente no diretório /wp-content/plugins/ da minha instalação local do WordPress (eu corro 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 as alterações necessárias e desenvolvo até que esteja pronto, comprometendo revisões à medida que vou.

Quando eu estiver pronto para publicar o tema no servidor de produção de um cliente, eu exporto o repositório, Zip it e uso os temas nativos >> Adicionar nova funcionalidade dentro do 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 específico.

Para SVN, eu uso Tortoise SVN . É grátis, notavelmente 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 do mouse e selecione operações de comando. O uso de "Exportar" permite que você envie a pasta inteira (sem as pastas .svn irritantes) diretamente para qualquer local de sua escolha - eu exporto com freqüência 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, é muito mais fácil substituir os arquivos antigos (e não é 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.

8
EAMann

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ê. http://beanstalkapp.com/ As ferramentas de implantação de FTP são incríveis. 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 essa é 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 GUI disponíveis no SVN.

3
Andrew

Eu gosto Aptana muito, é o Subversion integrado e você pode se conectar ao seu servidor com ftp/sftp facilmente e empurrar arquivos para cima, outro grande recurso que tem é que se você criar um novo projeto php e incluir o "inteira" pasta WordPress (com wp-admin, wp-includes) você recebe o preenchimento de código em seus arquivos de tema.

Na minha configuração, o repo é local.

2
Amit

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 gerais/setups/workflows:

Para começar: existem padrões CM, tão independentes de ferramentas. Google no CM Patterns, muitos livros por aí, comunidades do wiki, por exemplo http://www.cmcrossroads.com/forums .

Há também 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 falta, penso eu, é que ninguém escreveu um CMplan para o desenvolvimento do WordPress (ainda) (IEEE). Uma vez que alguém tenha feito isso (independente de ferramenta). Os requisitos podem ser preenchidos, penso eu, com qualquer ferramenta.

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 em execução 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 IC presentes em uma implementação do WordPress, incluindo 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 CIs, por exemplo, 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 mesclar de volta 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).

Só depois procurar uma ferramenta para fazer CM em um lado (que inclui o gerenciamento de versões como uma das ferramentas) e alterar o ferramental de gerenciamento no outro lado (o que o mantém sã).

Eu acho que é o melhor fluxo de trabalho para começar desde que, até onde eu googled, 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.

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

1
edelwater

Eu estou em um host compartilhado, então eu não posso instalar o SVN ou qualquer coisa assim. 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.

0
CAD bloke

eu estou usando o git. é simples. você só precisa entender o comando simples como clone, comit, push, pull e está pronto para começar. esse é 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.

0
justjoe