Drupal 6: uso de bitbucket.org para mis proyectos de Drupal como un maniquí del sistema de control de versiones real

¡Aquí hay un maniquí del sistema de control de versiones real! buen principiante!


La forma en que he trabajado hasta ahora:

Tengo un proyecto web de Drupal-6 www.blabla.com y desarrollo en www.blabla.com/beta . Estoy trabajando directamente en blabla.com/beta en el server. nada en mi local, nada en ningún otro lado. Solo tomando copys de security locales, de vez en cuando. Sé de manera horrible y no segura: /


La nueva forma en que quiero trabajar a partir de ahora:

Decidí usar Mercurial . Tengo un desarrollador más para trabajar en el mismo proyecto conmigo. Tengo un proyecto de Drupal-6 de blabla.com en bluehost y desarrollo blabla.com/beta. Descubrí http://bitbucket.org/ para alojamiento mercurial. He creado una count

Entonces, ¿cómo configuro las cosas? Estoy totalmente confundido después de leer decenas de artículos: /

  • bitbucket es solo para alojar files revisados? entonces, si yo o mi amigo desarrollador editamos index.php, bitbucket solo alojará index.php?
  • ¿De ahora en adelante tengo que trabajar en localhost y upload los cambios a blueshost? no más edición directamente en blabla.com/beta? o ¿todavía puedo trabajar en bluehost tal vez en blabla.com/beta2?
  • Cuando necesito editar cualquier file, ¿primero descargo la actualización de bitbucket, realizo mi cambio en localhost, actualizo bitbucket para los files editados y lo cargo en bluehost?

Perdón por las preguntas tontas, realmente necesito una guía …

¡Apreciar ayuda tanto! ¡muchas gracias!

bitbucket es solo para alojar files revisados?

El service principal de bitbucket es alojar files bajo control de revisión, pero también hay una forma de almacenar files arbitrarios allí.

entonces, si yo o mi amigo desarrollador editamos index.php, bitbucket solo alojará index.php?

En un proyecto típico, cada file que pertenece al producto se somete a control de revisión, no solo index.php. mira este ejemplo

¿De ahora en adelante tengo que trabajar en localhost y upload los cambios a blueshost? no más edición directamente en blabla.com/beta? o ¿todavía puedo trabajar en bluehost tal vez en blabla.com/beta2?

Mercurial no dicta un flujo de trabajo de reparación. Pero le recomiendo que tenga mercurial instalado donde edita los files. Por ejemplo, puede ver los cambios que realizó desde la última confirmación, sin tener que copyr los files de su server a su repository local.

Recomiendo absolutamente un flujo de trabajo donde en algún lugar del repository hay un script que genera el file de almacenamiento que se transmite al server, que contiene la revisión del repository cuando se creó el file. Esta información de revisión también debe estar en algún lugar almacenada en el server (no necesariamente en un área accesible para el público), ya que esta información puede ser muy útil cuando algo salió mal.

Cuando necesito editar cualquier file, ¿primero descargo la actualización de bitbucket, realizo mi cambio en localhost, actualizo bitbucket para los files editados y lo cargo en bluehost?

Hay varios enfoques diferentes para get los datos en el server:

  • exportar el repository local a un file y transmitirlo al server ( hg archive production.tar.bz2 ), esta es la variante más segura, ya que no depende de ningún software adicional en el server. Además, dependiendo de cuán grande sea el file, este enfoque puede desperdiciar mucho ancho de banda.
  • trabajar en el server y copyr los files modificados, pero no lo recomiendo, ya que es muy fácil perder algo importante
  • instale mercurial en el server, trabaje en una copy de trabajo allí y hg export localmente allí al área de producción
  • instalar mercurial en el server y hg fetch desde bitbucket (o cualquier otro repository accesible por el server)
  • instale mercurial en el server y hg push desde su copy local de trabajo al server (y hg update en el server luego)

Los dos últimos puntos pueden exponer el repository al público. Esta exposition puede ser tanto buena como mala, dependiendo de lo que contenga su repository, y si desea compartir el contenido. Cuando desee compartir el contenido, o puede limitar el acceso a http://www.blabla.com/beta/.hg, puede clonar directamente desde su server web.

También tenga en count que no debe registrar ningún file con passwords o secretos críticos , incluso cuando acceda a limitar el repository. Es mucho más fácil save los files de plantilla (con un nombre diferente que en producción) y copyr y editar estos files en el server.