El nuevo desarrollador no puede mantenerse al día con las fusiones de sucursales

Supongo que estás usando git. Si es así, utilice git rebase -i (el -i significa interactivo). Conviértalo en una tarea diaria (incluso con más frecuencia, si es necesario) para volver a clasificar su rama contra la rama de desarrollo. Esto trae los cambios incrementalmente cada día (al menos) para mantener su rama de características actualizada. Si hay conflictos durante su rebase diaria, necesita hablar con su equipo sobre quién está trabajando en qué.

Si lo ejecuta diariamente, probablemente no necesitará la parte interactiva. Solo deja que haga su trabajo.

Soy un desarrollador bastante experimentado, y todavía me toma bastante tiempo para ponerme al día en un nuevo proyecto. En su caso, parece que hay varias personas trabajando en el mismo proyecto simultáneamente, por lo que es un proyecto muy grande o un proyecto nuevo que está evolucionando rápidamente. En cualquier caso, no se preocupe si le toma varios meses entrar en el flujo. Si cambio los proyectos durante 2 o 3 semanas y luego vuelvo, me puede llevar algunas horas (o incluso un día o dos) para "volver a" un proyecto que escribí 100% por mi cuenta.

En resumen, no te preocupes por ser lento en este momento. La forma de mejorar es seguir practicando. No tenga miedo de preguntar a otros desarrolladores sobre aspectos de los proyectos que no comprende.

Esto podría ser un signo de mala ingeniería de software por parte de la empresa. Demasiadas interdependencias, diferentes problemas con características superpuestas, intentar abordar problemas en el orden incorrecto, etc. pueden causar la situación que está describiendo. Sugiero que regularmente fusione develop en su sucursal durante el desarrollo

Las respuestas aceptadas creo que son más bien una naturaleza técnica de "cómo usar Git mejor", creo que esto es más un problema de equipo que un problema de ingeniería o de herramientas.

Si te encuentras con muchos conflictos de combinación, significa que tú y alguien más en el equipo están pisando los otros dedos de los pies.
Usted o ellos deben tratar de desarrollar un espacio personal mientras codifican y evitar trabajar en áreas que ya están ocupadas.

En mi equipo, tendemos a un alto grado de propiedad de tareas.
Por lo general, asumo la propiedad completa de dos o tres archivos a la vez y los trabajo en una sucursal por un día o dos como máximo.
Por lo general, si alguien más toca esos archivos, solo es absolutamente necesario para sus propias tareas, ¡por lo general, no trabajamos juntos en el mismo bloque de tareas!

Si se da cuenta de que tiene que fusionar mucho, el código de todos sus equipos está en un lugar (lo que es algo que debe evitar) o todas sus tareas.

Todo lo dicho, como nuevo desarrollador, es probable que no esté en condiciones de hacer cumplir, solicitar o incluso sugerir algún tipo de reestructuración.
Lo que yo esperaría es que tus tareas hayan sido asignadas como "aprende las cuerdas" cosas que deberían ser razonablemente accesibles a tu nivel de habilidad para facilitarte el ingreso al equipo. Probablemente hayan sido eliminados de las tareas de un compañero de trabajo que aún está trabajando en la misma área, por lo tanto, sus conflictos de fusión.
Entonces, la solución para esto es taparlo, resolver los problemas, lidiar con los conflictos de fusión lo mejor que pueda y no preocuparse demasiado, siempre que esté haciendo todo lo posible para que su gerente se preocupe. tu progreso.
Conseguirá más velocidad y confianza a medida que avanza, y sus compañeros de trabajo le darán más autonomía y, como consecuencia, se pondrán en su camino menos.

Lo más importante de la fusión es que cuanto más espere, más doloroso se volverá. Y el problema crece más que lineal. Tres veces más conflictos son nueve veces más trabajo. Hay algunas estrategias:

Combine con la rama de desarrollo siempre que cambie, para que siempre esté cerca de ella y nunca tenga una gran cantidad de conflictos.

Si tarda mucho tiempo, entonces puede ser porque pasa la mayor parte del tiempo averiguando cuáles son los cambios y luego un poco de tiempo implementando los cambios. Si ese es el caso, fusione con la rama de desarrollo antes de iniciar los cambios de código reales.

