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

223

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.

git software branching merging margarita
fuente
165
no necesita fusionar su rama para que se desarrolle solo cuando haya terminado. puede fusionar el desarrollo en su rama de características de forma incremental cuando lo desee, para hacer la fusión final más pequeña.
DavidB
16
Asegúrese de estar haciendo el proceso de fusión correctamente. Solo sus archivos deberían verse afectados y solo sus cambios deberían aplicarse a la rama de desarrollo. Si obtiene conflictos aleatorios, es probable que haya realizado la fusión de manera incorrecta o que otros estén estropeando el orden de revisión. Es una buena oportunidad para educarse a sí mismo y posiblemente a otros para fusionarse correctamente. Algunas personas tienen dificultades para comprender sus cambios, no los archivos que se están fusionando. Por lo tanto, las revisiones que se ordenen fuera de sincronización causarían conflictos en los archivos que nunca tocó.
16
También asegúrese de que su editor esté configurado correctamente. A veces, los editores "arreglan" pestañas y espacios, de modo que cuando edita un archivo e intenta confirmarlo, cambia todo el archivo. Debes asegurarte antes de confirmar que solo tus cambios se están confirmando en la rama y corregir tu editor.
32
Aquí hay una cosa extraña: "Empiezo a trabajar en la tarea menor" y toneladas de conflictos de fusión normalmente no coinciden. Acabo de fusionar una rama de actualización importante de 2 semanas en un desarrollo experimental y tuvimos 10 (!) Conflictos que no se podían resolver automáticamente. No obtendrá toneladas de conflictos a menos que su tarea sea "cambiar los nombres de las variables en todos los archivos". No para tareas menores.
TomTom
50
Obligatorio xkcd: xkcd.com/1597
ED

Respuestas:

5

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.

Toxaris
fuente
1
También antes de la fusión, una git fetchy git diff origin/develople mostrará una vista previa de la combinación de (más o menos). Te da la oportunidad de limpiar tus cambios antes de que obtengas un montón de conflictos sin sentido.
Max
287

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.

Jacob Robbins
fuente
22
Supongo que esta es la respuesta correcta, pero, en mi opinión, es solo otro ejemplo de mal diseño y terminología de Git. Justo lo que estás "rebase"? ¿No debería llamarse "actualización" o "pago" o "fusión" o algo así? (Una respuesta a continuación argumenta a favor de "buscar") ¿Cuál es el punto de control del código fuente si todos los días se ve obligado a actualizar?
user949300
95
Sin embargo, no se está actualizando o revisando. Está tomando lo que esté exclusivamente en su rama y agregando sus cambios como si ahora los hubiera hecho en la otra rama. Es decir, sus cambios ahora están "basados ​​en" la otra rama. Además, no existe ningún sistema de control de fuente mágico que conozca su código y pueda saber cómo combinar cambios cuando varias personas modifican los mismos archivos. Actualiza todos los días para mantener los conflictos pequeños y manejables, y los cambios frescos en la mente de todos para que sepan cómo manejarlos.
Vectorjohn
54
@ user949300 el rebase es distinto de la fusión, es mucho más matizado y requiere una mejor comprensión de Git que un simple flujo de trabajo de fusión. Es por eso que nunca recomiendo un flujo de trabajo que implique un cambio de nombre a un novato de Git, porque lleva a suponer que el rebase es la única / predeterminada forma de actualizar una rama y genera muchas dificultades y dolores innecesarios. En este caso, la fusión resolverá el problema de la misma manera y tampoco resolverá el problema de los conflictos de fusión en dos ramas de características paralelas de larga duración.
Ant P
14
@ user949300, git pullque es solo una combinación de git fetchy git merge(o puede agregar --rebasepara hacer una nueva versión en lugar de una fusión). Suponiendo que solo tiene un día de retraso, entonces, en una LAN, esto probablemente se completará en menos de un segundo, podría tomar un par de segundos en Internet. Incluso a través de Internet y con pequeños conflictos de fusión, normalmente puede actualizarse y fusionarse limpiamente en menos de un minuto. Dedicar cinco minutos a lo largo de la semana es mucho mejor que pasar una hora al final de la semana lidiando con un conflicto de fusión retorcido.
Derek Elkins
66
Ningún voto de mi parte porque esta respuesta está completamente centrada en el rebase. Rebasar puede ser una herramienta útil, pero nunca debe usarse sin pensar. Para la actualización del día a día, es mejor fusionarse. ¿Por qué? Porque cada rebase es una mentira . Estás contando la historia de una manera que nunca sucedió. Esto puede atornillar totalmente poderosas herramientas como git bisect: Es posible que las cosas rebaseadas ni siquiera se compilen, por lo que no git bisecttiene valor en los commits rotos resultantes. @maaartinus: Yo, por mi parte, prefiero la historia verdadera a la historia lineal. Si cambias de opinión, debes verificar absolutamente cada nuevo compromiso por cordura para evitar mentiras dañinas.
cmaster
131

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

