¿Realmente necesitamos bifurcarnos en Git?

6 minutos de lectura

Estoy en mi primera clase de ingeniería de software. Es la primera vez que cualquiera de nosotros trabaja en un equipo y usa git y github. En clase, nuestro maestro nos dijo que, por lo general, debe bifurcar el maestro, después de terminar su nueva función, fusionarla nuevamente con el maestro. Esto es lo que he estado haciendo. Sin embargo, los otros miembros de mi grupo no se ramifican. Extraen del maestro en github a su máquina local, hacen ediciones, terminan su función en su maestro local y luego empujan al maestro en github.

Estoy tratando de convencerlos de que se ramifiquen, pero ahora que lo pienso, lo encuentro más confuso. Me dijeron que el propósito de la rama es hacer una copia del código y no preocuparse por arruinar el maestro al poner accidentalmente un código no ejecutable.

¿Pero su maestro local no es realmente como una rama en sí misma? A medida que realizan ediciones, no cambian el maestro en github, por lo que otros pueden extraer el código de trabajo de github. Luego se fusionan, similar a una rama.

Estoy confundido, ¿por qué deberíamos ramificarnos si lo que están haciendo parece estar funcionando?

¡Gracias!

  • En proyectos reales, las personas colaboran en las funciones, los miembros del equipo revisan el código de otros antes de fusionarlo, las personas trabajan en diferentes funciones o correcciones al mismo tiempo, las funciones pueden durar mucho tiempo y, por lo tanto, deben guardarse no solo en la máquina del desarrollador, etc. etc. Todo esto es posible con la ramificación y el envío de ramas a github.

    – JB Nizet

    3 de junio de 2017 a las 6:30

¿Pero su maestro local no es realmente como una rama en sí misma?

¡Sí lo es!

Estoy confundido, ¿por qué deberíamos ramificarnos si lo que están haciendo parece estar funcionando?

Esto depende de su flujo de trabajo. Lo que parece estar describiendo es este flujo de trabajo:

Alice hace una rama alice que rastrea master y Bob hace un bob rama que también rastrea master. Alice siempre se compromete a alice y Bob siempre se compromete a bob. Luego, cuando están contentos con sus cambios, se fusionan en master.

Por supuesto, apenas hay diferencia entre esto y Alice y Bob trabajando en su local. master ¡sucursales!

El problema a menudo surge cuando la misma persona está trabajando en varias funciones al mismo tiempo. Por ejemplo

Alicia está trabajando en Feature A y Bob está trabajando en Feature B. Alice está a mitad de camino con Feature A y ha hecho algunos compromisos en alice. Sin embargo, Feature A es bastante difícil de implementar, por lo que Alice decide que debería trabajar en Feature C y hace algunos compromisos en alice. Bob terminó Feature B y decide que le gustaría abordar Feature A y así tira alice dentro bob.

Después de que Bob termine Feature A le gustaría fusionarse bob dentro master. Sin embargo, bob ahora contiene Feature A, Feature B y partes de Feature Cpero Feature C no está listo para ser fusionado! Es fácil ver que un flujo de trabajo como este puede generar muchos conflictos de combinación confusos.

El truco es que en lugar de tener sucursales personales uno debería tener rasgo sucursales. Alice debería tener una sucursal para Feature A y Feature C y Bob debería tener una sucursal para Feature B y Feature A. De esa manera, ambos pueden trabajar en diferentes características sin pisarse los dedos de los pies.

  • ¡Ok, gracias! Creo que mi grupo planea trabajar en una característica a la vez y por su cuenta. Pero ahora puedo ver que la bifurcación es realmente importante si las personas trabajan en varias funciones a la vez con la colaboración de otros miembros.

    – seal308

    5 jun 2017 a las 14:00

  • La creación de ramas de características puede parecer exagerada cuando se está comenzando, pero realmente le ahorran muchos problemas futuros cuando, debido a problemas imprevistos, muchas personas tienen que trabajar en la misma característica, o alguna característica tarda demasiado en fusionarse y el el desarrollador quiere seguir trabajando en otros problemas.

    – Moyamo

    6 de junio de 2017 a las 6:18

  • ¡Gran explicación! Creo que la mayoría de las personas usan sucursales de forma redundante. Esta es la única razón por la que la gente debería usarlos.

    – cerebro desbordado98

    10 de enero de 2021 a las 12:25

La idea es que tenga una rama maestra donde el código sea estable y fusionado.

Digamos que tengo una aplicación que raspa un sitio web.

Crearé una nueva rama llamada desarrollar/extraer datos. En esta rama, trabajaré en extraer los datos. Uno de los miembros de mi equipo podría trabajar en la aplicación de alguna lógica en los datos, para que pueda crear su propia rama de desarrollo/aplicación lógica.

Una vez que tiene algunas confirmaciones y su código es estable, puede abrir una solicitud de extracción para fusionar su código con el maestro, que puede ver en la interfaz de usuario de github, para ver qué código ha cambiado y decidir si desea fusionarlo o no. , o si se requieren cambios.

Ahora, después de un tiempo, mi código está listo, abro una solicitud de extracción para dominar, para que mis colegas puedan ver mi código y aprobar o sugerir cambios. Es fácil de ver y todos en el equipo saben que la rama principal es estable. Sin embargo, otras ramas no tienen por qué serlo. Tienen que serlo cuando se fusionan con el maestro.

avatar de usuario
puntero colgante

Mantenlo más corto. el maestro lo que tienes en la máquina es el maestro local. Empujas todos los cambios a origin/master servidor.

Una razón principal por la que no se recomienda trabajar en el master rama es varias personas que trabajan en el proyecto y en el que una rama debe ser la base común para todos los que crearon la rama.


Por ejemplo, tiene el producto al que desea agregarle un módulo Bluetooth, luego crea una rama add_blueetooth desde el maestro cuando lo fusionó con el maestro. Otro tipo está trabajando en wifi, puede fusionar su sucursal en maestro. Es solo el flujo de trabajo común de CVS, donde la creación de ramas conduce al trabajo paralelo.


¿Qué sucede realmente cuando clonas?

Realmente, git clone obtiene todas las sucursales remotas, crea una sucursal local que es la master, para ti. Solo escribe este comando git branch -a,

git branch -a
* master
  remotes/origin/HEAD

Son otros comandos donde puedes ver las sucursales remotas usando git branch -r.

Puede verificar la referencia creada por la sucursal local maniobrando a esta ubicación. refs/remotes/origin

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad