Estou desenvolvendo um site em php em localhost e, à medida que os módulos são concluídos, carrego-o na nuvem para que meus amigos possam testar o alfa.

Enquanto continuo desenvolvendo, tenho muitos arquivos e perco o controle de quais arquivos editei ou alterei etc. Ouvi falar de algo como 'controle de versão' para gerenciar todos eles, mas não tenho certeza de como funciona.

Portanto, minha pergunta é: Existe uma maneira fácil / serviço / aplicativo disponível para rastrear todas as edições / alterações / novos arquivos e gerenciar os arquivos à medida que desenvolvo o site. Assim que terminar um módulo, quero carregá-lo na nuvem (estou usando o Amazon Cloud Service). Se algo acontecer com os novos arquivos, talvez eu queira voltar ao arquivo antigo. E talvez, em um clique ou dois, eu consiga ver os arquivos que editei ou alterei desde o último que carreguei?

O gerenciamento de configuração de software , do qual o Controle de versão faz parte, é um pouco mais complexo do que acompanhar as alterações nos arquivos, embora você certamente possa começar com isso. Mas leia os artigos da Wikipedia relacionados acima, juntamente com o tutorial de Joel Spolky sobre Mercurial .

Para começar, escolha um Mercurial, GIT ou Bazaar, nessa ordem, e instale-o junto com as ferramentas para o seu IDE e sistema operacional (eu prefiro o Mercurial com HGE for Eclipse).

1. Inicialize um repositório a partir do seu diretório de trabalho ( hg init com Mercurial) ..
2. Decida quais arquivos e diretórios você deseja rastrear e quais não. A regra geral é não rastrear arquivos gerados por compiladores e outras ferramentas.
3. Use o comando para adicionar os arquivos e diretórios ao repositório ( hg add for Mercurial).
4. Informe a ferramenta sobre os padrões dos arquivos que você não deseja rastrear (edite .hgignore para Mercurial).
5. Execute uma confirmação para rastrear as versões originais ( hg ci ).
6. Execute uma confirmação após cada marco lógico, mesmo que seja pequeno.
7. Adicione novos arquivos ao criá-los.
8. Repita os dois últimos.
9. Faça backup do diretório de trabalho e do repositório com a frequência razoável.

Com seus arquivos no repositório, você pode conhecer as diferenças entre as duas versões de um arquivo ou diretório ou o projeto completo ( hg diff ), ver o histórico de alterações ( hg hist ) e reverter as alterações ( hg up -r )

É uma boa idéia marcar ( hg tag ) o repositório antes de publicar seu código, para que haja uma maneira fácil de voltar exatamente ao que você publicou para alterações ou comparações.

Se você quiser experimentar uma linha de desenvolvimento diferente, faça-o em uma ramificação simples, clonando o repositório principal ( hg clone ) e não recuando até que o experimento seja conclusivo. É tão fácil quanto ter um diretório de trabalho diferente para o experimento.

Se a experiência for para uma versão nova e atualizada, clone e ramifique (ramificação hg ) para manter todas as cópias dos repositórios atualizadas sem que uma experiência interfira na outra.

Linus Torvalds (que lida com dezenas de milhares de arquivos e milhões de linhas de código em seus projetos) fez uma palestra no Google sobre por que a ferramenta não pode ser CVS, SVN ou qualquer um dos muitos gratuitos e comerciais disponíveis ; vale muito a pena assistir.

Eu recomendo o Git. Saiba mais aqui: https://lab.github.com/

Se você não gosta do Git, existem outras soluções de controle de versão. Você pode conferir o SVN.

É só você ?, use um DVCS

Por mais contra-intuitivo que pareça, é melhor começar com um Sistema de Controle de Versão Distribuído (mercurial, git, bazar) do que um sistema centralizado (svn, cvs). Por quê ?, você o instala em sua máquina e executa seu repositório localmente, e é isso. Em um sistema centralizado como o svn, você precisa configurar seu cliente e um servidor ... e, em seguida, você precisa se conectar a um servidor para armazenar suas alterações.

Com um DVCS, você é o repositório local e, se desejar, pode usar um serviço como bitbucket.org ou github.com.

IMHO, mercurial é um DVCS mais amigável e igualmente capaz para começar.

Existem outros ?, use um DVCS!

Existem inúmeras vantagens ao usar um DVCS para trabalhar com uma equipe, a mais importante em contraste com um sistema centralizado é que não existem corridas de confirmação e isso ocorre porque, tecnicamente, o repositório de cada indivíduo é uma ramificação e quando você compartilha seu altera essas ramificações que são mescladas para você e você nem percebe, o que significa que, em vez de ter um histórico de versões como este, onde você tem pessoas canalizando seu trabalho em linha reta:

Você acaba tendo algo parecido com isto, onde todos cometem ad hoc:

Cada um se preocupa com seu próprio trabalho durante o controle de versão (ou seja, não corre para confirmar) e não se preocupa com uma conexão com um servidor apenas para confirmar.

Boa sorte

Para ser breve, existem muitas alternativas, entre as quais o Subversion (SVN) e o Git parecem mais populares (portanto, é mais fácil encontrar soluções na web).

Ambos diferem. O SVN é mais simples, mas o Git não exige que você tenha um servidor - você pode controlar a versão localmente.

Supondo que você tenha Linux e deseje começar a usar o Git:

1. Instale o Git
2. Vá para o diretório e execute o comando 'git init'
3. Aprenda a adicionar arquivos, revisar alterações, enviá-las ...
4. ... e fazer coisas mais avançadas (revisando logs, revertendo alterações, ignorando arquivos, criando ramificações, mesclando-as, criando e usando controles remotos, usando submódulos, usando suporte a SVN etc.).

Espero que isso ajude você a começar.

Como o Apalala sugere, eu recomendo o check-out do hginit . Como você é novo no controle de versão, pode pular a primeira página. Isso deve lhe dar uma boa introdução; depois, você pode postar no SO se tiver perguntas específicas.

Eu vou contra a opinião da maioria e recomendo o Subversion. O Subversion é fácil de usar e faz todo o material necessário para indivíduos e equipes pequenas. É um produto maduro, portanto, todo IDE disponível no mercado tem um bom suporte. Sim, ele não tem todos os recursos do Git. (Eu nunca usei o Mercurial, então não falarei sobre isso.) Mas a maioria dos desenvolvedores não precisa desses recursos adicionais.

Vários repositórios? Tenho certeza de que existem usos legítimos para esses, mas nunca os encontrei.

Ser capaz de fazer confirmações locais, sem acesso à rede? É bom ter isso, se você estiver fazendo várias alterações discretas e não puder acessar o servidor de repositório - mas, honestamente, com que frequência isso acontece?

O Git facilita o processo de ramificação e fusão. Mas para uma equipe de uma pessoa, isso não é grande coisa.

Para algo na escala do kernel Linux - sim, use Git. Para o resto de nós, o Subversion é bom o suficiente.

Eu acho que um sistema de controle de versão distribuído funcionará bem. As escolhas comumente sugeridas são Git e Mercurial (Hg). Ferramentas gráficas podem ser úteis, para o Mercurial eu recomendo o TortoiseHg .