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

Soy el nuevo desarrollador, esta es mi primera posición de programación.

Mi problema es este: Usamos: gitcorté una rama de nuestra developrama, luego comencé a trabajar en la tarea menor que me asignaron. Es muy lento porque no tengo experiencia. Para el momento en que estoy listo para fusionar mi sucursal con developlas demás, he realizado tantos cambios que resolver los conflictos es abrumador (en realidad parece más fácil desechar mi trabajo y comenzar de nuevo la tarea, lo que por supuesto no es una solución sostenible )

¿Cómo supero esto? ¿Hay alguna táctica que pueda usar que no sea 'ser mejor codificando'? Tengo la intención de hablar de esto con mi supervisor la próxima semana.

Obtiene conflictos de fusión si los cambios que realizó en su rama están cerca de los cambios que sus colegas hicieron en la developrama mientras tanto, si usted y sus colegas cambiaron las mismas líneas de código o líneas adyacentes en el mismo archivo.

Por lo tanto, para reducir la probabilidad de conflictos de fusión, puede intentar fusionarse 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 usted mismo, asegúrese de hacer solo cambios relacionados con su tarea.

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

También hay algunos comandos de Git que pueden ayudarlo a cambiar la menor cantidad de líneas posible:

• git diffy git diff --stagedpara ver qué líneas ha cambiado.
• git add -p para agregar solo algunos de sus cambios en un archivo.
• git commit --amendy git rebase -ipara modificar los compromisos que ya realizó en su rama de características locales antes de enviarlos a otros repositorios de Git.

(Cambiando el menor número posible de líneas también puede hacer que sea más fácil para revisar su trabajo o de usar herramientas que funcionan en las diferencias entre los compromete como git cherry-pick, git rebase, git bisect, y git blame.)

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

Supongo que estás usando git. Si es así, utilice git rebase -i(los -imedios interactivos). Conviértalo en una tarea diaria (incluso con mayor frecuencia, si es necesario) para volver a armar su rama contra la rama desarrollada. Esto trae los cambios de forma incremental todos los días (al menos) para mantener su rama de características actualizada. Si hay conflictos durante su rebase diario, debe hablar con su equipo sobre quién está trabajando en qué.

Si lo ejecuta a diario, probablemente no necesitará la parte interactiva. Solo deja que haga lo suyo.

Soy un desarrollador bastante experimentado, y todavía me lleva bastante tiempo 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 nuevo proyecto que está evolucionando rápidamente. En cualquier caso, no se preocupe si le toma varios meses ingresar al flujo. Si cambio de proyecto durante 2 o 3 semanas y luego vuelvo a cambiar, ¡me puede tomar unas horas (o incluso un día o dos) volver completamente 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.

EDITAR:

O usar merge. Esa también es una opción. Entonces, lo anterior sería: "hacer uso de git rebase -i(los -imedios interactivos) o git merge". En cuanto a cuál usar, hable con el resto de su equipo. Pueden (o no) tener fuertes preferencias de cualquier manera. Está claro que algunas personas no tienen fuertes preferencias.

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

Creo que las respuestas aceptadas son más 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 herramientas.

Si se encuentra con muchos conflictos de fusión, significa que usted y alguien más en el equipo se pisan 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 hacia un alto grado de propiedad de la tarea.
Por lo general, tomaré la propiedad total y completa de dos o tres archivos a la vez y trabajaré en ellos en una sucursal durante un día o dos como máximo.
Por lo general, si alguien más toca esos archivos, solo si es absolutamente necesario para sus propias tareas, generalmente no trabajamos juntos en el mismo bloque de tareas.

Si descubres que tienes que fusionar mucho, entonces el código de todos tus equipos está en un solo lugar (lo cual es algo que debes evitar en sí mismo) o todas tus tareas.

Dicho todo esto, como nuevo desarrollador probablemente no esté en condiciones de hacer cumplir, solicitar o incluso sugerir realmente algún tipo de reestructuración.
Lo que esperaría es que sus tareas hayan sido asignadas como cosas de "aprender las cuerdas" que deberían ser razonablemente accesibles a su nivel de habilidad para facilitar su ingreso al equipo. Probablemente han sido eliminados de las tareas de un compañero de trabajo que todavía está trabajando en la misma área, de ahí sus conflictos de fusión.
Entonces, la solución a esto es desconectarse, resolver los problemas, lidiar con los conflictos de fusión lo mejor que pueda y no preocuparse demasiado, siempre que esté haciendo lo mejor posible, le corresponde a su gerente preocuparse por su progreso.
Te volverás más rápido y más seguro a medida que avanzas,

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

