Conceptos GIT más confusos

Primero analicemos la diferencia entre los comandos de git, a saber, » git –pull » y » git -fetch «. Si estamos hablando de git pull and fetch , entonces estamos trabajando con el repositorio remoto y queremos actualizar las sucursales locales con las sucursales remotas de una manera diferente. git pull hace un git fetch seguido de un git merge como se muestra en la siguiente imagen de la siguiente manera:  

git pull: cuando usas git pull, git intenta fusionarse automáticamente. git fusionará cualquier confirmación extraída en la rama en la que está trabajando actualmente. git pull fusiona automáticamente las confirmaciones sin permitirle revisarlas primero. Si no administra sus sucursales con cuidado, es posible que se encuentre con conflictos frecuentes.

git fetch: cuando no desea fusionar directamente los cambios del repositorio remoto y desea revisar primero el código, se sugiere usar git fetch.

Git clone vs fork se puede tratar como:

• Bifurcación: cuenta de GitHub
• Clonación: Git

Cuando bifurca un repositorio desde su cuenta de GitHub, crea una copia del repositorio ascendente, pero el repositorio permanece en su cuenta de GitHub y no en su máquina local. Mientras que, cuando clona un repositorio, el repositorio se copia en su máquina local con la ayuda de Git, pero en este momento no tiene nada que ver con su cuenta de GitHub.

• Cuando bifurcas un repositorio desde tu cuenta de GitHub, obtienes una copia completamente independiente del repositorio en tu cuenta y ahora, si clonas este repositorio en tu máquina local, el flujo ascendente del repositorio local no será el repositorio original sino el tuyo. copia de ese repositorio en su cuenta.
• Por lo tanto, ahora todas sus requests PUSH y PULL de su git local apuntarán a la parte superior que es su copia del repositorio.

Alijo Git

Para entender este comando, supongamos por un momento que git no tiene un comando para ocultar cambios. Suponga que está trabajando en un repositorio con dos ramas, A y B. Las ramas A y B han divergido entre sí durante bastante tiempo y tienen cabezas diferentes. Mientras trabaja en algunos archivos en la rama A, su equipo le pide que corrija un error en la rama B. Rápidamente guarda sus cambios en A e intenta verificar la rama B con git checkout B. Git cancela inmediatamente la operación y arroja el siguiente error declarado de la siguiente manera:

"Your local changes to the following files would be overwritten by checkout … 
Please commit your changes or stash them before you switch branches."

Nota: Este es exactamente el tipo de escenario para el que está diseñado git stash.

Git stash guarda (oculta) los cambios no confirmados en su máquina local, lo que a su vez le permite realizar cambios, cambiar de rama y también realizar otras operaciones de Git. A continuación, puede volver a aplicar los cambios ocultos cuando los necesite.

git stash: save for later use

Git stash guarda temporalmente los cambios que ha realizado en su copia de trabajo para que pueda trabajar en otra cosa y luego volver y volver a aplicarlos más tarde. El ocultamiento es útil si necesita cambiar rápidamente de contexto y trabajar en otra cosa, pero está a la mitad de un cambio de código y no está listo para comprometerse.

El comando git stash toma sus cambios no confirmados (tanto preparados como no preparados) y los guarda para su uso posterior. Recuerde ciertos puntos clave importantes que se enumeran a continuación:  

• El alijo es local para su repositorio de Git; los alijos no se transfieren al servidor cuando empujas.
• Git guarda temporalmente sus datos de forma segura sin comprometerse.

¿Diferencia entre Git Merge y Git Rebase?

Git Merge y Git Rebase se usan para combinar los cambios de las ramas, pero de diferentes maneras.

Consideremos un escenario, comenzó a trabajar en una nueva función en una rama dedicada, luego otros miembros del equipo actualizan la rama principal con nuevas confirmaciones. Esto da como resultado una historia bifurcada, que es muy común en Git.

Ahora, si las confirmaciones en la rama «principal» son relevantes para su rama de funciones y desea incorporar esas confirmaciones en su rama de funciones. En este momento tiene las siguientes dos opciones:  fusionar o reorganizar.

Fusión: si elegimos la opción Fusión, entonces «El historial de ambas sucursales permanece intacto» y las sucursales existentes no se modifican de ninguna manera.

Nota: merge ejecuta solo una nueva confirmación

Reorganización: si elegimos la opción Reorganización, toda la rama de función se mueve para comenzar en la punta de la rama principal, incorporando efectivamente todas las confirmaciones de la rama de función como nuevas confirmaciones en la rama principal.

Rebasar reescribe el historial del proyecto al crear nuevos compromisos para cada compromiso en la rama original.

Debe estar preguntándose cuándo usar Merge y cuándo usar Rebase.

A. Utilice Fusionar cuando:

• Desea conservar el historial completo de confirmaciones y el orden cronológico.
• Queremos agregar cambios a una rama de función de vuelta a la rama principal.
• Desea revertir los cambios rápidamente.

B. Use Rebase cuando:

• Desea aplastar varias confirmaciones.
• Mantenga un historial de confirmación simple y optimizado.