Git – máquinas múltiples por desarrollador – se compromete en todas las máquinas, pero no en la twig principal

Estamos en transición a git desde SVN, y hay algunos conceptos que no puedo entender.

Tenemos una configuration de la siguiente manera:

  • server en vivo, "en vivo"
  • server de desarrollo interno, "local" (server git, svn daemon, todos los repos residen en este)
  • estaciones de trabajo (iMacs)
  • computadoras hogareñas (principalmente PC linux)

Convertí nuestra fuente en un repository de git y me comprometí con "local". Todo funciona bien, y cuando lo clono, copy la twig principal en mi entorno local, ya sea que esté en casa o en el trabajo. Tirar del server en vivo también funciona bien, y lleva los cambios de la twig maestra al entorno en vivo. Pero quiero tener las siguientes posibilidades:

  • Quiero ser capaz de desarrollar y comprometerme en la estación de trabajo sin presionar a la twig principal, pero me gustaría que estos cambios también se reflejen en mi máquina doméstica. En otras palabras, quiero poder hacer una actualización o function parcial, comprometerme y continuar trabajando en ella en casa sin que sea arrastrada a ningún tipo de twig activa. ¿Esto se logra con la ramificación? ¿Me comprometo y luego presiono a una twig específica? Eso sí, rastrear el repository git de la estación de trabajo con la computadora hogareña está fuera de cuestión, ya que la estación de trabajo no siempre está encendida (cualquiera que haya ejecutado una aplicación java en una Mac sabe que solo puede permanecer durante un par de horas como máximo)

  • Quiero que cada desarrollador pueda trabajar en su propia parte de la aplicación, sin que dependamos unos de otros. ¿Es aconsejable hacer esto con twigs por desarrollador, o deberíamos hacer twigs por function?

  • Cuando se completa el trabajo en una característica, ¿es aconsejable fusionar la twig en el repository principal y luego extraer las actualizaciones de repository maestro en el entorno en vivo, o deberíamos tener una sucursal de "producción" separada para estos fines? ¿Cómo se maneja la implementación en vivo a través de git? Dado que tenemos una frecuencia de lanzamiento de aproximadamente 10 revisiones por día (ciclos de desarrollo extremadamente rápidos), SVN funcionó muy bien hasta el momento en que nuestro sitio en vivo es solo un checkout del repository y siempre que una actualización está list, simplemente llamamos a svn update on esos files en el server en vivo. ¿Alguna de las mejores prácticas con respecto a esto con git?

Editar:

Ejemplo práctico con mis suposiciones sobre cómo funciona todo esto: digamos que nuestro proyecto es "proyecto", y tenemos desarrolladores "dev1", "dev2" y "dev3", cada uno con 2 máquinas. El equipo tiene 3 tareas: "error", "function" y "queueboración". El error está asignado a dev1, function a dev2, y la queueboración es una característica en la que los tres deben trabajar juntos ($ REMOTE es la URL del repository principal en nuestro server de desarrollo local, es decir, usuario @ local: repo.git):

=========

I. Trabajando localmente

Como dev1 está asignado a "error", se encargará de eso. Él hace lo siguiente:

$git branch bug $git checkout bug // switches to bug branch ( // edit some files) $git commit -a -m 'I fixed the bug!' $git push $REMOTE bug 

¿Cómo combina ahora este desarrollador su solución en el repository principal y cómo elimina la twig de errores en todas las máquinas una vez que se realiza esta fusión? Me gustaría que la twig de errores desaparezca cuando las personas hagan una actualización o busquen algo por si lo revisaron o como lo recupere.

========

II Trabajando localmente, y luego continuando en la misma twig sincronizada en otra location

"feature" ha sido asignado a "dev2" y lo hace:

 $git branch feature $git checkout feature // switches to feature branch ( // edit/add some files etc. ) $git commit -a -m 'I made some updates, will continue at home' $git push $REMOTE feature // at home, the developer does the following, right? $git clone $REMOTE -b feature /some_new_folder // if he didn't clone the whole repo previously or cd previously_cloned_repo_master_or_whatever $git fetch $git checkout $REMOTE feature ( // right? ) ( // edit some files then ... ) $git commit -am 'I finished!' $git push // Same as above, what next? How to merge it into all other branches and safely delete the branch afterwards. What happens when someone is in a branch that has been deleted, and makes a pull? 

========

III Mucha gente en una twig, separada de la twig principal

"queueboración" es un esfuerzo set, y los tres desarrolladores de las 6 ubicaciones trabajarán en set. Es creado por dev3.

 $git branch collaboration $git checkout collaboration // switches to needed branch ( // add something, so we have something to commit) $git commit -a -m 'Initialized new branch' $git push $REMOTE collaboration ( // The other two devs can then simply call .. ) $git fetch $git checkout $REMOTE collaboration ( // And they're ready to go, right? ) ( // Each dev then makes his own edits on some areas, commits, and pushes. All pushes change the content of the branch, so that if dev2 pushed and dev1 makes $git pull in the root of the project while on this branch, dev1 will get his changes, right? ) 

========

Además, ¿es posible restringir una twig a un creador de twig específico? Por ejemplo, me gustaría ver qué hizo dev1 en "error" antes de que lo elimine, pero en caso de que desee hacer algunos de mis propios cambios en él, NO debería poder hacerlo, en su lugar debería tener que hacer una request de extracción para esa twig determinada, y dev1 debería aceptar manualmente mis cambios. No debería forzar su mano en esto.