Fúndete con la rama de desarrollo cada vez que cambie, para que siempre estés cerca de ella y nunca tengas una gran cantidad de conflictos.

Si toma mucho tiempo, puede ser porque pasa la mayor parte del tiempo averiguando cuáles son los cambios, y luego una pequeña cantidad de tiempo implementando los cambios. Si ese es el caso, combínelo con la rama de desarrollo antes de comenzar los cambios de código reales.

Hable con sus colegas sobre estrategias para evitar conflictos. Obtiene conflictos si dos personas editan el mismo código. No solo el mismo archivo, sino el mismo código. Entonces, 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 agregamos 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 ningún conflicto.

Si tiene conflictos, obtenga una buena herramienta de diferencias, para que pueda comparar la rama de desarrollo antes de su fusión, su código antes de la fusión, su código original y el código fusionado, y fusionar a mano.

En el peor de los casos: no descarta su trabajo, pero utilice una buena herramienta de diferencias para descubrir exactamente qué cambios realizó, vuelva a ramificarse desde el desarrollo y aplique todos los cambios que realizó manualmente en lugar de volver a escribirlos.

Para cuando esté listo para fusionar mi rama nuevamente en desarrollo (énfasis mío)

Manejar conflictos en a git mergemenudo es más simple que en git rebase. En Git merge puedes ver la lista completa de archivos que se han modificado a la vez. No importa cuántos compromisos hayan realizado otros compañeros de trabajo, tendrá que fusionarse una vez . Con el flujo de trabajo de rebase, puede terminar teniendo los mismos conflictos una y otra vez y tener que revisarlos manualmente. Puedes terminar arreglando el compromiso número 13 y sentir que no puedes ver la luz del túnel .

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

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