Ivan Anatolievich
fuente
99
Esto está codificando 101 cosas como mencionaste. No necesariamente una reflexión precisa sobre el nuevo empleado.
Señor Positivo
2
@Ivan Anatolievich OP dice que están separados del desarrollo, no del maestro, para tu información
Matthew FitzGerald-Chamberlain
66
Esta respuesta muestra exactamente por qué no me gusta GIT: nuevamente es otra herramienta para que los equipos eviten tener una administración adecuada y una planificación decente. La respuesta a todo es "a quién le importa, siempre puedes usar ese comando más tarde", en lugar de evitar problemas antes de que sucedan.
motoDrizzt
77
mi primer pensamiento también fue una señal de malas prácticas, los desarrolladores no deberían estar trabajando en los mismos archivos en su mayor parte. Si un pequeño proyecto tiene tantos conflictos, ¡todos los demás deben estar resolviendo conflictos todo el día sin hacer ningún trabajo!
Aequitas
14
@motoDrizzt ¿Qué? Nunca he escuchado a nadie hacer ese argumento.
jpmc26
95

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,

Serbal
fuente
44
Creo que has dado en el clavo con el conflicto de los compañeros de trabajo. Los conflictos de fusión son algo habitual, pero generalmente se limitan a un puñado de archivos.
Matthieu M.
10
Esto suena como un corolario de la Ley de Conway y el principio de responsabilidad única , es decir, que si las personas están trabajando en diferentes problemas, idealmente editarán partes separadas del código fuente.
ChrisW
77
Si bien estoy de acuerdo en que un proceso deficiente o un diseño deficiente pueden conducir a una gran cantidad de conflictos, estoy bastante seguro de que el problema es simplemente que el OP no se está fusionando en la línea principal regularmente. No estoy de acuerdo en que "asumir la propiedad completa y completa" de los archivos sea apropiado como algo natural. No quiero que mi equipo tenga una sobrecarga constante de hacer un seguimiento de quién "posee" qué ahora, pedir "permiso" para realizar cambios o adivinar qué archivos deben "reclamar". Solo en raras ocasiones, cuando reescribí significativamente un componente, les pedí a los miembros del equipo que me informaran si iban a cambiar ciertos archivos.
Derek Elkins
1
ChrisW tiene la idea correcta con lo que estaba conduciendo. En general, la propiedad en mi empresa toma la forma de la funcionalidad de la aplicación, tomo la propiedad completa del sistema de filtro de búsqueda como una tarea y, como sucede, nadie más necesita tocar los archivos relacionados en la mayoría de las circunstancias. Creo que es muy probable que OP como un nuevo iniciador haya recibido partes menores de tareas estrechamente relacionadas con un conjunto continuo de tareas por otro desarrollador. Lo que significa que el otro desarrollador está trabajando en la misma parte de la base de código y se están interponiendo en el camino del otro.
Rowan
1
@Rowan Cool, sí, lo pensé. La separación funcional también puede ayudar con la separación de archivos (conjuntos de funciones en diferentes archivos, etc.) y esta IMO ayuda con la fusión.
SaltySub2
28

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.

gnasher729
fuente
Las ramas de características se presentan como otra forma de deuda tecnológica, donde los cambios de transmisión ascendente de la rama matriz es como una refactorización.
Dan Lyons
Salvo que se tiene que pagar esa deuda. Ahora mismo.
gnasher729
15

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.