Hable con sus colegas sobre estrategias para evitar conflictos. Obtienes conflictos si dos personas editan el mismo código. No solo el mismo archivo, sino el mismo código. Así que necesito una nueva función functionA y usted necesita una nueva función functionB, y ambos la agregamos al final del mismo archivo, tenemos un conflicto. Si lo añadimos en diferentes lugares, no hay conflicto. Si ambos lo agregamos en un lugar en el archivo al que pertenece lógicamente, es probable que no tengamos conflicto.

Si tiene conflictos, obtenga una buena herramienta de diferencias, de modo que pueda comparar la rama de desarrollo antes de su combinación, su código antes de la combinación, su código original y el código combinado, y fusionar con mano.

El peor de los casos: no desperdicia su trabajo, sino que usa una buena herramienta de diferencias para averiguar exactamente qué cambios realizó, se ramifica de nuevo desde el desarrollo y aplica todos los cambios realizados manualmente en lugar de volver a escribirlos.

  

Cuando esté listo para fusionar mi sucursal volverá a desarrollarse (énfasis mío)

Los conflictos de manejo en git merge son a menudo más simples que en git rebase . En Git merge puedes ver la lista completa de archivos que se han modificado a la vez. No importa cuántas confirmaciones hayan realizado otros compañeros de trabajo, tendrá que fusionar una vez . Con el flujo de trabajo de rebase, puede terminar teniendo los mismos conflictos una y otra vez y tendrá que revisarlos manualmente. Puedes terminar arreglando el 13º compromiso y sentir que no puedes ver la luz saliendo del túnel .

Según mi experiencia, cuando intenté resolver ingenuamente los conflictos de rebase repetidos terminé perdiendo las modificaciones de alguien o con una aplicación que ni siquiera compilaba. A menudo, yo y mis compañeros de trabajo trabajamos mucho, pero nos sentimos tan abrumados por la complejidad de los conflictos repetidos que tuvimos que abortar y perder nuestro trabajo anterior después de un puñado de confirmaciones de rebase.

Le sugeriré algunas técnicas, pero solo pueden ayudar a que la fusión sea más fácil que automatizar la tarea.

• Archivos de recursos / idioma . Si tiene cambios aditivos en un archivo de recursos, asegúrese de moverlos siempre al final del archivo para poder recordar fácilmente los cambios contra otros cambios. Es posible que pueda copiar y pegar los cambios en la parte inferior, o simplemente eliminar los marcadores de conflicto
• Hacer. No. ABSOLUTAMENTE. Re-formatear . Ni usted ni sus compañeros desarrolladores deberán realizar un "cambio de formato de código masivo" durante el trabajo diario. El reformateo de código agrega un número excesivo de falsos positivos en la gestión de conflictos. Se puede reformatear el código.
  • de forma incremental, por ejemplo, por cada desarrollador en cada confirmación, tan pronto como utilizan una herramienta automatizada (por ejemplo, Eclipse tiene una opción para volver a formatear al guardar, Vanilla Visual Studio no tiene ninguna). Absolutamente todos los desarrolladores deben usar los mismos estándares de formato de código, codificados en un archivo de formato que se come por su IDE. Para darte una idea, si son 4 espacios o 2 pestañas no importa, pero realmente importa si todos usan el mismo.
  • Justo antes del lanzamiento, por un líder de equipo. Si se produce una confirmación de "cambio de formato de código" cuando las personas no están trabajando en las sucursales, es decir, antes de que se ramifiquen, las cosas se harán más fáciles
• Revisar el trabajo que se divide entre compañeros de trabajo. Esta es la parte donde viene la mayoría de la ingeniería. Como señalan otras respuestas, es olor a diseño si varios desarrolladores que realizan diferentes tareas tienen que tocar los mismos recursos. Es posible que tenga que discutir con el líder de su equipo qué parte debe ser modificada por cada desarrollador concurrente.

También he visto algunos malos hábitos en los flujos de trabajo de Git en mis equipos. A menudo las personas se comprometen demasiado a sus ramas. Personalmente, fui testigo de que un desarrollador agregaba de 10 a 20 confirmaciones etiquetadas como "corregir", cada una de las cuales cometía una o dos líneas. Nuestra política es que las confirmaciones estén etiquetadas con boletos JIRA para darle una idea.

@JacobRobbins sugiere hacer de git rebase una tarea diaria. Me gustaría impulsar su enfoque hacia adelante.

