Lógica básica de trabalhar com controle de origem no localhost + mercurial

Question

Eu sou muito novo no Mercurial - na verdade novo no controle de origem.

Tenho projetos no localhost, que é ~/mamp/htdocs. Eu quero trabalhar tudo local. Há um ponto em que estou confuso:

Devo manter o repositório em um caminho diferente dos meus htdocs, eu acho, então criei "/Reps/" Pasta e criando pastas para cada projeto aqui, e copiar todos os arquivos da pasta do projeto HTDOCS para repetições.

por exemplo; Project01

copiar arquivos de ~/mamp/htdocs/project01/ para /reps/project01/

Mas eu trabalho na localhost (htdocs) para alterar arquivos, etc. Então, como eu relaciono essas mudanças com /reps/?

Obviamente, estou perdendo algum ponto muito óbvio sobre o controle de origem. Eu fiz um começo errado?

Todos os tutoriais que encontrei on -line exigem algum tipo de conhecimento básico, eu acho; Nenhum deles diz nada do significado zero ponto! :/

Answer 1

Da maneira mais simples, se você quiser editar seus arquivos em ~/mamp/htdocs/project01/ (Porque também concordo que seria bom ter algum tipo de área de preparação em que você possa testar suas alterações antes de implantá-las no servidor de produção, mas talvez seja precisamente a sua máquina, que é a área de estadiamento, então está tudo bem então:- )) é:

1. Instale o mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (o que você quiser gerenciar)
5. hg commit -m"initial version"

Depois de fazer hg init, há um repositório em um .hg diretor abaixo ~/mamp/htdocs/project01/ ! Não é possível evitar isso (pelo menos) com HG: se você tiver fontes no Project01, precisará ter um repo no Project01. E é suficiente porque você pode se beneficiar do controle de versão com exatamente isso, sempre que alterar um arquivo, pode comprometer -o e dar uma mensagem de log para dizer ao sistema o que você fez, por exemplo,

• <edit> a.html
• hg status (dirá a você os arquivos atualmente modificados)
• hg diff (dirá as diferenças com a versão salva)
• hg commit -m"what-has-changed-message" (salve uma nova versão)

Mesmo que não seja necessário ter outro repositório em outro lugar (por exemplo, em /repetições) se você quer, por exemplo, para ter seus dados em uma zona backupada, então você pode apenas clonar o de $ Home:

• cd /reps
• hg clone /home/name/mamp/htdocs/project01/ project01

Que entrará /reps/project01 Uma cópia exata do que você fez: todas as suas alterações e todas as suas mensagens de log. Agora, se você fizer isso, sempre que fizer "hg commit" Para salvar uma mudança no seu repo primário, você também precisa fazer "cd /reps/project01" e "hg pull" Para encaminhar as alterações para /representantes, se você quiser que ela permaneça sincronizada.

Espero que seja simples o suficiente ..

Answer 2

Há muitas abordagens / métodos diferentes. Aqui está como eu trabalho:

1. Desenvolvimento: Eu verifico (clone no caso Mercurials) em meus arquivos no meu 'ambiente de desenvolvimento' para funcionar neles e depois comprometer/empurrar/etc. No mesmo lugar.

2. Próximos estágios: Uma vez que eu acho que eles estão prontos para testes / produção do usuário / ou qualquer que seja o seu próximo estágio, você pode distribuir seu código como um

   2a. pacote (pode ser um zíper simples dos seus arquivos mais recentes) ou

   2b. Confira -os no diretório do próximo estágio.

3. Outros usos: Depois de se sentir confortável trabalhando com os principais cenários de uso, você deve considerar outros Usivos de controle de revisão como marcação, ramificação e fusão

Answer 3

Normalmente, você deve manter seu VCS (sistema de controle de versão) e seus arquivos separados do ambiente do servidor da Web de produção (que é o que deduzir que você está perguntando, dada a menção ao HTDOCS).

Muitos sistemas da Web (pelo menos antigos) têm uma área de estadiamento em que você copia o material do sistema de origem, que você pode verificar cuidadosamente usando um segundo servidor (não acessível ao público). Quando você está confiante de que o código está correto, pode movê -lo para a produção.

Este cenário tem três áreas:

• Área de trabalho (Desenvolvimento) com VCs, etc; talvez acessível através de mais um servidor da web).
• Área de estadiamento (sem VCs, sem acesso público; teste e validação).
• Área de produção (sem VCs, acesso público).

Parece um pouco como se você estivesse confundindo esses três - um cenário comum em minha experiência limitada. Mesmo se você decidir ficar sem a área de estadiamento, precisará separar seus sistemas de desenvolvimento e produção. E o VCS (mercurial) é usado na área de trabalho.