Nuestro equipo de documentación de unas diez personas se mudó recientemente de SVN a Git. En SVN, todos trabajaban en master, un modelo que siempre odié, pero no pude lograr ese cambio. Como parte del cambio a Git, hemos acordado arreglar eso, pero aún no podemos hacerlo (esperando los cambios de compilación que permitirán compilaciones desde ramas arbitrarias). Mientras tanto, todos están trabajando en master. Sí, sé que esto es terrible, créeme.

Estamos viendo muchos más problemas ahora que cuando estábamos usando SVN, algunos de los cuales son causados ​​por el modelo de dos etapas de Git (local y remoto). A veces las personas se comprometen pero no pueden presionar, o tiran y tienen conflictos con sus cambios locales pendientes. Ayer, alguien golpeó los cambios recientes, de alguna manera, con una fusión que salió mal, lo que creo que fue la fusión que Git hace cuando tira y tiene cambios sobresalientes. (No ha podido decirme exactamente lo que hizo, y debido a que está usando una GUI, no puedo simplemente inspeccionar su historial de shell).

Como el usuario de Git más competente (léase: lo he usado antes, aunque no para nada súper complicado), soy la persona que establece la política, enseña las herramientas y limpia los problemas. ¿Qué cambios puedo hacer en la forma en que estamos usando las herramientas para hacer que un maestro compartido y activo sea menos propenso a errores hasta que podamos pasar a desarrollar en las sucursales?

El equipo está utilizando Tortoise Git en Windows. Estamos usando Tortoise Git porque usamos Tortoise SVN antes. ( Yo personalmente uso la línea de comandos bajo Cygwin para algunas operaciones, pero el equipo ha dejado claro que necesita una interfaz gráfica de usuario y vamos con este.) Las respuestas deben trabajar con esta herramienta, no propone reemplazos.

Tortoise Git tiene "Commit & Push" disponible como una sola operación y les he dicho que siempre lo hagan. Sin embargo, no es atómico: puede suceder que el commit (que, después de todo, es local) funciona bien, pero el empuje no funciona (por ejemplo, debido a un conflicto o un problema de red). Cuando eso sucede, obtienen un error ambiguo; Les he dicho a comprobar el registro de cometer BitBucket si tienen alguna duda sobre una reciente cometió y, si no lo ven, para empujar. (Y para resolver el conflicto si ese es el problema, o pedir ayuda si no saben qué hacer).

El equipo ya tiene la buena costumbre de "tirar temprano y con frecuencia". Sin embargo, parece que el tirón puede causar conflictos, lo que creo que es nuevo. Si no es nuevo, mucho más frecuente que en SVN. He oído que puedo cambiar la forma en que Git tira (rebase en lugar de fusionar), pero no tengo una buena comprensión de las compensaciones allí (o cómo hacerlo en nuestro entorno).

El servidor es BitBucket (no Github). Tengo control administrativo total sobre nuestro repositorio pero ninguno en el servidor en general. Nada de eso es cambiante.

Los archivos de origen son XML. También hay archivos de gráficos, que todo el mundo sabe que no puedes fusionar, pero que casi nunca tenemos colisiones allí. Los conflictos de fusión provienen de los archivos XML, no de los gráficos.

¿Qué cambios puedo hacer en nuestro uso de Git para que el uso compartido del master sea más sencillo para el equipo hasta que podamos pasar al uso de ramas de características con solicitudes de extracción revisadas y validadas por prueba?

Hasta ahora, SourceTree fue el mejor IDE para aprender los conceptos, ya que muestra todos los cuadros de diálogo y opciones relevantes que tiene en cada etapa, las opciones predeterminadas generalmente están bien, no pierda el tiempo con rebase, etc. Simplemente siga el flujo normal:

• Tire del maestro, solo para asegurarse de que está actualizado
• Modifica tus archivos
• Confirma tus cambios (solo a nivel local)
• Tire nuevamente del maestro (esto hará que aparezcan conflictos)
• Edite todos los archivos hasta que se resuelvan los conflictos, lo que significa que el archivo se encuentra en el estado apropiado que desea confirmar (sin mensajes maestros <<<<< HEAD y >>>> en el archivo sin procesar)
• Cometer los cambios de fusión
• empujar

Si todos siguen esta receta, deberían estar bien.

