¿Cuál debería ser el flujo de trabajo con un repositorio git?

7

Trabajo en varios repositorios de git, aunque en la mayoría no trabajan más de 2 personas. Sobre todo yo y mi jefe. Muy a menudo, cuando trabajamos en paralelo, sucede que "git log" no se ve tan bien debido a las confirmaciones de fusión. Mi jefe siempre se queja de eso. Realmente odio ese hecho porque esto me hace efectivamente serializar mi trabajo. Para evitar estas confusiones de combinación, siempre debo volver a la versión más reciente e ir a la otra oficina para asegurarme de que mi jefe no se olvide de procesar las solicitudes de fusión antes de cometer las cosas él mismo. Peor aún, me dijo que desde una semana más o menos no recibe notificaciones por correo electrónico para la solicitud de combinación, aunque tengo problemas para creerlo.

Aún peor, ahora él mismo fusiona la solicitud de revisión por pares, elevando más el problema. (La mejor parte es que él piensa que siempre me olvido de cambiar de base y actualizar a tiempo ...) En varias ocasiones ya intenté explicarle que hago todo lo que él sugiere, pero él no me cree porque tiene más experiencia. con git, al menos en entornos sin trabajo en equipo.

Trabajo en este lugar desde hace 3 meses, aunque en realidad trabajo en equipo desde hace unas semanas. Realmente deseaba que usáramos svn porque con este flujo de trabajo en git pierdo mucho tiempo y me duele la cabeza. En particular, tenemos aproximadamente 40 reposiciones con módulos que en la mayoría de los casos no superan los 3000 LOC. Entonces, cuando cambie algo de intimidad en Repo A, es posible que tenga que cambiar algo en Repo B. Si estuviera decidiendo, pondría todas esas cosas en una repo, al menos los módulos que pertenecen a un grupo de software.

Por supuesto, como nuevo empleado, no puede criticar demasiado a su jefe o influenciarlo demasiado. Entonces, ¿cuál es la mejor manera de lidiar con este problema?

    
pregunta Joe 02.07.2011 - 09:23

3 respuestas

5

Supongo que con esta respuesta supongo que tanto usted como su jefe trabajan en los mismos repositorios, por lo que tienen que hacer fusiones reales en lugar de avances rápidos.

Si ha vuelto a basar su trabajo en la cabecera de su repositorio compartido, ha hecho todo lo posible por usted para mantener el historial lineal.

Si quiere un historial lineal para sus propios cambios, tiene que seguir el mismo procedimiento que espera que usted haga y volver a introducir sus cambios locales en la cabecera del repositorio compartido.

Tal como está, creo que vive en el pasado y desea una historia lineal, pero es un deseo común con las personas que han sido picadas demasiadas veces por el manejo de sucursales en sistemas VCS más antiguos. Hasta que no pueda convencerlo de lo contrario, tendrá lo peor de ambos mundos, tratando de encajar un flujo de trabajo lineal en un entorno utilizando un DVCS donde se espera que la bifurcación sea la norma.

    
respondido por el Mark Booth 04.07.2011 - 14:12
3

Su jefe parece que ha decidido cómo funcionarán sus cosas y le está diciendo que lo solucione, aunque la forma en que lo quiere no se alinea con la forma en que los sistemas distribuidos fluyen de forma natural. (También tiene algún problema con la microgestión y la confianza de sus empleados, pero de eso no se trata realmente esta pregunta).

Un modelo exitoso de bifurcación de Git
Esta es una descripción bien escrita y detallada de un modelo de bifurcación. Te permite mantener las cosas organizadas y seguir el flujo de cambios. También habla del concepto de tener un origen "centralizado" del que todos puedan empujar y tirar, en lugar de que usted tenga que unirse de todos en su equipo.

Lo que más me gusta de ese artículo es su postura sobre la fusión.

git merge --no-ff myfeature

Detener el avance rápido significa que el hecho de que existió la rama permanece intacto. Luego, cuando vea el gráfico de registro

git log --oneline --graph

verá la rama y los puntos de fusión y seguirá las diferentes rutas incluso cuando varias personas estén trabajando en paralelo.

    
respondido por el unholysampler 04.07.2011 - 16:28
0

Hay varios problemas aquí:

  • Usando git sobre svn.

git es mejor porque está distribuido.
git también se ha convertido en un estándar debido a problemas como este.

  • Relaciones con tu jefe.

Claramente estás en un lugar difícil. En situaciones como esta, los comentarios de "pase por" o "pasillo" no funcionarán. Le recomendaría que solicite una reunión formal con él / ella sobre un tema que le preocupa mucho. Use ese lenguaje "muy preocupado por" en su solicitud de reunión pero NO diga de qué se trata. ¡Esto llamará su atención!

  • Normas de la industria.

Con el desarrollo actual, es muy importante mantenerse actualizado sobre las herramientas y las cosas cambian rápidamente. A diferencia de cuando programé hace 30 años y las herramientas podrían ser estándar durante una década. Consideraría usar esta y otras publicaciones en su reunión con su jefe ... aunque esta pregunta y sus respuestas probablemente las molesten debido a las críticas. Así que tal vez otras preguntas sobre el mismo tema.

Nota final:
Mi último jefe usó svn y cuando intenté hablar sobre cómo git era mejor obtuve el snarky "svn es un sistema perfectamente bueno, lo he estado usando durante un año, no es como si hubiera caído por el camino". La verdad salió a la luz cuando alguien, bueno, era yo, arruinó un código. Luego tuvo un tiempo difícil con Hellavu para retroceder. Bastante irónico, dado que este es un punto muy importante de un sistema de control de versiones. Así que básicamente svn funcionó bien ... hasta que realmente necesitamos características clave. Probablemente debería haber sabido esto dado que no había estado en grupos de usuarios en 3 años, no tenía una buena cuenta de SO, etc. Dadas sus descripciones, también puliría ese currículum y me aseguraría de que esté en contacto con el mercado. ¡Las personas con las que quieres para trabajar estarán felices de que estés usando git!

    
respondido por el junky 05.03.2012 - 17:04

Lea otras preguntas en las etiquetas