• Recursos / archivos de idioma . Si tiene cambios aditivos en un archivo de recursos, asegúrese de moverlos siempre al final del archivo para poder recordar fácilmente sus cambios contra los cambios de los demás . Es posible que pueda copiar y pegar sus cambios en la parte inferior, o simplemente eliminar los marcadores de conflicto
• Hacer. No. ABSOLUTAMENTE. RE-formatear . Ni usted ni sus colegas desarrolladores realizarán un "reformateo 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 volver a formatear el código
  • Incrementalmente, por ejemplo, por cada desarrollador en cada confirmación, tan pronto como usen una herramienta automatizada (por ejemplo, Eclipse tiene una opción para 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 es comido por su IDE. Para que te hagas una idea, si son 4 espacios o 2 pestañas, no importa, pero realmente importa si todos usan lo mismo.
  • Justo antes del lanzamiento, por un líder del equipo. Si se produce una confirmación de "reformateo de código" cuando las personas no están trabajando en sucursales, es decir, antes de que se ramifiquen, las cosas se facilitarán
• Revise el trabajo dividido entre compañeros de trabajo. Esta es la parte donde viene la mayoría de la ingeniería. Como señalan otras respuestas, es un olor de diseño si varios desarrolladores que realizan diferentes tareas tienen que tocar los mismos recursos. Es posible que deba discutir con el líder de su equipo sobre qué parte debe modificar 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 con sus ramas. Personalmente fui testigo de un desarrollador que agregaba entre 10 y 20 confirmaciones etiquetadas como "arreglo", cada una de las cuales confirmaba una o dos líneas. Nuestra política es que los compromisos están etiquetados con tickets JIRA para darle una idea.

@JacobRobbins sugiere hacer git rebaseuna 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 la confirmación de la que se ha ramificado. Cuando digo puñado, podría decir 3 o 4 (por ejemplo, todos los front-end, todos los back-end, todos los parches de la base de datos) o cualquier figura humanamente razonable. Después de haberlos consolidado, use fetchy 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 reformatear y boy scout. He modificado ligeramente el formato RE para resaltar que lo que quiero decir es la tarea de formatear desde cero todo el archivo fuente, incluido el código que no tocó. A diferencia de formatear siempre su propio código, que es perfectamente boy scouty, varios desarrolladores, incluido yo mismo, se utilizan para formatear todo el archivo con las capacidades del IDE. Cuando otros tocan el archivo, incluso si las líneas afectadas no cambian en su contenido y semántica, Git lo verá como un conflicto. Solo un editor con conocimiento del lenguaje muy poderoso puede sugerir que el conflicto solo está relacionado con el formateo y la fusión automática del fragmento mejor formateado. Pero no tengo evidencia de tal herramienta.

Después de todo, la regla de boy scout no te obliga a limpiar el desorden de otras personas. Solo tuyo.

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

En segundo lugar, encuentre a una persona que trabajó en los archivos que causan conflictos. 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 Git UI. Yo uso TortoiseGit. Ayuda en la fusión.

Y para evitar en el futuro,

• Es una muy buena práctica fusionar la rama de desarrollo regularmente con su rama de características.

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

Debe ejecutar regularmente (diariamente) el comando 'git fetch' (no git pull) desde su rama de desarrollo. Esto hará que otras personas cometan cambios y los incorporará a su rama de características sin intentar integrar los cambios en su rama.

Esto es algo sobre lo que debería hablar con el desarrollador principal (no necesariamente su gerente), porque su empresa puede tener sus propios estándares o formas recomendadas de manejar este problema; Es muy común. No espere hasta la próxima semana: descubra el proceso ahora y pregunte si puede realizar algún trabajo trivial (como formatear el código o agregar comentarios) para que pueda 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, no obstante. Tendrá que hacer preguntas al resolver conflictos que son realmente complejos.

Dicho esto, veo muchas respuestas que recomiendan fusionar / rebase para desarrollar regularmente. Estaría mucho menos entusiasmado con 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 rama con regularidad con el desarrollo, invariablemente terminará teniendo que resolver conflictos mientras está a punto de implementar su función. Y eso significa que será mucho más difícil tratar de descubrir lo que se supone que debe hacer el código, ya que no había terminado con él. Antes de intentar fusionarse, asegúrese de que su rama sea una unidad coherente de cambio. Aun mejor,

Traté de no entrar en los méritos de rebase sobre merge, que probablemente sea otra pregunta. En este contexto, las herramientas realmente no importan.

Para cuando estoy listo para fusionar mi rama nuevamente en el desarrollo, los otros han hecho tantos cambios que resolver los conflictos es abrumador

¡Esto suena como un escenario ideal para la programación de pares !

Más información sobre los beneficios y enfoques básicos:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Naturalmente, acelerará con el tiempo trabajando 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 al estar en un ambiente estresante siempre presionados para ponerse al día, otros que no aprenden bien bajo presión constante se verán obstaculizados.

En lugar de trabajar en una rama por su cuenta y tratar de mantenerse al día con otros desarrolladores que obviamente son mucho más rápidos que usted, en su lugar, trabajaría directamente (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 en su proyecto, ya que la programación de pares no siempre tiene sentido para algunos proyectos, aunque posiblemente siempre tenga sentido para el aprendizaje, incluso si solo se sienta y mira a alguien más experimentado que usted. (siempre y cuando sean buenos desarrolladores, la experiencia no significa necesariamente que usen buenas prácticas).

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

• Es probable que reduzca los conflictos de fusión, ya que trabajar con alguien más experimentado aumentará el tiempo de finalización en lugar de trabajar solo
• Como te estarán enseñando, es probable que sean más lentos de lo que estarían trabajando solos, por lo que aún puede haber algunos conflictos de fusión y, por lo tanto, puede resolverlos con alguien experimentado y, por lo tanto, puede obtener algunos consejos sobre cómo ahorrar tiempo, etc.
• Ayudarlo a ver posibles trucos y formas de ser más rápido (aunque ser lento a veces es simplemente una falta de experiencia en lugar de una falta de buenas prácticas)
• Puede hacer preguntas de inmediato 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 comprende el código y el escenario exactos mientras trabaja en él, sin programación de pares tienes que explicar el código y el escenario, que a menudo termina siendo un problema y así que pierdes su tiempo / atención en obtener realmente los consejos tan necesarios
• Conozca el proceso de pensamiento de alguien más experimentado y experimentado, y con una buena comunicación seguramente aprenderá cosas nuevas

¿Hay alguna táctica que pueda usar que no sea 'ser mejor codificando'? Tengo la intención de 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 que usted presente las ventajas de la programación de pares (si lo necesitan, la mayoría de la gente lo sabe y es de conocimiento común por qué ayuda).

Hay algunos problemas subyacentes aquí. Es muy probable que la fusión de sus problemas no sea su culpa y, más comúnmente, es un síntoma de malas prácticas.

1) Idealmente, fusionarías tu rama para desarrollarla todos los días. Intenta tener un código de trabajo al menos una vez al día que pase todas las pruebas para que puedas unirte al desarrollo.

2) Si no tiene código de trabajo en ningún momento durante su día de trabajo habitual, probablemente tenga fragmentos de código demasiado grandes para trabajar. Debe dividir su tarea en tareas más pequeñas que se puedan terminar (idealmente independientemente una de la otra) más rápido para que pueda fusionarse.

