git en un equipo de desarrollo web utilizando 1 server de desarrollo remoto y sin entorno de desarrollo local

Estoy trabajando en una agencia web con un pequeño equipo (5 desarrolladores, 2 diseñadores). Principalmente trabajamos con aplicaciones web PHP / MySQL que incluyen Magento, Experession Engine y CakePHP. Usamos una combinación de Windows 7 PC'S (desarrolladores) y Mac's en OSX (diseñadores).

He estado buscando usar github para nuestros proyectos con 3 objectives principales:

  1. Para ver quién ha editado los files y permitir que las personas comenten sobre los files.

  2. Para evitar sobreescribir el trabajo de los demás, ya que a veces es el caso, varias personas pueden intentar trabajar en el mismo file al mismo time.

  3. Permitir retrocesos a versiones anteriores de un file.

Este es nuestro flujo de trabajo actual y no entiendo cómo Github encaja con esto en absoluto. Me doy count de que nuestro flujo de trabajo necesitará cambios, pero no he podido encontrar un process que de alguna manera parezca encajar con esto:

  1. Todo nuestro trabajo se realiza en un server web remoto que es específicamente para el desarrollo (nada "en vivo" se encuentra aquí). El server ejecuta Apache, PHP, MySQL, etc. Nadie tiene un entorno de desarrollo local configurado en su máquina y no queremos eso si es posible.

  2. Todos tenemos acceso FTP al server de desarrollo mencionado anteriormente. En general, editamos files directamente en este server de desarrollo, ya que ofrece una forma muy rápida de probar cosas (literalmente editar un file, cargarlo y ejecutarlo en el browser). Hay problemas con conflictos, por ejemplo, varias personas que intentan editar el mismo file, y es por eso que estoy buscando usar git.

  3. Cuando todo ha sido aprobado en el server de desarrollo, se realiza en vivo copiándolo en un server diferente. El server en vivo puede estar en cualquier lugar, usamos algunos serveres que administramos nosotros mismos, a veces utilizamos compañías de hosting de terceros, varía.

He estado investigando esto durante los últimos días y todos los enfoques que encuentro me parecen imposibles de usar. ¿Alguien tiene alguna idea de la mejor manera de lograr esto? ¿O estoy buscando algo que ni siquiera es aplicable para los problemas que trato de resolver?

Agradecería cualquier consejo útil que las personas puedan ofrecer.

Gracias.

Podrías crear un repository git en tu máquina de testing y hacer que cada uno de tu equipo use git para enviar sus cambios a ese repository. De esta forma, recibirán una notificación cuando sus cambios entren en conflicto con los de otras personas.

Un flujo de trabajo típico podría verse así:

  1. Desarrollador1 cambia algo en su máquina.
  2. Designer1 cambia algunos files en su máquina
  3. Designer1 confirma esos cambios en su repository git local
  4. Desarrollador1 confirma esos cambios en su repository git local
  5. Desarrollador1 empuja sus cambios a la máquina de desarrollo.
  6. Designer1 empuja sus cambios a la máquina de desarrollo
    1. en caso de conflicto con los cambios de Developer1, ahora se le preguntará cuáles son esos conflictos y tendrá que resolverlos.
    2. Luego, los cambios resueltos se enviarán a la máquina de desarrollo.

Esto debería arreglar su problema 1.) y 3.) y hará de 2.) una acción explícita, lo que significa que sus desarrolladores y diseñadores verán qué están anulando. Si los cambios ocurren en diferentes partes de un file al mismo time, entonces git puede mantener ambos cambios sin necesidad de interacción adicional.

Pero ten cuidado, que esto todavía tiene el problema, que nadie podrá probar sus propios cambios sin la interferencia de otras personas, ya que pueden cambiar las cosas en cualquier momento mientras alguien intenta probar algo. Con solo 1 máquina de desarrollo no puedes evitar que esto ocurra solo con git. Como su equipo es bastante pequeño y su enfoque actual no lo soluciona, puede ser de poca importancia para usted.

Tenemos una configuration muy similar en la empresa en la que trabajo. De hecho, tenemos un sandbox diferente en el server de desarrollo. En otras palabras, clonamos el repository en diferentes entornos limitados. Cada desarrollador / diseñador obtiene una caja de arena. Por ejemplo, si hay 3 desarrolladores, habrá 3 directorys de sandbox + 1 directory de etapas

Entonces, el desarrollador john obtiene /home/john/example.com y se puede ver en john.example.hot (configuration de vhosts) mike obtiene /home/mike/example.com visto en mike.example.com tracy gets / home /tracy/example.com visto en tracy.example.com Y habrá un directory de etapas adicional. /home/staging/example.com staging.example.com

La estadificación fusiona todos los cambios para que se pueda probar. Todos estos directorys son accesibles solo con IPS interno.

Implementamos estos cambios en la producción utilizando RSYNC. Más información aquí sobre RSYNC: http://www.cyberciti.biz/tips/linux-use-rsync-transfer-mirror-files-directories.html