TL; DR

Use git flow .

Eliminará las preguntas y automatizará algunas de las cosas que pregunta. Cuando esté familiarizado con el flujo y la ramificación de git, etc., puede elegir hacer las cosas de manera diferente, o manualmente.

Los cambios se reflejarán también en mi máquina doméstica

En su imac push / pull para no dominar y en su máquina doméstica, presione / tire desde not-master.

Donde "no maestro" es la twig en la que está trabajando actualmente.

Por twigs dev

Depende de usted, su flujo de trabajo necesita ayudar no obstaculizar el desarrollo. Por ejemplo, ¿qué pasa si dos desarrolladores queueboran en la misma tarea? ¿Desea forzarlos a trabajar en diferentes twigs? Las twigs de características probablemente tengan más sentido, sin embargo, no hay nada de malo en tener twigs de usuario.

Rama de producción separada

Independientemente de cómo lo haga, su aplicación en vivo debería extraer de una label / twig estable conocida , y normalmente no se envía directamente a la maestra , porque romper las cosas es parte del desarrollo, pero romper el código que su aplicación en vivo extraerá es algo que absolutamente quiero evitar Debería poder instalar su installation en vivo sin ninguna duda, en cualquier momento, de que podría estar sacando un código dañado. Si está utilizando un server de continuous integration , puede automatizar fácilmente la fusión de su twig de desarrollo a la maestra si todas las testings se atestingn e incluso se implementan automáticamente.

Cuando se termina una twig con

Todas las dudas sobre el flujo de trabajo son lo mismo. cuando termina una twig, la fusiona con su twig principal.

es decir

 $ git branch working-on-this master $ git add ... $ git commit ... $ # rinse and repeat $ git push --set-upstream $REMOTE working-on-this 

Y cuando llegue el momento:

 $ git checkout master $ git pull $ git merge working-on-this $ git push $ git branch -d working-on-this $ git push $REMOTE :working-on-this 

No elimina explícitamente todas las twigs en otras máquinas; sin embargo, cualquiera en cualquier momento puede ejecutar:

 $ git branch --merged master 

que si se termina una twig se verá así:

 $ git branch --merged master master working-on-this $ git branch -d working-on-this 

Lo que indica que working-on-this se puede eliminar de forma segura. En cualquier caso, git branch -d activa una advertencia y se cancela si intentas eliminar una twig que no está fusionada con la twig en la que estás cuando ejecutas el command.

Si encuentra que tiene múltiples twigs remotas que se piensa que ya se terminaron, puede limpiarlas con un solo command:

 $ git remote prune -n origin 

El -n significa que solo informará qué twigs va a eliminar. Elimine ese indicador para eliminar realmente las sucursales remotas obsoletas.

Si tiene varios desarrolladores trabajando en la misma twig (queueboración) la comunicación es key , no confíe en un flujo de trabajo, hable activamente de eliminar cosas antes de dejar que uno de su equipo trabaje en una (supuestamente) sucursal terminada.

Restricción de permissions de confirmación de sucursal

Sí, puedes hacer eso, ¿pero realmente quieres hacerlo? Será mejor que utilices la comunicación y las convenciones.

Algunas sugerencias:

  • cualquiera puede crear una twig remota
  • nadie se compromete / se fusiona para dominar (solo el desarrollador principal lo hace)
  • nadie borra una twig remota (solo el desarrollador principal lo hace)
  • nadie corta el server remoto (solo el desarrollador principal lo hace)

Cualquiera puede en cualquier momento hacer cualquiera de los pasos anteriores, pero asumiendo que confías en tu equipo como un todo, no hay ninguna razón para restringir realmente a los desarrolladores para evitar que lo hagan; probablemente habrá momentos en los que necesitarán romper filas y reglas. prevenir eso mientras que una convención no lo hace.

Quiero ser capaz de desarrollar y comprometerme ..

Sí, esto se logra mediante la bifurcación. Inicialmente empuja hacia arriba su twig completa desde su estación de trabajo a "local" y luego puede verificar una twig de rastreo en su casa si desea continuar trabajando allí.

Quiero que cada desarrollador sea …

Recomiendo sucursales de características en lugar de twigs de desarrolladores. Tiene más sentido cuando varios desarrolladores queueboran en una function.

Cuando el trabajo en una característica esté completo, ¿es aconsejable?

Esta es una cuestión de gusto. Generalmente creamos una twig de lanzamiento primero (creo que muchos lo hacen), así que tenemos una brecha entre las cosas reales y las cosas que necesitan ser probadas, cuando la twig de lanzamiento se considera estable fusionamos esa twig en maestro y luego puede ir en vivo

No creo que haya mejores prácticas. Depende de lo que está haciendo, es decir, qué tipo de cosas está desarrollando. Si quieres mantener tu flujo de trabajo, git te permitirá hacerlo. En lugar de "svn update", haces "git pull".

Puede introducir convenciones de nombres para sus sucursales y dejar que todos vivan felices en el local . Por ejemplo:

En el trabajo:

 work$ git branch -a master * user1/my-work remote/local/master remote/local/user1/my-work work$ git push local user1/my-work 

y en casa:

 home$ git branch -a master * user1/my-work remote/local/master remote/local/user1/my-work home$ git pull local user1/my-work 

A cada usuario se le asigna un prefijo para sus sucursales, por lo que local puede servir como server de almacenamiento central.