3) Sus archivos de proyectos son probablemente demasiado grandes. Si hay muchos conflictos de fusión para un archivo, hay demasiadas personas trabajando en un archivo. Idealmente, algo en lo que una persona está trabajando debe 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 descartar una función completa y comenzar de nuevo, es probable que haya demasiadas personas que comprometen el código en el mismo repositorio.

5) Es posible que no tenga estándares de formato de código consistentes. 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 su git, estos podrían incluso reducirse a conflictos de espacios en blanco (terminaciones de línea, sangría, tabulaciones vs espacios).

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

Esto es lo que puede hacer: 1) Si no puede fusionarse en desarrollo todos los días, combine / rebase desarrolle en su rama todos los días (o con más frecuencia).
2) Intenta separar tu 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 del código (archivos más pequeños, funciones más pequeñas).

En realidad, parece más fácil descartar 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 soluciono un error o hago un cambio en el sistema, estoy aprendiendo cómo hacerlo. La próxima vez que solucione el mismo error, solo tomará el 1% del tiempo ya que ahora entiendo el problema.

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

Por lo tanto, no hay nada de malo en crear una nueva rama del 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 forma de dividir su cambio en partes lógicas y correctas, cada una de las cuales se fusionará en la rama maestra una vez completada. Por ejemplo, las pruebas unitarias y los cambios en el código de back-end se pueden hacer y fusionar. Luego, en una operación separada, puede hacer los cambios en la interfaz de usuario que los utiliza, por lo tanto, tiene menos riesgo de que otra persona edite el mismo archivo de interfaz de usuario.

Si no desea fusionar la rama de desarrollo en su rama con demasiada frecuencia, puede obtener un flujo de trabajo que se parezca más a svn mediante el uso git pull --rebase. Esto extraerá las nuevas confirmaciones y rebajará sus confirmaciones en ellas. Esto significa que cuando fusiona 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 git pull --rebase.

Pero cuanto más compromisos realice antes de fusionar su rama para desarrollarla o desarrollarla en su rama, más complicada será la próxima rebase y subvertirá un poco el sentido de las ramas de características, ya que su rama solo existe mientras no esté fusionada. .

Cuando trabajas en archivos comunes, de cualquier manera, tú o tus compañeros de equipo deben resolver todos los conflictos antes de fusionar los acabados, por lo tanto, en primer lugar, no se molesten . Todavía está trabajando en proyectos y está orgulloso de su trabajo. Ahora, para hacer un movimiento más inteligente, puede seguir algunas sugerencias a continuación.

1. Divide las tareas de forma independiente:

   Antes de comenzar su trabajo, planifique y divida tareas completas de tal manera que la tarea asignada para cada miembro del equipo sea lo más independiente y modular posible (para evitar posibles conflictos durante el desarrollo). Puede acercarse a su líder de scrum para que le asigne algunas tareas independientes como novato.

2. Fusionar confirmaciones frecuentes granulares:

   No espere a que se complete la tarea completa antes de la unión final. Por supuesto, cualquier tarea más grande se puede dividir en múltiples subtareas. Por lo tanto, un mejor enfoque es fusionar confirmaciones más pequeñas para subtareas más pequeñas al mismo tiempo con frecuencia para evitar la resolución de conflictos voluminosos.

3. Rebase su sucursal con frecuencia:

   Realice una práctica de rebase frecuente a su sucursal local con una remota. Puede usar el siguiente comando para cambiar la frecuencia de su sucursal local con una remota,

   git pull --rebase #or
   git pull --rebase origin dev #when dev is remote branch
   

   Ese es hasta ahora el comando git más útil para mí en mi vida de desarrollo.

4. Trabajar en estrecha colaboración con los compañeros de equipo:

   Si realmente necesita trabajar en paralelo con su compañero de equipo en una tarea común, trabaje en colaboración. Puede esperar un momento para evitar la resolución de conflictos complejos para su conveniencia, ya que usted es un novato y es una experta.

5. Acostúmbrate con las opciones de git:

   Utiliza el poder de las herramientas de fusión de git. Hay muchas maneras convenientes de resolver conflictos mientras se fusionan. Las estrategias de fusión a veces pueden ayudar mucho. Acostúmbrate e intrépido con los comandos git.