Cada vez que alguien haga un cambio más grande o central, informe a los otros usuarios que se comprometan localmente y se retiren del maestro, para que no obtengan demasiados conflictos más adelante y la primera persona aún esté cerca para resolver los conflictos junto con ellos.

Invierta mucho tiempo para que todos comprendan el flujo, de lo contrario, podrían moverse un rato y luego sentirse cómodos con él mientras atornilla la rama maestra, por ejemplo, "usar mi archivo en lugar de remoto" para resolver un conflicto. todos los cambios realizados por otras personas.

Git es un sistema difícil de aprender, especialmente si creciste con Svn, sé paciente y dales tiempo para aprenderlo correctamente, con los nuevos usuarios a veces puedes pasar un día limpiando algún desastre, eso es normal. ;)

Hay tres cosas principales que debe recordar cuando trabaja desde la misma rama que otra persona:

• Nunca lo use a --forcemenos que realmente sepa lo que está haciendo.
• Ya sea commito stashel trabajo en curso antes de cada pull.
• Por lo general, es más fácil si pulljusto antes de a push.

Aparte de eso, señalaré que con el control de versión distribuido no importa si su repositorio "oficial" usa ramas o no. Eso no tiene relación alguna con lo que los usuarios individuales hacen en sus repositorios locales. Solía ​​usar git para obtener sucursales locales cuando mi compañía usaba un VCS central completamente diferente. Si crean sucursales locales para sus características y cometen errores de fusión con sus locales master, es mucho más fácil de arreglar sin entrar en el registro o alguna otra magia.

¿Es posible tomar un día para que todos aprendan git?

Realmente se debe esperar que los profesionales que usan computadoras aprendan una nueva herramienta y, aunque es posible que cometan muchos errores en cualquier VCS, deberían usar la herramienta ya que está diseñada para usarse.

La mejor manera de introducir esto es hacer que todos trabajen en su propia rama cuando hacen un cambio (lo más breve posible) y vuelven a unir y luego vuelven a fusionarse con el maestro cuando terminan. Esto no está muy lejos de la forma actual de trabajar e introduce un flujo de trabajo simple al que pueden acostumbrarse hasta que se sientan lo suficientemente seguros como para realizar operaciones más complicadas.

No uso Windows, pero si Tortoise básicamente les oculta git y finge que es SVN, entonces Tortoise es la herramienta incorrecta.

A veces, lo que estás haciendo tiene que cambiar.

El mayor problema es que todos están trabajando en master. Esto no es típico para el desarrollo de código, y también podría ser el modelo incorrecto en su caso. Si puede cambiar eso, al pedir / solicitar que los cambios se realicen en ramas separadas, estará en mejor forma. Con ramas, puede obtener lo siguiente:

• Exigir que no masterse permitan empujes directos a .
• Haga cumplir a través de Bitbucket que las solicitudes de extracción se crean y tienen al menos una aprobación antes de la fusión . Esto garantiza que alguien esté mirando los cambios, y también hace que la fusión sea menos dolorosa, ya que la interfaz de usuario mostrará conflictos contra la versión remota del código, no lo que sea que el usuario tenga en el escritorio. Esto evita el escenario commit-exitosed-but-push-failure.
• Ejecute "compilaciones" contra su repositorio antes de fusionar. Me doy cuenta de que es un repositorio de documentos, pero tal vez haya una corrección ortográfica, un raspado de jerga legal o incluso una traducción automatizada (exportar STRING_DEF a un archivo csv) que podría construirse a partir de esta compilación. O tal vez no, depende de tu trabajo.
• Permita que la gente trabaje en varias cosas diferentes al mismo tiempo más fácilmente. Sí, esto también se puede hacer con escondites, pero es un poco más complicado y algo me dice que tampoco los estás usando.

Si no puede usar la ramificación, puede considerar escribir un merge-and-pushscript que pueda automatizar algunos de los puntos débiles. Tal vez comprobaría que el usuario no está atrasado en el maestro, buscará y extraerá, y luego intentará la fusión ( posiblemente con--no-commit --no-ff ), y así sucesivamente.

Enfatice que puede rehacer fusiones

Puede ser obvio para usted, pero los antiguos usuarios de SVN pueden no ser conscientes de que pueden intentar resolver una fusión varias veces. Esto podría reducir la cantidad de indicadores de ayuda que recibe.