Primero, use rebase una vez solo para reducir el número de confirmaciones a un puñado. Y rebase solo en la rama de desarrollo original , que es el compromiso desde el que se ha ramificado. Cuando digo unos cuantos, podría significar 3 o 4 (por ejemplo, todos los front-end, todos los back-end, todos los parches de la base de datos) o cualquier cifra humanamente razonable. Una vez que los haya consolidado, use fetch y trabaje su rebase en la rama ascendente. Esto no lo salvará de conflictos a menos que su equipo revise su propio enfoque, pero hará que su vida sea menos dolorosa.

Si tiene preguntas adicionales sobre las tareas específicas, no dude en buscar y preguntar en Stackoverflow.

[Editar] sobre la regla de no reformateo y boy scout. He reformulado ligeramente RE-format para resaltar que lo que quiero decir es la tarea de formatear desde cero todo el archivo fuente, incluido el código que no ha sido tocado por usted. Al contrario de formatear siempre su propio código, que es perfectamente boy scouty, varios desarrolladores, incluido yo mismo, se utilizan para reformatear todo el archivo con las capacidades del IDE. Cuando el archivo es tocado por otros, incluso si las líneas afectadas no se modifican en su contenido y semántica, Git lo verá como un conflicto. Solo un editor muy poderoso que tenga en cuenta el idioma puede sugerir que el conflicto solo está relacionado con el formateo y la fusión automática del fragmento con el mejor formato. Pero no tengo pruebas de ninguna herramienta de este tipo.

Después de todo, la regla de los boy scouts no te obliga a limpiar el desorden de otras personas. Sólo tuyo.

Obtendrá conflictos de combinación si los cambios que hizo en su sucursal están cerca de los cambios que hicieron sus colegas en la rama develop mientras tanto, es decir, si usted y sus colegas cambiaron las mismas líneas de código o líneas adyacentes en el mismo archivo.

Para reducir la probabilidad de conflictos de combinación, puede intentar fusionar antes para que sus colegas cambien menos líneas mientras tanto, o puede intentar cambiar menos líneas usted mismo.

Para cambiar menos líneas, asegúrese de hacer solo los cambios relacionados con su tarea.

Si necesita experimentar con diferentes maneras de lograr su objetivo, ¿tal vez algunos de sus experimentos cambiaron líneas que realmente no necesitan cambiarse? Deshaga estos cambios antes de fusionar.

También hay algunos comandos de Git que pueden ayudarte a cambiar el menor número de líneas posible:

• git diff y git diff --staged para ver qué líneas ha cambiado.
• git add -p para agregar solo algunos de sus cambios en un archivo.
• git commit --amend y git rebase -i para modificar las confirmaciones que ya realizó en su rama de características local antes de enviarlas a otros repositorios de Git.

(Cambiar la menor cantidad de líneas posible también puede facilitar la revisión de su trabajo o el uso de herramientas que funcionan en las diferencias entre confirmaciones, como git cherry-pick , git rebase , git bisect y git blame ).

Pero incluso si reduce la probabilidad de conflictos de combinación, a veces se encontrará con conflictos de combinación. Así que no les tengas miedo, aprende a resolver los conflictos.

Primero, no pienses en descartar tus cambios. Perderá oportunidades para aprender el proceso de fusión.

En segundo lugar, encuentre a una persona que haya trabajado en los archivos causando conflicto. Puedes ver la historia. Hable con la persona y resuelva los conflictos en esos archivos. Haz lo mismo para otros conflictos.

Si hay demasiados conflictos, su tarea puede ser menor, pero repetitiva. Intenta encontrar un patrón. Esto ayudaría a resolver conflictos mediante las herramientas de cliente de la interfaz de usuario de Git. Yo uso TortoiseGit. Ayuda a fusionar.

Y para evitar en el futuro,

• Es una muy buena práctica combinar la rama de desarrollo regularmente con la rama de tu función.

• Si tiene CI habilitado, vea si la herramienta CI proporciona una compilación de rama. Esto debería basarse en cada comprobación que realice en su rama de características, pero después de la rama de desarrollo de mezcla.

Debe ejecutar regularmente (diariamente) el comando 'git fetch' (no git pull) desde su rama de desarrollo. Esto hará que los demás usuarios se comprometan a realizar cambios y los incorporen a su rama de funciones sin intentar integrar los cambios en su rama.

