Uso de Git como control de origen para desarrollo web y entorno múltiple

Poco context: somos un equipo de 6 desarrolladores que trabajan en una aplicación web. Desde su lanzamiento, hemos utilizado CVS como nuestro sistema de control de fuente en un server de Windows utilizando ColdFusion w / Eclipse. Con todo el bombo en torno a Git y los sistemas distribuidos últimamente, pensamos que lo verificaríamos.

Como aplicación web estándar, tenemos nuestro entorno local donde desarrollamos nuevas funciones / correcciones de errores. Un entorno de desarrollo donde empujamos todo para testings iniciales por QA. La etapa en la que enviamos las características / soluciones que ya se han probado en este entorno es imitar lo más posible a nuestros serveres de producción. Finalmente, todo sucede en el sistema en vivo en el desierto …

Este process es bastante doloroso en algún momento, ya que la mayor parte se hace con FTP y lo que no y a menudo encontramos conflictos al comprometernos, ya que algo se está demorando más de lo habitual para probar o cuando se requiere una solución rápida de errores con urgencia.

Estoy un poco confundido en cuanto a cómo funcionaría Git en este caso, obviamente no es un escenario poco común, pero la mayoría de lo que he encontrado no lo menciona en detalle.

Si entiendo correctamente que las sucursales locales desempeñan un papel importante con Git, cloné el repository de git primero, luego ramifiqué, arreglé algo y lo devolví todo a nivel local.

¿Entonces puedo volver a enviarlo al repository principal debajo del maletero que trata con los conflictos de fusión si hay alguno?

Si mis suposiciones son correctas, entonces la pregunta principal es qué sucede con la puesta en escena. Obviamente, algunas características / arreglo tardan más en probarse, algunas son más urgentes, etc. ¿Sería capaz de hacer algo así como un tirón de ciertas características / twigs en la puesta en escena para la firma final y luego hacer lo mismo desde el server en vivo ( tirar mientras están firmados)?

Es bastante tomar en count desde un background de CVS … ¡cualquier ayuda sería muy apreciada!

  • Las sucursales locales son importantes porque puedes crear tantas como quieras y combinarlas con bastante facilidad.
  • Las sucursales de seguimiento (en realidad una sucursal local siguiendo una de seguimiento remoto ) son mucho más relevantes en su caso, ya que le permiten vincular formalmente una sucursal local a una remota, con fines de publicación (otra gran característica de DVCS: puede " publicar " se compromete con un repository remoto u otro)

La idea es definir:

  • informe vacío para fines de empuje
    • un revelador dev revelador donde todos los desarrolladores pueden impulsar su trabajo actual y / o retirar trabajos de sus colegas (una especie de repository "central" local, pero existen muchos otros flujos de trabajo , como el descrito en esta página del libro de ProGit )
    • un repository de etapas desnudo donde se empuja una twig de etapas con las cosas para probar / validar.
      El equipo de QA puede clonar ese repository para get un directory de trabajo intermedio donde puedan ejecutar y probar el website.
    • un repository simple en un server en el entorno de producción.
      El administrador de prod puede clonar eso, y luego rsync / ftp a los serveres de producción reales que administrarán el website en vivo.
      Nota: no debe tener ningún DVCS en el server de producción real. Solo debe tener lo que necesita para ejecutar / supervisar un entorno de producción.

El flujo de trabajo básico se basa en empujar / tirar twigs entre esos entornos (repos):

  • en el repository de revelado y puesta en escena, puede mantener varias sucursales públicas oficiales, un poco como el mantenedor de Git Julio C. Hamano lo hace con sus twigs 'pública', 'maint', 'próxima', 'pu' .
  • antes de llevar cualquier cosa a la puesta en escena, puede volver a basar su trabajo en la parte superior de la twig de sorting remota para resolver localmente cualquier conflicto y actualizar su trabajo de desarrollo local con cualquier corrección detectada / realizada en el área de preparación.
  • empujar de la etapa a la producción debe ser trivial (sin conflictos, ya que no se realiza ninguna modificación en el lado de prod repo)
  • puede definir hooks en el repository de transición y prod repo para aceptar solo ciertas twigs, y rechazar cualquier creación de twig (como oposition a todos los dev repos donde puede definir / empujar / arrastrar tantas twigs como necesite)