En SVN, cuando trabajas trunk, tendrías cambios sin confirmar sentados. Entonces harías un svn update. En ese momento, sus cambios se mezclarían con los cambios de otras personas para siempre. No había forma de deshacerlo (afaik), por lo que no tuvo más remedio que verificar manualmente todo y esperar que el repositorio estuviera en buen estado. Cuando realmente estarías mucho más cómodo simplemente rehaciendo la fusión.

La gente tendría la misma mentalidad incluso cuando nos moviéramos a git. Conduciendo a muchos errores involuntarios.

Afortunadamente con git hay un camino de regreso, específicamente porque puedes hacer commits locales. (Describo más adelante cómo se expresa esto en la línea de comandos)

Sin embargo, la forma en que esto se haga variará según las herramientas. Creo que rehacer una extracción no es algo expuesto en muchas GUI como un solo botón, pero probablemente sea posible. Me gusta que uses Cygwin. Mis compañeros de trabajo usan sourcetree. Dado que usa BitBucket, tendría sentido usarlo como su GUI, ya que es administrado por la misma compañía: Atlassian. Sospecho que hay una integración más estrecha.

En cuanto a los tirones

Creo que tienes razón en que la fusión pulles lo que está arruinando a la gente. En pullrealidad, A git fetchrecupera los cambios del servidor, seguido de git merge origin/<branchname>* que combina los cambios remotos en su sucursal local. ( https://git-scm.com/docs/git-pull )

El resultado es que todos los comandos de combinación estándar funcionan con extracción. Si esa fusión tiene conflictos, puede abortar git merge --abort. Lo que debería llevarlo de vuelta a antes de su fusión. Luego puede intentarlo nuevamente con git pullo git merge origin/<branchname>.

Si de alguna manera puede aprender cómo hacer lo anterior utilizando la herramienta de GUI de sus compañeros de trabajo, creo que eso resolverá la mayoría de sus problemas. Lo siento, no puedo ser más específico.

* Entiendo que el origen no siempre es el caso aquí.

Úselo git reflogpara diagnosticar problemas

Yo, como usted, tengo que diagnosticar problemas creados principalmente por el mal uso de las herramientas GUI. Creo que a git reflogveces puede ser útil, ya que es un rastro de acciones bastante consistente en el repositorio. Aunque a veces es difícil de leer.

Una alternativa

Dado que su situación es temporal , puede volver a SVN hasta que tenga el proceso en marcha para implementar. Dudaría en hacer esto, ya que muchos lugares continuarían diciendo 'Intentamos git una vez, pero simplemente no funcionó ...' y nunca lo recupero realmente.

Algunos otros problemas transitorios comunes

• La gente a menudo borraba y reclonaba su repositorio, convencida de que su repositorio estaba en un estado inutilizable. Por lo general, esto fue causado por la pérdida de la diferencia local y remota. Tanto las herramientas GUI como la CLI fallan al mostrar esto bien. En la CLI encuentro git log --decoratela forma más fácil de ver las diferencias. Pero si las cosas se ponen demasiado difíciles para el maestro (por ejemplo) puedesgit reset --hard origin/master

Un mecanismo posible, que muchos equipos de código abierto han adoptado, es usar el modelo de bifurcación: https://www.atlassian.com/git/tutorials/comparing-workflows (asegúrese de enunciar claramente cuando se discute un flujo de trabajo de git de bifurcación) ) .

En esto, cada desarrollador o sub-equipo tiene su propia bifurcación del repositorio que comprueban desde BitBucket. Proporciona un mecanismo para esto , configurando un origen "ascendente" además del control remoto predeterminado: deberán recordar "buscar aguas arriba" "y" fusionar remoto / ascendente / maestro "de forma regular.

Posiblemente resolverá los problemas del mecanismo de compilación, ya que las herramientas de compilación posiblemente apunten al maestro en un proyecto diferente, es decir, la bifurcación.

Luego, podría eliminar de la mayoría de las personas la capacidad de empujar directamente al proyecto maestro y convertirlo en un equipo más pequeño de personas con roles de revisión y aprobación. Ver https://www.atlassian.com/git/tutorials/making-a-pull-request

El lugar para leer sobre cómo asegurarse de que se realicen casi todas las comprobaciones deseables antes de los empujes es en la sección del libro de git en ganchos: https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - puede usar ganchos previos y anteriores para hacer cosas como ejecutar algunas pruebas en el compromiso propuesto para garantizar que el trabajo sea válido, etc. El único problema con los enlaces del lado del cliente es que los desarrolladores pueden desactivarlos o no pueden activarlos. ellos.

Tanto la búsqueda / combinación como los ganchos están disponibles en TortoiseGit.

Esto va a sonar contradictorio, pero escúchame:

Anímalos a comenzar a experimentar con git

Una de las cosas interesantes sobre git es que es sorprendentemente fácil hacer que cualquier operación local sea completamente segura. Cuando comencé a usar git, una de las cosas que me encontré haciendo fue comprimir todo el directorio como una copia de seguridad en caso de que arruinara algo. Más tarde descubrí que este es un gran error y casi nunca es realmente necesario para proteger su trabajo, pero tiene la virtud de ser muy seguro y muy simple, incluso si no sabe qué demonios está haciendo y cómo el comando que quieres probar saldrá. Lo único que debes evitar cuando haces esto es push. Si no presiona nada, esta es una forma 100% segura de probar lo que quiera.

El miedo a probar cosas es uno de los mayores obstáculos para aprender git. Se le da por lo tanto control sobre todo lo que es una especie de enormes proporciones. La realidad es que puede apegarse a algunas operaciones muy seguras para la mayoría de su uso diario, pero encontrar qué comandos son esos requiere algo de exploración.

Al darles una sensación de seguridad , estarán mucho más dispuestos a tratar de descubrir cómo hacer las cosas por su cuenta. Y estarán mucho más capacitados para encontrar un flujo de trabajo personal en su máquina local que funcione para ellos. Y si no todos hacen lo mismo localmente , está bien, siempre y cuando cumplan con los estándares con lo que presionan . Si se necesita comprimir todo el repositorio antes de realizar una operación para que se sientan así, está bien; pueden aprender mejores formas de hacer las cosas a medida que avanzan y mientras prueban cosas. Cualquier cosa para comenzar a probar cosas y ver lo que hace.

Esto no significa que el entrenamiento no valga nada. Por el contrario, la capacitación puede ayudarlo a presentarle características, patrones y normas. Pero no es un reemplazo para sentarse y hacer cosas en su trabajo diario. Ni git ni SVN son cosas de las que puedes ir a una clase y luego sabes todo. Usted tiene que utilizar para resolver sus problemas para familiarizarse con ellos y qué características son muy adecuadas para el cual los problemas.

Deja de desanimarlos de aprender los entresijos de git

Mencioné no presionar nada, lo que en realidad va en contra de una de las cosas que les has estado enseñando: siempre "Comprometerse y Empujar". Creo que deberías dejar de decirles que hagan esto y decirles que comiencen a hacer lo contrario. Git tiene básicamente 5 "lugares" donde tus cambios pueden ser:

• En disco, no comprometido
• Escenificado pero no comprometido
• En un compromiso local
• En un escondite local
• Repositorios remotos (solo las confirmaciones y etiquetas se insertan y se extraen entre diferentes repositorios)

En lugar de alentarlos a tirar y empujar todo en un solo paso, aliéntelos a aprovechar estos 5 lugares diferentes. Anímalos a:

• Obtener cambios antes de que cometan algo.

• Tome una decisión sobre cómo manejar los cambios recuperados. Las opciones son:

  • Confirme sus cambios locales, luego vuelva a clasificarlos sobre los cambios recuperados.
  • Confirme sus cambios locales y luego fusione con los cambios recuperados.

  • Guarde sus cambios, combínelos, y luego desencaje y resuelva cualquier conflicto.

    Hay otras cosas, pero no voy a entrar aquí. Tenga en cuenta que un tirón es literalmente solo una búsqueda y una fusión. No es como ellos; que es de ellos. (Los --rebasecambios aprobados se extraen de buscar + fusionar para buscar + rebase).

• Organice sus cambios y luego revíselos.
• Comprometa sus cambios por etapas y luego revise el compromiso.
• Empujar por separado.

Esto los alentará a verificar su trabajo antes de que esté disponible públicamente para todos, lo que significa que detectarán sus errores antes. Verán la confirmación y pensarán: "Espera, eso no es lo que quería", y a diferencia de SVN, pueden regresar e intentarlo nuevamente antes de presionar.

Una vez que se acostumbren a la idea de comprender dónde están sus cambios, pueden comenzar a decidir cuándo omitir los pasos y combinar ciertas operaciones (cuándo tirar porque ya sabe que desea buscar y fusionar o cuándo hacer clic en la opción Confirmar y presionar) .

Este es en realidad uno de los enormes beneficios de git sobre SVN, y git está diseñado teniendo en cuenta este patrón de uso. SVN, por el contrario, asume un repositorio central, por lo que no es sorprendente si las herramientas para git no están tan optimizadas para el mismo flujo de trabajo. En SVN, si su confirmación es incorrecta, su único recurso real es una nueva confirmación para deshacer el error.

Hacer esto en realidad conducirá naturalmente a la siguiente estrategia:

Anímalos a usar sucursales locales

Las sucursales locales realmente alivian muchos de los puntos débiles de trabajar en archivos compartidos. Puedo hacer todos los cambios que quiero en mi propia rama, y ​​nunca afectará a nadie ya que no los estoy presionando. Luego, cuando llegue el momento, puedo usar las mismas estrategias de fusión y rebase, solo que más fácil:

• Puedo cambiar la base de mi sucursal local, lo que hace que fusionarlo sea maestro trivial.
• Podría usar una combinación simple (crear una nueva confirmación) en master para incorporar los cambios de mi sucursal local.
• Puedo aplastar fusionar toda mi sucursal local en un solo commit en master si creo que mi sucursal es demasiado desordenada para salvarla.

El uso de sucursales locales también es un buen comienzo para descubrir una estrategia de ramificación sistemática. Ayuda a sus usuarios a comprender mejor sus propias necesidades de ramificación, por lo que puede elegir una estrategia basada en las necesidades y el nivel actual de comprensión / habilidad del equipo y no solo caer en Gitflow porque todos lo han escuchado.

Resumen

En resumen, git no es SVN y no puede ser tratado como tal. Necesitas:

• Elimine el miedo alentando la experimentación segura.
• Ayúdelos a comprender cómo es diferente git para que puedan ver cómo eso cambia su flujo de trabajo normal.
• Ayúdelos a comprender las funciones disponibles para ayudarlos a resolver sus problemas más fácilmente.

Todo esto lo ayudará a adoptar gradualmente un mejor uso de git, hasta que llegue al punto en que pueda comenzar a implementar un conjunto de estándares.

Características específicas

En el término inmediato, las siguientes ideas pueden ayudar.

Rebase

Mencionaste rebase y que realmente no lo entiendes en tu pregunta. Así que aquí está mi consejo: pruebe lo que acabo de describir. Realice algunos cambios localmente mientras otra persona empuja algunos cambios. Compromete tus cambios localmente . Comprime el directorio de tu repositorio como copia de seguridad. Obtenga los cambios de la otra persona. ¡Ahora intente ejecutar un comando rebase y vea qué sucede con sus commits! Puede leer un sinfín de publicaciones en el blog o recibir capacitación sobre rebase y cómo debe o no usarlo, pero nada de eso es un reemplazo para verlo en vivo en acción. Así que pruébalo .

merge.ff=only

Esta será una cuestión de gusto personal, pero la recomendaré al menos temporalmente, ya que mencionó que ya tiene problemas con el manejo de conflictos. Recomiendo configurar merge.ffaonly :

git config --global merge.ff only

"ff" significa "avance rápido". Una combinación de avance rápido es cuando git no necesita combinar cambios de diferentes confirmaciones. Simplemente mueve el puntero de la rama hacia una nueva confirmación a lo largo de una línea recta en el gráfico.

Lo que esto hace en la práctica es evitar que git intente automáticamente crear confirmaciones de fusión. Entonces, si confirmo algo localmente y luego realizo los cambios de otra persona, en lugar de intentar crear una confirmación de fusión (y potencialmente forzar al usuario a lidiar con conflictos), la fusión simplemente fallará. En efecto, git solo habrá realizado a fetch. Cuando no tiene confirmaciones locales, la fusión continúa normalmente.

Esto les brinda a los usuarios la oportunidad de revisar los diferentes commits antes de intentar fusionarlos y los obliga a tomar una decisión sobre la mejor manera de combinarlos. Puedo cambiar el nombre, continuar con la fusión (usando git merge --no-ffpara omitir la configuración), o incluso puedo posponer la fusión de mis cambios por ahora y manejarlo más tarde. Creo que este pequeño aumento de velocidad ayudará a su equipo a evitar tomar decisiones equivocadas sobre fusiones. Puede dejar que su equipo lo apague una vez que mejoren en el manejo de las fusiones.

Pasé por la misma experiencia SVN -> git en mi empresa y, según mi experiencia, el único remedio es el tiempo. Deje que las personas se acostumbren a las herramientas, dejen que cometan errores, muéstreles cómo solucionarlas. Su velocidad sufrirá por un tiempo, y las personas perderán trabajo, y todos estarán un poco nerviosos, pero esa es la naturaleza de cambiar algo tan fundamental como su VCS.

Dicho esto, estoy de acuerdo con todos los que opinan que TortoiseGit es un obstáculo, en lugar de una ayuda, tan temprano en el período de transición. TortoiseGit no es ... una gran interfaz gráfica de usuario en el mejor de los casos, y al ocultar cómo funciona realmente git en nombre de la simplicidad, también evita que sus compañeros de trabajo comprendan los conceptos básicos de git, como el compromiso de dos fases.

Tomamos la decisión (bastante drástica) de obligar a los desarrolladores a usar la línea de comandos (git bash o posh-git ) durante una semana, y eso funcionó de maravilla para comprender cómo funciona realmente git y cómo difiere de SVN. Puede sonar drástico, pero te sugiero que lo pruebes simplemente porque crea esa comprensión del modelo git, y una vez que lo tengan abajo, tus compañeros de trabajo pueden comenzar a usar las fachadas de GUI sobre git que les guste.

Nota final: habrá algunos de tus compañeros de trabajo que entenderán cómo funciona git casi de inmediato, y habrá algunos que nunca lo harán. En el último grupo, solo tiene que enseñar los encantamientos místicos para que su código llegue desde su máquina local al servidor para que todos puedan verlo.

Bueno, recientemente adapté el siguiente flujo de trabajo para nunca joder la rama maestra:

1) Todos usan su propia rama, que inicialmente es una copia de la rama maestra.