Esto es algo sobre lo que debe hablar con el desarrollador principal (no necesariamente con su gerente), ya que su compañía puede tener sus propios estándares o formas recomendadas de manejar este problema; es muy comun No espere hasta la próxima semana; averigüe el proceso ahora y pregunte si puede realizar algún trabajo trivial (como el formato de código o agregar comentarios) para poder probar el proceso.

Obviamente, lo primero es evitar que varias personas trabajen en los mismos archivos en primer lugar, al menos de una manera que genere conflictos difíciles. Agregar cosas a las enumeraciones no es un problema siempre que se use un buen formato de código. Cambiar el flujo de control de diferentes maneras y mover el código es mucho más complicado. A veces esto es inevitable, sin embargo. Deberá hacer preguntas cuando resuelva conflictos que son realmente complejos.

Dicho esto, veo muchas respuestas que recomiendan fusionar / reagrupar en desarrollar con regularidad. Me encantaría mucho menos recibir ese tipo de consejos. Su objetivo en este punto es hacer que el proceso de resolución de conflictos sea lo más fácil y seguro posible. Una cosa que ayudará enormemente con ese proceso es tener tantas pruebas de regresión disponibles de inmediato, incluidas las nuevas que forman parte de su nueva función. Si sincroniza su sucursal muy regularmente con el desarrollo, invariablemente terminará teniendo que resolver conflictos mientras está casi terminado de implementar su función. Y eso significa que será mucho más difícil tratar de averiguar qué se supone que debe hacer el código, ya que no se hizo con él. Antes de intentar fusionarse, asegúrese de que su rama sea una unidad de cambio coherente. Aún mejor, modifíquelo en un solo compromiso antes de fusionar.

Intenté no entrar en los méritos de la rebase sobre la fusión que probablemente sea para otra pregunta. En este contexto, las herramientas realmente no importan.

  

Cuando esté listo para volver a unir mi rama para desarrollar las otras   han realizado tantos cambios que resolver los conflictos es abrumador

¡Esto parece un escenario ideal para programación de pares !

Más información sobre los beneficios y enfoques básicos:
enlace

Es natural que aumente la velocidad con el tiempo al trabajar solo, pero puede ser desalentador hasta que llegue ese momento, y a veces también es un largo recorrido. Además, si bien las personas pueden aprender rápidamente estando en un ambiente estresante siempre presionado para ponerse al día, otras personas que no aprenden bien bajo una presión constante se verán obstaculizadas.

En lugar de trabajar en una rama por tu cuenta y tratar de mantenerte al día con otros desarrolladores que obviamente son mucho más rápidos que tú, en su lugar, trabajarías directamente (la misma PC) con otro desarrollador. De esta manera, obtendrá consejos instantáneos y probablemente obtendrá consejos sobre cómo acelerar, etc.

Habría descubierto el mejor enfoque para el código particular de su proyecto, ya que la programación en pares no siempre tiene sentido para algunos proyectos, aunque podría decirse que siempre tiene sentido para el aprendizaje, incluso si solo se sienta y observa a alguien más con más experiencia que tú (siempre que sean buenos dev, la experiencia no significa necesariamente que usen buenas prácticas).

Sentarse con un desarrollador más rápido y más experimentado tiene potencial para ayudar al:

• Es probable que reduzca los conflictos de combinación, ya que trabajar con alguien más experimentado aumentará el tiempo de finalización en lugar de trabajar solo.
• Como te enseñarán, es probable que sean más lentos de lo que trabajarían solos, por lo que es posible que aún haya algunos conflictos de fusión y que puedan trabajar con alguien experimentado, por lo que quizás encuentres algunos consejos para ahorrar tiempo. etc
• Ayudarle a ver posibles trucos y maneras de ser más rápidos (aunque ser lento a veces es simplemente una falta de experiencia en lugar de una falta de buenas prácticas)
• Puede hacer preguntas inmediatamente cuando algo no tiene sentido o no está 100% claro
• Trabajar 1: 1 es valioso para aprender porque la persona a la que le pedirías ayuda ya entiende el código y el escenario exactos mientras trabajan en él, sin la programación de pares, tienes que explicar el código y el escenario, que a menudo termina es un problema y, por lo tanto, pierde su tiempo / atención para obtener consejos muy necesarios
• Conozca el proceso de pensamiento de alguien más experimentado y experimentado, y con buenas comunicaciones seguramente aprenderá cosas nuevas

  