usr-local-ΕΨΗΕΛΩΝ
fuente
3
Es en gran medida una cuestión de opinión, pero no estoy de acuerdo con que los conflictos de fusión sean más fáciles de manejar que los conflictos de rebase. Cuando reescribe, esencialmente aplica commits uno por uno, manteniendo el alcance de los conflictos de fusión mucho más pequeños y fáciles de seguir (aplica SUS cambios que conoce, no los cambios de otra persona que no conoce). Es posible que tenga que resolver más conflictos de fusión de esta manera (debido a que toca los mismos archivos varias veces en las confirmaciones), pero serán más pequeños y más fáciles de abordar.
user622505
3
Con respecto al formateo, mientras VS no puede hacerlo automáticamente al guardar, si configura "Cuando pego" en "Sangrar y formatear" en "Herramientas" -> "Opciones" -> "Editor de texto" -> "< Su idioma de elección> "->" Formateo ", eso significa que se formatea automáticamente al pegar. Esto permite que la secuencia de tres pulsaciones de teclas: ctrl-A, ctrl-C, ctrl-V tenga el resultado deseado. Dicho eso, +1 para Do. No. ABSOLUTAMENTE. Reformatear. Excepto como se describe en condiciones controladas con mucho cuidado.
dgnuff
1
Los lectores de Bob Martin deben tener en cuenta que la Regla Boy Scout debe aplicarse con moderación si está trabajando en un equipo (si está trabajando solo, tiene mucha más flexibilidad). Si interpreta la regla como "Es mi deber como codificador arreglar literalmente todo en cada archivo que no sea perfecto en el instante en que lo descubra, no importa en qué esté trabajando alguien más", terminará con un Una cantidad gigantesca de conflictos difíciles de resolver, y será un desastre enorme, no importa cuán buenas sean tus intenciones.
jrh
2
Si siente la necesidad de volver a formatear o refactorizar ligeramente el código, hágalo antes o después de su confirmación significativa. No solo reducirá los conflictos, sino que también ayudará al futuro lector de su compromiso, incluidos los revisores
max630
1
Desde mi cultura C #, "volver a formatear" significa la acción de formatear un archivo de código completo o incluso un repositorio completo donde el formato solo está relacionado con la legibilidad . Si su idioma usa espacios en blanco de manera significativa, no debe meterse con espacios en blanco en LOC que no sean suyos. Por el contrario, su idioma de elección aún puede permitir espacios en blanco sin sentido (por ejemplo, antes de una llave) que pueden "formatearse" de acuerdo con un estándar de legibilidad
usr-local-ΕΨΗΕΛΩΝ
5

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.

PKV
fuente
1
Las otras sugerencias para usar Git mejor son buenas, pero hablar con los otros desarrolladores sobre los conflictos de fusión es otro aspecto clave para desarrollar la efectividad de OP.
Dragonel
1
"Puedes ver la historia" ¡Quizás! Depende de cuán aplastado y rebase todo es: P
Carreras de ligereza en órbita
1

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.


fuente
21
No estoy seguro de que esto sea correcto. Git fetch actualizará los controles remotos / origen / maestro, pero luego deberá fusionar los controles remotos / origen / maestro en su rama característica (O controles remotos / origen / desarrollo si ese es el flujo que están usando)
Richard Tingle
Suponiendo que está usando git, también es una buena idea aprender cómo aplastar su compromiso con partes significativas. De esa manera, cuando esté listo para hacer una solicitud de extracción, su confirmación es sencilla y directa y fácil de entender.
@ RichardTingle Correcto, está pensando en una opción de rebase. Simplemente busca y rebabas tu rama con la rama de desarrollo. Eso sincronizará todo.
66
@ Dan, creo que puede ser una cuestión de opinión. Personalmente odio los commits masivos. ¡Prueba git biseccionando eso!
Richard Tingle
2
@PeteCon "y llevarlos a su rama de características sin intentar integrar los cambios en su rama". Eso parece una declaración contradictoria. Creo que te refieres a traerlos a tu repositorio local sin integrarlos en tu rama de características, pero no estoy seguro de cómo eso ayuda ...
Jason Goemaat
1

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.

Kafein
fuente
1

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).

James
fuente
Honestamente, ¿quién votó negativamente :( esto no es una suposición descabellada, esto sucede en mi lugar de trabajo y está demostrado que funciona! Incidentalmente, trabajé duro en otras respuestas en otras preguntas en este sitio para poder tener 10 rep (por encima de mi representante asociado ) sólo para ser capaz de sugerir "la programación en parejas" en éste porque nadie sugirió que trabajé muy duro para responder a esta..
James
1

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).

xyious
fuente
1

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.

Ian
fuente
1

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. .

allo
fuente
1

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.

Sazzad Hissain Khan
fuente