Denominemos la rama maestra "master" y mi propia rama "my_master".

Acabo de hacer mi rama del maestro, por lo que es exactamente lo mismo. Empiezo a trabajar en una nueva función en mi propia sucursal, y cuando lo hago, hago lo siguiente.

Actualmente en mi rama, acabo de terminar de codificar

git add . && git commit -m "Message" && git push

Regrese a la rama maestra

git checkout master

Tire si no está actualizado

git pull

Regresa a mi propia sucursal

git checkout my_master

Combinar el último maestro en mi propia sucursal

git merge master

Repara conflictos y fusiones

Prueba todo de nuevo

Cuando todo esté fusionado y arreglado en mi propia rama, empújalo

git push

Regrese a la rama maestra

git checkout master

Fusionarse con mi rama

git merge my_master

Imposible tener conflictos ya que se resuelven en su propia sucursal con una fusión anterior

Maestro de empuje

git push

Si todos siguen esto, la rama maestra estará limpia.

Entonces, tenemos un equipo que cambió de TFS a git y retuvo las viejas formas de pensar. Las reglas generales de operación son más o menos las mismas.

Sí, esto significa que todos trabajan en master. Esto no es tan malo; y un equipo acostumbrado a TFS o SVN encontrará esto más natural.

Procedimientos generales para que esto sea lo menos doloroso posible:

1. hacer git stash && git pull --rebase && git stash poptodas las mañanas
2. comprometerse temprano y con frecuencia (no es necesario presionar de inmediato; al menos podemos comenzar a aprovechar esta ventaja de git temprano)

3. para empujar haz el siguiente bucle:

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

Si todos están trabajando en master, no hay nada que puedas hacer. Las cosas inevitablemente se estropearán.

Debe usar master para productos completos que se envían a un cliente. Debe utilizar el desarrollo de desarrollo en curso, y usted debe no permitir que nadie para empujar al desarrollo. El estándar es que todos se ramifican desde el desarrollador, hacen sus cambios, los empujan de local a su sucursal en el servidor y emiten una solicitud de inserción. Entonces alguien revisa el cambio y lo fusiona con el desarrollo.

Para evitar conflictos, todos fusionan el desarrollo en su propia rama antes de empujar y resuelven conflictos en esa etapa (por lo que solo afecta a un desarrollador localmente). Si fusionarse con el desarrollo causaría conflictos, entonces no se fusiona: el desarrollador fusiona nuevamente el desarrollo en su rama, empuja al servidor nuevamente y luego se revisa nuevamente.

Puede usar sourcetree, por ejemplo, para que esto funcione sin ningún problema.