la lógica de base de trabajo con control de código fuente en localhost + Mercurial

Question

Soy bastante nuevo en Mercurial - en realidad nueva en el control de la fuente

.

Tengo proyectos en localhost, que es ~ / MAMP / htdocs. Quiero trabajar todos locales. Hay un punto que estoy confundido acerca de:

Debería mantener repositorio en un camino diferente al de mis htdocs creo, por lo que creó "/ repeticiones /" carpeta y crear carpetas para cada proyecto bajo aquí, y copiar todos los archivos de la carpeta htdocs proyecto de repeticiones.

  

por ejemplo; Proyecto01

     

copiar archivos de ~/mamp/htdocs/project01/ a   /reps/project01/

Pero yo trabajo en localhost (htdocs) para el cambio de archivos, etc. así que ¿cómo relacionar estos cambios con /reps/?

Es evidente que me falta algún punto muy obvio sobre control de código fuente. ¿He hecho un mal comienzo?

Todos los tutoriales que encontré en línea requiere algún tipo de conocimiento de base, supongo; ninguno de ellos dice nada de lo que significa punto cero! : /

Answer 1

La forma más simple, si usted quiere editar sus archivos en ~/mamp/htdocs/project01/ (porque también estoy de acuerdo en que sería bueno tener algún tipo de área de ensayo donde se puede probar los cambios antes de implementarlos en el servidor de producción, pero tal vez es precisamente su máquina, que es el área de ensayo, por lo que todo está bien entonces :-)) es:

1. Instalar Mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (lo que desea administrar)
5. hg commit -m"initial version"

Después de haber hecho hg init, existe un repositorio en un dir .hg bajo ~/mamp/htdocs/project01/! No es posible evitar esto (aún al menos) con hg: si tiene fuentes en Proyecto01 es necesario tener un acuerdo de recompra en Proyecto01. Y es suficiente, ya que se puede beneficiar de control de versiones con sólo eso, cada vez que se cambia un archivo, puede comprometerse y darle un mensaje de registro para indicar al sistema lo que ha hecho, por ejemplo.,

• <edit> a.html
• hg status (le dirá los archivos actualmente modificados)
• hg diff (le dirá las diferencias con la versión guardada)
• hg commit -m"what-has-changed-message" (guardar una nueva versión)

Aunque no es necesario tener otra cesión temporal en otro lugar (por ejemplo, en / repeticiones) si desea , por ejemplo para tener sus datos en una zona backuped, entonces usted podría clonar el una en $ HOME:

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

¿Qué se pondrá en /reps/project01 una copia exacta de lo que ha hecho: todos los cambios y todos sus mensajes de registro. Ahora bien, si se hace eso, cada vez que haces "hg commit" para guardar un cambio en tu repositorio principal, también es necesario hacer "cd /reps/project01" y "hg pull" en orden para responder a los cambios en / repeticiones, si usted quiere que permanecen sincronizados.

Espero que sea lo suficientemente simple ..

Answer 2

Hay muchos enfoques diferentes / métodos . Aquí es cómo trabajo:

1. Desarrollo: verifico (clon en el caso mercuriales) mis archivos a mi 'entorno de desarrollo' para trabajar en ellos, entonces se comprometen / push / etc. en el mismo lugar.

2. Las etapas siguientes: Una vez que creo que están listos para las pruebas de usuario / producción / o lo que su siguiente paso es, entonces usted puede distribuir su código como un

   2a. paquete (podría ser una postal sencilla de sus últimos archivos) o

   2b. comprobar a cabo en ese directorio siguiente etapa.

3. Otros Usos: Una vez que se sienta cómodo trabajando con los principales escenarios de uso, entonces usted debería considerar otro noreferrer usos de control de versiones como etiquetar , ramificación y fusión

Answer 3

Normalmente, debe mantener su VCS (sistema de control de versiones) y sus archivos separados de su entorno de servidor Web de producción (que es lo que deduzco que está planteando, dada la mención de htdocs).

Muchos sistemas web (al menos de antaño) tienen un área de ensayo, donde se copia el material desde el sistema de origen, que se puede comprobar con cuidado utilizando un segundo (no accesible al público) del servidor web. Cuando está seguro de que el código es correcto, se puede mover en la producción.

Este escenario tiene tres áreas:

• Trabajo (desarrollo) zona con VCS, etc; quizá accesible a través de otro servidor web).
• área de ensayo (sin VCS, sin acceso al público; prueba y validación)
.
• Zona de producción (sin VCS, el acceso público).

Suena un poco como si usted está fusionando estas tres - un escenario común en mi experiencia limitada. Incluso si decide prescindir de la zona de concentración, es necesario separar sus sistemas de desarrollo y producción. Y la VCS (Mercurial) se utiliza en el área de trabajo.