¿Hay alguna otra táctica que pueda usar que no sea "ser mejor codificando"? pretendo   para hablar de esto con mi supervisor la próxima semana.

Mi consejo es discutir la programación de pares con los otros desarrolladores y luego acercarse a su supervisor. Si son decentes, apreciarán su iniciativa, que tiene más posibilidades de presentar los profesionales de la programación en pares (si lo necesitan, la mayoría de la gente lo sabe y es de por qué sabe por qué es útil).

Hay algunos problemas subyacentes aquí. Sus problemas de fusión probablemente no sean su culpa y son más comúnmente un síntoma de malas prácticas.

1) Idealmente, fusionarías tu rama en desarrollo todos los días. Trate de tener un código de trabajo al menos una vez al día que pase todas las pruebas para que pueda integrarse en el desarrollo.

2) Si no tiene un código de trabajo en algún momento durante su día de trabajo habitual, es probable que tenga demasiados trozos de código para trabajar. Debe dividir su tarea en tareas más pequeñas que se puedan terminar (lo ideal es que sean independientes entre sí) más rápido para que pueda fusionarse.

3) Es probable que los archivos de tus proyectos sean demasiado grandes. Si hay muchos conflictos de combinación para un archivo, hay demasiadas personas trabajando en un archivo. Idealmente, algo en lo que una persona está trabajando debería estar separado de lo que todos los demás están trabajando.

4) Tu equipo puede ser demasiado grande. Si le resulta más fácil deshacerse de una característica completa y comenzar de nuevo, es probable que haya demasiadas personas que ingresen código en el mismo repositorio.

5) Es posible que no tenga estándares de formato de código coherentes. Si no usa el mismo formato de código de manera consistente, obtendrá muchos conflictos diferentes para el mismo código. Dependiendo de cómo esté configurado tu git, estos incluso podrían reducirse a conflictos de espacios en blanco (finales de línea, sangría, tabulaciones frente a espacios).

6) Las personas podrían estar empujando sus cambios directamente a la rama de desarrollo.

Esto es lo que usted puede hacer: 1) Si no puede fusionarse con el desarrollo todos los días, fusionar / reagrupar se desarrolla en su sucursal todos los días (o con mayor frecuencia).
2) Trate de separar su código del código de todos los demás.
3) Hable con el resto del equipo sobre características más pequeñas, estándares de codificación consistentes y una mejor organización de los códigos (archivos más pequeños, funciones más pequeñas).

  

En realidad parece más fácil desechar mi trabajo y comenzar de nuevo en la tarea,   que por supuesto no es una solución sostenible)

La mayoría de las veces, esto es lo que hago, la primera vez que corrijo un error o realizo un cambio en el sistema, estoy aprendiendo cómo hacerlo. La próxima vez que solucione el mismo error, solo toma el 1% del tiempo, ya que ahora entiendo el problema.

También encuentro que cuando rehago un poco de trabajo, escribo mejor código .....

Por lo tanto, no hay nada de malo en crear una nueva rama desde el maestro, rehacer su trabajo en ella, mientras usa su "rama privada" para recordarle lo que debe hacer.

También es posible que haya descubierto una manera de dividir su cambio en partes lógicas y correctas, cada una de las cuales se fusionará en la rama maestra una vez que se complete. Por ejemplo, las pruebas unitarias y los cambios en el código de fondo se pueden realizar y fusionar. Luego, en una operación separada, puede hacer los cambios en la interfaz de usuario que los utilizan, por lo tanto, tienen menos riesgo de que alguien más edite el mismo archivo de interfaz de usuario.

Si no desea combinar la rama de desarrollo en su rama con demasiada frecuencia, puede obtener un flujo de trabajo que es más parecido a svn utilizando git pull --rebase . Esto tirará de las nuevas confirmaciones y volverá a basar tus confirmaciones en ellas. Esto significa que cuando fusione su rama en desarrollo, será una fusión de avance rápido (como si hubiera agregado todas sus confirmaciones pasadas al mismo tiempo una tras otra) y no tenga ningún conflicto de fusión, porque las resolvió todas durante %código%.

Pero mientras más confirmaciones realice antes de fusionar su rama en desarrollar o desarrollar en su rama, más complicada será la próxima rebase y subvierte un poco el sentido de las ramas de características, ya que su rama solo existe mientras no está fusionado.