Tutorial de uso de GIT (quince pasos para entender, el más detallado de Internet)

1. Instalar GIT

Descargue GIT desde el sitio web oficial: https://git-scm.com/downloads

2. Crea un almacén

Haga clic derecho en un área en blanco de la carpeta donde desea crear el repositorio,

haga clic en "GIT Bash Here" en el menú emergente y luego inicialice el repositorio.

$ git init

Después del éxito, habrá una carpeta oculta adicional ".git" en la carpeta. GIT utiliza este directorio para rastrear y administrar versiones. No modifique manualmente los archivos en este directorio; de lo contrario, el almacén de git se destruirá. .

.git es una carpeta oculta, que debe configurarse para que muestre las carpetas ocultas antes de poder verlas.

1. Abra las opciones de carpeta

o

2. Configure los archivos ocultos que

se mostrarán. Recuerde, solo asegúrese de que la carpeta .git exista. No cambie el contenido casualmente.

3. Partición y flujo de trabajo de GIT

• Espacio de trabajo: el espacio de trabajo
  es donde los programadores editan el código. Es el directorio donde se encuentra .git (almacén) (no dentro de .git). Todos los cambios se realizan en esta área y tendrán efecto directamente en esta área primero.
• Índice / Etapa:
  el lugar donde se almacenan temporalmente los archivos modificados en el área de almacenamiento temporal. Todos los cambios que se enviarán al almacén (adición, eliminación y modificación de archivos en el espacio de trabajo) deben agregarse (agregarse) aquí primero y luego enviado (comprometer). . Por supuesto, también puedes consultar el espacio de trabajo.
• 
  Repositorio: cada envío en el área de almacén (o almacén local) es una versión. El área de almacén guarda cada versión enviada anteriormente. Puede enviarse al almacén remoto o restaurarse (restablecer, revertir, pagar) nuevamente al espacio de trabajo .
• Remoto: almacén remoto
  El almacén remoto almacena varias versiones y ramas enviadas por uno o más autores desde su almacén local. Cada autor puede extraer la última versión de master (rama master) localmente, fusionar sus propios cambios y luego enviarlos a la rama master del almacén remoto para que otros los utilicen. Cada uno es responsable de su propia parte y luego fusiona sus propios resultados en la rama maestra, de modo que la división del trabajo se pueda llevar a cabo fácilmente.

4. Agregue archivos al área de almacenamiento temporal

4.1 Primero verifique el estado actual del almacén.

$ git status

Los rojos son archivos que no se han agregado al área de preparación. Si se trata de un almacén recién creado, todos los archivos en la carpeta estarán en rojo después del estado de git, porque estos archivos no se han agregado al área de preparación y son todos " archivos sin seguimiento" (Archivos sin seguimiento).

4.2 Agregar un solo archivo al área de almacenamiento temporal

$ git add source1.c

4.3 Agregar varios archivos al área de almacenamiento temporal

$ git add source1.c source2.c source3.c

4.4 Agregar todos los archivos al área de almacenamiento temporal

$ git add .

Después de agregarlo al área de preparación, verifique el estado del almacén. El archivo agregado se vuelve verde.

5. Borre los archivos que no se han agregado al área de almacenamiento temporal

Si desea borrar archivos recién agregados o archivos que nunca han sido rastreados (agregados al área de almacenamiento temporal), puede usar el siguiente comando.
Por ejemplo: se agregaron source4.c y source5.c, o el almacén local nunca se agregó al área de preparación después de crearlo, y ahora quiero borrarlo.

5.1 Verifique qué archivos se eliminarán mediante limpieza

$ git clean -n

5.2 Eliminar todos los archivos sin seguimiento en el directorio actual. Las carpetas y archivos especificados en el archivo .gitignore no se eliminarán.

$ git clean -f

Después de la ejecución, se eliminarán source4.c y source5.c en la carpeta. Si ejecuta git status nuevamente (verifique el estado del almacén), no verá el recordatorio de estos dos archivos.

5.3 Eliminar archivos en la ruta especificada que no han sido rastreados

$ git clean -f <路径>

5.4 Eliminar archivos y carpetas en el directorio actual que no han sido rastreados

$ git clean -df

5.5 Eliminar todos los archivos sin seguimiento en el directorio actual, independientemente de si son las carpetas y archivos especificados en el archivo .gitignore.

$ git clean -xf

5.6 Agregar archivo .gitignore

Generalmente, siempre tendremos algunos archivos que no necesitan ser administrados por Git, no es necesario agregarlos ni enviarlos, y no queremos que aparezcan siempre en la lista de archivos sin seguimiento. Por lo general, se trata de archivos generados automáticamente, como archivos de registro o archivos temporales creados durante el proceso de compilación.
Por ejemplo, hay un archivo temporal llamado file1.txt y hay un archivo ensamblador (*.o) generado durante el proceso de compilación, que queremos ignorar.

Cuando no hay ningún archivo .gitignore, este archivo sin seguimiento se mostrará al ver el estado.

5.6.1 Crear un archivo .gitignore

Primero veamos la situación creada en la ventana

: Después de crear un nuevo documento, aparece el siguiente archivo.

Cambiar nombre.

¡Algo salió mal! Porque queremos crear un archivo con un nombre vacío y un sufijo .gitignore, y los archivos creados en la ventana deben tener un nombre.
¿Como arreglarlo?

Todavía hay métodos, podemos crearlo en la caja negra de git base. Luego use el editor vim o vi para editar, o haga doble clic en el directorio para abrir la edición.

Después de crear y editar el archivo .gitignore (el proceso de edición se encuentra al final de esta sección), verifiquemos el estado del almacén.

Se puede ver que los archivos que anteriormente se mostraban como sin seguimiento se han ignorado.
A continuación podemos agregar .gitignore y enviarlo, para que tengamos un archivo .gitignore en la última versión.

Sin embargo, si el archivo ya está en el repositorio, ignorarlo no tiene ningún efecto.

Por ejemplo, source1.c ya es un archivo en el almacén y newfile.txt es un archivo recién creado que se agregó al área de preparación. Queremos ignorarlos ahora.

Se puede ver que ignorar no es válido. Después de cambiar source1.c, todavía habrá un recordatorio correspondiente. El newfile.txt en el área de almacenamiento temporal todavía está allí y, si continúa realizando cambios en newfile.txt, aparecerá el recordatorio correspondiente.

Se puede ver que si desea ignorar un archivo, primero debe asegurarse de que no esté en el almacén y el área de preparación en este momento.
Si ya están en el almacén y en el área de preparación, la única forma es limpiarlos.
Como se muestra abajo:

El siguiente es el proceso de edición con vim editor.

Después de ejecutar el comando $vim .gitignore, el editor vim abre el archivo .gitignore (archivo vacío). Este es el modo normal del editor vim. Haga clic en i para ingresar al modo de inserción (editable).

5.6.2 Cómo escribir archivos gitignore

1. Git ignorará todas las líneas vacías o que comiencen con el símbolo de comentario #.
2. Se puede utilizar la coincidencia de patrones globales estándar.
3. El patrón coincidente seguido de una barra invertida (/) indica que se debe ignorar el directorio.
4. Para ignorar archivos o directorios fuera del patrón especificado, puede agregar un signo de exclamación (!) antes del patrón para negarlo.

El llamado patrón global se refiere a una expresión regular simplificada utilizada por el shell.

• El asterisco (*) coincide con cero o más caracteres arbitrarios;
• [abc] coincide con cualquier carácter enumerado entre corchetes (este ejemplo coincide con a, a b o a c);
• El signo de interrogación (?) coincide sólo con un carácter arbitrario;
• Si usa un guión para separar dos caracteres entre corchetes, significa que todos los caracteres dentro del rango de estos dos caracteres pueden coincidir (por ejemplo, [0-9] significa que todos los números del 0 al 9 coinciden).

Por ejemplo:

# 此为注释 – 将被 Git 忽略
*.a       # 忽略所有 .a 结尾的文件
!lib.a    # 但 lib.a 除外
/TODO     # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
build/    # 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt

/ , /* y !
/OBJ/
indican que se ignoran todos los archivos del directorio OBJ.
/OBJ/
!/OBJ/UWB.sct *
indica que los archivos en el directorio OBJ se ignoran, excepto UWB.sct.
"!" se utiliza para restaurar el rastreo, pero si se ignora el directorio donde se encuentra el archivo, no se puede volver a rastrear el archivo.

* y **
/a/*/b solo puede coincidir con b en el subdirectorio de segundo nivel de a, como por ejemplo a/x/b /
a/**/b puede coincidir con b en cualquier subdirectorio de nivel de a, como por ejemplo a /b , a/x/b, a/x/y/b …

6. Eliminar archivos en el almacén.

6.1 Agregar una solicitud para eliminar un archivo en el almacén al área de almacenamiento temporal y cancelar el seguimiento del archivo, pero no eliminar el archivo fuente

$ git rm --cached source1.c

Recordatorio: si desea borrar varios archivos, simplemente enumérelos más tarde.

Después de la ejecución:
la solicitud para eliminar archivos en el almacén se agrega al área de almacenamiento temporal y entra en vigor después del envío.
Cancelar el seguimiento del archivo, con efecto inmediato
. El archivo y sus cambios en el espacio de trabajo siguen ahí, pero los cambios no se agregan al área de preparación.

6.2 Agregar una solicitud para eliminar un archivo en el almacén al área de almacenamiento temporal y eliminar el archivo fuente

$ git rm source1.c

Recordatorio: si desea borrar varios archivos, simplemente enumérelos más tarde.

Después de ejecutar el comando:
el archivo fuente se elimina inmediatamente y la eliminación de los archivos en el almacén entra en vigor solo después del envío.

7. Deshacer los cambios de los archivos rastreados en el espacio de trabajo.

7.1 Primero verifique el estado actual del almacén.

$ git status

Este es el archivo de seguimiento que ha cambiado en el espacio de trabajo.

7.2 Ver cambios específicos en archivos rastreados

$ git diff 

7.3 Comprobar qué contenido se ha modificado en un archivo rastreado

$ git diff  soure1.c   

Recordatorio: si desea ver varios archivos, enumérelos más tarde.

El rojo es contenido eliminado, el verde es contenido agregado.

7.4 Comprobar qué contenido ha sido modificado por un determinado tipo de archivo rastreado

A veces, solo se pueden cambiar uno o dos archivos, pero después de la compilación, git status encuentra que se ha cambiado una gran cantidad de archivos (marcados en rojo). Si usa git diff directamente, el siguiente contenido le hará dudar de su vida. Por lo tanto, también podemos observar cambios en un determinado tipo o tipos de archivos.

Recordatorio: si desea ver varias categorías, enumérelas más tarde.

$ git diff *.c *.h

Por supuesto, una mejor manera es utilizar el archivo .gitignore para ignorar esos archivos intermedios y no rastrearlos. Consulte la sección 5.6.1 para operaciones específicas.

7.5 Deshacer los cambios de un archivo rastreado en el espacio de trabajo

$ git checkout -- source1.c   

Recordatorio: si desea borrar varios archivos, simplemente enumérelos más tarde.

Por ejemplo: "modificado: source1.c" en la imagen de arriba indica que el archivo source1.c en el área de almacenamiento temporal ha sido modificado. Puede usar $ git checkout – source1.c para descartar este cambio.

7.6 Deshacer todos los cambios en los archivos rastreados en el espacio de trabajo

$ git checkout . 

7.7 Cancelar todos los cambios (adición, eliminación, modificación) a los archivos rastreados en el espacio de trabajo local después de la última adición de git y eliminar archivos sin seguimiento

$ git checkout . && git clean -df

Por ejemplo: el directorio actual incluye source1.c, source2.c y source3.c, todos los cuales se agregaron al área de almacenamiento temporal la última vez.

Posteriormente, se agregó source4.c y el contenido de source3.c se cambió a: 333.

Verifique el estado del almacén y podrá ver todos los cambios en el directorio actual en comparación con la última vez que se agregó al área de preparación (git add).
Si desea descartar estos cambios, puede usar: $ git checkout.&& git clean -df
De acuerdo con el contenido anterior:
$ git checkout. es para descartar los cambios en los archivos rastreados en el espacio de trabajo, como los cambios en source3. .c arriba
$ git clean -df descarta archivos sin seguimiento. Por ejemplo,
después de ejecutar los dos comandos source4.c recién agregados arriba, los archivos rastreados se pueden restaurar al estado posterior al último git add.

8. Enviar al almacén local

8.1 Antes de enviar, verifique el estado del almacén para asegurarse de que los archivos en el área de almacenamiento temporal no hayan cambiado.

$ git status

En la imagen de arriba, "modificado: source1.c" significa que el archivo ha sido modificado y este mensaje debe solucionarse antes de enviarlo.
Método 1 Para actualizar este cambio en el área de preparación, puede utilizar:

$ git add source1.c "或 "$ git add .

Método 2 Para descartar este cambio, puedes usar:

$ git checkout -- source1.c 

8.2 Si hay archivos modificados en el área de almacenamiento temporal, primero debe actualizarlos al área de almacenamiento temporal usando el comando agregar.

$ git add sorce1.c		//把source1.c加到暂存区
或 
$ git add .					//把当前目录中所有文件加到暂存区

8.3 Enviar archivos (lo siguiente –m es un comentario)

$ git commit –m “注释内容”

Esto solo se envía al almacén local. Para enviarlo al almacén remoto (github) y guardarlo, se deben cumplir las siguientes condiciones u operaciones:
1. Tener una cuenta de github
2. Crear un almacén de github
3. Crear una CLAVE SSH localmente y luego agréguelo a la Lista de permisos de github
4. Establezca una asociación entre los repositorios local y github

8.4 Modificar los comentarios enviados más recientemente

$ git commit --amend

8.5 Modificar comentarios enviados una o más veces antes

$ git rebase -i HEAD~2	//修改最近两次提交的注释

La siguiente es la ventana que aparece después de ejecutar el comando git rebase -i HEAD~2. La ventana que

acaba de aparecer arriba no se puede editar todavía. Haga clic en "i" para ingresar al modo de edición.

Después de editar las instrucciones, continúe con el paso de modificar los comentarios.

8.6 toque

Después de confirmaciones frecuentes, habrá una larga lista de registros de confirmaciones densos. Una vez que hay un problema con el proyecto y necesita verificar el problema del código de un determinado nodo, será un dolor de cabeza. Aunque hay un mensaje de confirmación, todavía existen problemas como dificultad para encontrarlo y una descripción poco clara.

Como la mayoría de los VCS, Git también puede etiquetar versiones en un momento determinado. La gente suele hacer esto cuando lanza una determinada versión de software (como v1.0, etc.).

El propósito del etiquetado es agregar nombres semánticos a los nodos de desarrollo del proyecto, es decir, alias para versiones funcionales. Al agregar un nombre de etiqueta y la información que lo acompaña, puede facilitar el seguimiento y la revisión durante el mantenimiento futuro del proyecto. Además, también puede utilizar registros de etiquetas para comprender aproximadamente la compatibilidad con versiones anteriores, las modificaciones de API y las iteraciones del proyecto actual.

8.6.1 Etiquetar la versión actual

Utilice el comando git tag seguido del nombre de la etiqueta para crear una etiqueta directamente.

$ git tag v1.0

También puede agregar el parámetro -a para crear una etiqueta con comentarios. La información del comentario se especifica mediante -m.

$ git tag -a v1.0 -m "备注信息"

8.6.2 Etiquetar un número de confirmación específico

No es necesario que la etiqueta esté en la cabeza, también puede estar en la versión anterior.

8.6.3 Listar etiquetas existentes

$ git tag

8.6.4 Ver detalles de la etiqueta

$ git show v1.0	//查看v1.0标签的详细信息

8.6.5 Cambiar a la versión correspondiente a una determinada etiqueta

$ git checkout v1.0	//切换到v1.0标签对应的版本

Si desea realizar más cambios en la versión v0.5, después de ingresar a la versión v0.5, estará en un estado libre. En este estado, puede crear y cambiar a una nueva rama, y ​​luego puede guardar su cambios y presentaciones.

8.6.6 Sincronizar etiquetas con el almacén remoto

$ git push origin v1.0	//将本地v1.0标签同步到远程仓库

8.6.7 Eliminar etiquetas

8.6.7.1 Eliminar etiquetas locales

$ git tag -d v1.0	//删除本地的v1.0标签

8.6.7.2 Eliminar la etiqueta del almacén remoto

Si desea eliminar la etiqueta del almacén remoto, primero debe eliminar la etiqueta local correspondiente y luego eliminar la etiqueta del almacén remoto; de lo contrario, no será válida.

$  git push origin :refs/tags/v1.0	//删除远程仓库的v1.0标签

Consejo: para obtener información sobre almacenes remotos, consulte las conferencias 9 y 10 a continuación.

9. Registre una cuenta, cree un almacén y cree una CLAVE SSH

9.1 Primero vaya al sitio web oficial para registrar una cuenta de github: https://github.com/

9.2 Crear un repositorio de github

9.3 Crear CLAVE SSH

Dado que la transferencia entre su repositorio Git local y su repositorio github está cifrada a través de SSH, debe crear una CLAVE SSH localmente y agregarla a la lista de permitidos de github.

9.3.1 Comprobar si hay SSH, si nunca se ha creado no debe estar ahí.

$ cd ~/.ssh
$ ls

Compruebe si el archivo id_rsa.pub o id_dsa.pub ya existe, si es así, ya existe SSH.

9.3.2 Crear una clave SSH

$ ssh-keygen -t rsa -C "注释文字"

Significado de los parámetros del comando:
-t especifica el tipo de clave, el valor predeterminado es rsa y se puede omitir.
-C establece el texto del comentario, como la dirección de correo electrónico.
-f especifica el nombre del archivo de almacenamiento del archivo clave.
El código anterior omite el parámetro -f. Por lo tanto, después de ejecutar el comando anterior, se le pedirá que ingrese un nombre de archivo para guardar el código de clave SSH que acaba de generar.

9.3.3 Copiar el contenido del archivo id_rsa.pub

$ clip < ~/.ssh/id_rsa.pub

Después de ejecutar este comando, la clave pública de SSH KEY se copió en el tablero y se puede pegar en github.

9.3.4 Vaya a github para abrir la configuración

9.3.5 Agregar SSH

Complete cualquier título y pegue el contenido del archivo id_rsa.pub en el cuadro de texto Clave.

9.3.6 Copiar la dirección de la biblioteca remota

Haga clic en el repositorio de github

10. Asociado al almacén remoto

10.1 Ver información de la biblioteca remota

$ git remote 
$ git remote –v	（-v显示对应的克隆地址）

Si el almacén remoto no ha sido asociado, no se mostrará nada después de la ejecución.

10.2.Asociar biblioteca remota

$ git remote add heater_mainboard [email protected]:wuzulie/Demo_hub.git 

El nombre de la biblioteca remota es origen, que es el nombre predeterminado de Git. También se puede cambiar a otro, pero el nombre origen le indica que es una biblioteca remota de un vistazo.
Después de la asociación, use git remoto para verificar la información del almacén remoto y tendrá el contenido: fetch corresponde a la dirección de recuperación y push es la dirección de inserción.

10.3 Eliminar biblioteca remota

$ git remote rm origin

Si verifica la biblioteca remota después de la eliminación, no habrá contenido.

11. Crea y fusiona ramas.

Casi todos los sistemas de control de versiones admiten ramificaciones de alguna forma. El uso de ramas significa que puede separar su trabajo de la línea de desarrollo principal para no afectar la versión estable de la línea de desarrollo principal.

En primer lugar, la rama master debe ser muy estable y se utiliza para lanzar nuevas versiones. En circunstancias normales, no se permite trabajar en ella.
En circunstancias normales, el trabajo se realiza en la rama de desarrollo (desarrollo) recién creada. Una vez que las nuevas funciones agregadas en la rama de desarrollo se depuran y estabilizan, se pueden fusionar en la rama principal maestra para su distribución.
Si de repente encuentra un ERROR, puede crear una nueva rama desde la rama maestra para corregir específicamente el ERROR. Una vez completado el parche, combínelo nuevamente con la rama maestra. Generalmente, los ERRORES no se corrigen en la rama de desarrollo u otras ramas de desarrollo de nuevas funciones, porque el código de estas ramas generalmente no está completo durante el proceso de edición, y existe una alta probabilidad de que haya nuevos ERRORES, e incluso pueden ser temporalmente incapaz de ejecutarse.

Por ahora, sólo hay una rama, la rama maestra. HEAD apunta a la última versión de la rama actual.

11.1 Estrategia de sucursal

En el ejemplo anterior, solo hemos utilizado la rama master y la rama dev. En el desarrollo real, es imposible tener sólo dos sucursales. ¿Qué otras ramas debería haber y cuáles son las diferencias entre estas ramas?

• Dos sucursales de larga data en el proyecto.

master : la rama principal, responsable de registrar la iteración de la versión en línea. El código de esta rama es completamente consistente con el código en línea.
desarrollar (dev) : rama de desarrollo, que registra una versión relativamente estable, y todas las ramas de funciones y ramas de corrección de errores se crean a partir de esta rama.

• Otras ramas son ramas a corto plazo y deben eliminarse una vez que se completa el desarrollo funcional.

característica : rama de característica (función), utilizada para desarrollar nuevas funciones. Diferentes funciones crean diferentes ramas de funciones. Una vez que la rama de función se desarrolla y se prueba automáticamente, debe fusionarse en la rama de desarrollo y luego eliminarse.
corrección de errores : rama de corrección de errores, utilizada para corregir errores no urgentes. Para errores comunes, debe crear una rama de corrección de errores para el desarrollo. Una vez que se completa el desarrollo y la autoprueba no es un problema, combínela con la rama de desarrollo y elimínela. la rama.
lanzamiento : Rama de lanzamiento, utilizada para preparar el código para estar en línea. Esta rama se crea a partir de la rama de desarrollo. Después de la creación, los estudiantes de prueba la lanzan al entorno de prueba para realizar pruebas. Los errores encontrados durante la prueba requieren que los desarrolladores corrijan los errores en la rama de lanzamiento. Todos los errores están corregidos. Una vez completado, antes de conectarse, debe fusionar la rama de lanzamiento con la rama maestra y la rama de desarrollo.
hotfix : rama de corrección de errores de emergencia, esta rama solo se usa en emergencias. Se crea a partir de la rama maestra y se usa para corregir errores en línea con urgencia . Una vez completada la reparación, la rama debe fusionarse con la rama maestra para conectarse , y debe fusionarse en la rama de desarrollo.

11.2 Ver todas las sucursales actuales

$ git branch  

11.3 Crear una rama

Si desea corregir un error o agregar nuevas funciones, a menudo crea una rama para modificarla y probarla. Después de lograr el objetivo, puede fusionarlo nuevamente con la rama principal y luego la versión de la rama principal se modificará en consecuencia.

$ git branch dev	//创建分支dev 

Después de la creación, la nueva sucursal es exactamente igual a la sucursal principal, incluido el área de almacén, el área de preparación, el área de trabajo y los registros de envío.

11.4 Cambiar de rama

$ git checkout dev 

Nota: Si el área de preparación y el espacio de trabajo se modifican al cambiar de rama, se pueden producir errores de cambio o incluso se pueden perder archivos.

Si cambia de sucursal con modificaciones, existen cinco situaciones:

1. Los archivos en el almacén no se han modificado y los archivos modificados en el área de preparación y el espacio de trabajo no se han confirmado.
En este caso, puede cambiar a cualquier sucursal y los cambios en el área de preparación y el espacio de trabajo también serán compartido después del cambio. La razón por la que decimos compartir es que después de cambiar, el contenido del área de almacenamiento temporal y el espacio de trabajo serán los mismos. Además, si realiza cambios en archivos no confirmados en el área de preparación o en el espacio de trabajo de cualquier rama, los cambios también tendrán efecto en otras ramas.

2. Los archivos en el almacén se han modificado, pero no hay conflicto en el contenido de los archivos entre las ramas antes y después del cambio. En este caso, también
puede cambiar y los cambios en el área de almacenamiento temporal y el espacio de trabajo. después del cambio también se compartirá. Este intercambio es el mismo que se mencionó anteriormente, por lo que no entraré en detalles.

3. Los archivos en el almacén se han modificado y el contenido de los archivos en las ramas antes y después del cambio entran en conflicto.
En este caso, se producirá un error durante el cambio, como se muestra a continuación.

4. El nuevo archivo de la sucursal actual tiene el mismo nombre que el archivo en la sucursal que se va a cambiar, pero el contenido es diferente o el archivo no se ha agregado al área de preparación. En este caso, el cambio saldrá
mal , Como se muestra abajo.

Nota: Si el archivo con el mismo nombre no se ha agregado al área de almacenamiento temporal, no importa si el contenido es el mismo, el cambio provocará un error.

5. El nuevo archivo de la sucursal actual tiene el mismo nombre que el archivo en la sucursal a cambiar, el contenido es el mismo (puede entenderse como el mismo archivo) y también se agrega al área de almacenamiento temporal. En este caso, el archivo se perderá, como se muestra
a continuación.

Por lo tanto, se debe prestar especial atención antes de cambiar de sucursal para garantizar que el área de almacenamiento temporal esté limpia. Si hay archivos, una situación es que no se pueden cambiar y deben enviarse primero. En otro caso (los archivos en el área de almacenamiento temporal también existen en la sucursal después del cambio y el contenido es el mismo que antes), los archivos se perderán.

Por supuesto, si usa el comando de creación y cambio "$ git checkout –b dev", no habrá ningún error sin importar si el estado del área de preparación y el área de trabajo está limpio o no. Debido a que no hay posibilidad de conflicto, después de crear y cambiar, el contenido del área de almacén, área de preparación y área de trabajo de la nueva sucursal será el mismo que el de la sucursal maestra cuando se creó.
Consulte la siguiente sección (11.5) para obtener más detalles.

11.5 Crear una nueva rama y cambiar a esta rama

$ git checkout –b dev  

Esto equivale a ejecutar los siguientes dos comandos:

$ git branch dev	//创建新分支dev
$ git checkout dev	//切换到分支dev  

Al visualizar sucursales, la sucursal con "*" indica la sucursal actual.
Si el área de preparación y el espacio de trabajo estaban limpios antes de que se creara el conmutador (sin cambios en comparación con la última versión), entonces el espacio de trabajo antes de que se creara el conmutador también está limpio.
Pero, ¿qué pasará si el espacio de trabajo anterior al cambio no está limpio?

Se puede ver que el estado de la nueva rama y el espacio de trabajo de la rama maestra cuando se crea el conmutador es el mismo.
Mencionamos en la Sección 11.4 que al cambiar de rama normalmente (a diferencia de crear y cambiar), si los archivos en el área de preparación no son los archivos rastreados en la última versión, se eliminarán después de realizar el cambio.
Entonces, si se crea y se cambia, ¿cómo manejar la misma situación?

Se puede ver que si crea y cambia, el contenido del almacén, el área de preparación y el espacio de trabajo de la nueva sucursal son los mismos, lo cual es seguro y no se perderán archivos.

Sin embargo, un recordatorio especial aquí es que, ya sea que esté cambiando o creando y cambiando, trate de no operar con contenido modificado. Debido a que las funciones y tareas de diferentes ramas son diferentes, el contenido que modifique en esta rama debe enviarse en esta rama. Si cambia a otra rama, las modificaciones en otras ramas destruirán las modificaciones en la rama anterior. Incluso si se envía en otra sucursal, el área de almacenamiento temporal de la sucursal anterior estará vacía y las modificaciones anteriores no tendrán ningún efecto en esta sucursal.

Por lo tanto, se recomienda desarrollar el hábito de lidiar con todos los cambios antes de cambiar de rama; de lo contrario, podría tener un gran problema.

11.6 Almacenamiento

Pueden ocurrir las siguientes dos situaciones en el trabajo:
1. A veces, solo estamos a la mitad de la modificación de una determinada rama y no queremos enviarla todavía, para que el registro de envío no sea demasiado complicado. Sin embargo, en este momento hay un ERROR que debe solucionarse con urgencia o desea escribir otra parte del código en otra rama.
2. El código que debería haberse escrito en la rama de desarrollo se escribió en la rama maestra. No desea ir a la rama de desarrollo y reescribir, sino mover los cambios escritos en la rama maestra a la rama de desarrollo.

¿Hay alguna manera? Realmente así es, echemos un vistazo a la función de almacenamiento mágico.

11.6.1 Almacenamiento del sitio de trabajo actual

$ git stash	//储藏当前工作现场，不加注释
$ git stash save "注释内容"	//储藏当前工作现场，带注释

11.6.2 Ver el almacenamiento existente

$ git stash list	//查看现有的储藏

11.6.3 Verificar la diferencia entre un determinado elemento de almacenamiento y el contenido actual

$ git stash show	//查看最近的储藏与当前内容的改动概况
$ git stash show -p	//查看最近的储藏与当前内容的具体改动
$ git stash show stash@{0} -p	//查看编号为0的储藏与当前内容的具体改动

11.6.4 Sitio de trabajo restaurado

$ git stash pop stash@{index}	//恢复储藏的工作现场，并删除该储藏记录
$ git stash apply stash@{index}	//恢复储藏的工作现场，但保留该储藏记录

Si no especifica un número y usa $ git stash pop directamente, se restaurará el registro de alijo más reciente.

Nota: No utilice el número de almacenamiento para determinar qué almacenamiento es, porque el número cambiará. Debe juzgarse en función de las ramas y comentarios almacenados.

11.6.5 Eliminar un sitio de trabajo almacenado

$ git stash drop stash@{index}	//删除储藏的工作现场

Si no especifica un número y usa $ git stash drop directamente, se eliminará el registro de alijo más reciente.

11.6.6 Creando una nueva rama desde el repositorio

$ git stash branch newbranch

Nota: No utilice el número de almacenamiento para determinar qué almacenamiento es, porque el número cambiará. Debe juzgarse en función de las ramas y comentarios almacenados.

11.7 Los contenidos de diferentes ramas son independientes.

Las modificaciones realizadas en una sucursal solo son efectivas en la sucursal actual y no tienen ningún efecto en otras sucursales.

Los cambios de cada rama son únicos para esa rama. Si desea que los cambios se apliquen a la rama principal, o si desea actualizar los cambios en la rama principal a la rama actual, debe utilizar la combinación de ramas. Consulte Consulte las dos secciones siguientes para obtener más detalles.
Para los registros de envío de cada sucursal, cuando se crea por primera vez, contendrá todos los registros de envío de la sucursal maestra en ese momento. Pero antes de eso, los registros de confirmación agregados por la rama maestra y cada rama pequeña no se compartirán, a menos que se fusionen con los cambios de cada rama.

11.8 Fusionar otras ramas en la rama actual

$ git merge dev 

Fusione la rama de desarrollo con la rama actual. La rama actual puede ser la rama maestra u otras ramas.
Como mencionamos antes, creamos nuevas ramas con el propósito de dividir el trabajo y cooperar. Generalmente, diferentes ramas son responsables de diferentes módulos funcionales. A veces se crean nuevas ramas para corregir errores o agregar funcionalidad. En cualquier caso, los cambios deben fusionarse nuevamente en la rama maestra.

Otra situación es que durante el proceso de modificación de una determinada rama, los cambios de otras ramas deben actualizarse a la rama actual.
Por ejemplo, durante el proceso de modificación de una determinada rama, si los cambios en la rama principal deben actualizarse a la rama actual, la rama principal debe fusionarse con la rama actual.

Nota: En el proceso de desarrollo colaborativo de varias personas, si desea actualizar los cambios de otros programadores en la rama maestra a la rama actual, primero debe obtener la última versión de la rama maestra en el almacén remoto a la local. y luego fusionarlo.
Si desea enviar cambios al almacén remoto en colaboración entre varias personas, primero debe obtener la última versión maestra, luego fusionar los cambios en la rama actual y finalmente enviarlos al almacén remoto, de lo contrario, la versión de la rama maestra local será más grande que la versión de la rama maestra en el almacén remoto. Antiguo y no se puede enviar.

Todas las fusiones anteriores son ideales y fluidas, pero a veces no lo son.
Debido a que la fusión anterior solo se realizó cuando una sola parte hizo cambios, ¿qué pasaría si ambas partes hicieran cambios?

11.9 Resolución de conflictos al fusionar sucursales

¿Qué pasa si ambas partes cambian distintas partes de un mismo expediente?

Entonces la pregunta es, ¿qué sucede si ambas partes realizan cambios en el mismo lugar del mismo archivo?

Como puede ver, la fusión es realmente conflictiva. Pero cabe señalar que la fusión se ha completado, pero hay conflictos que no se han enviado. En otras palabras, la rama maestra ha fusionado el contenido de la rama de desarrollo, incluido el contenido conflictivo de source1.c.
Entonces, ¿cómo se ve cuando se fusiona el source1.c en conflicto?

Se puede ver que la forma de manejar el conflicto es retener las modificaciones en ambos lados y luego usar identificadores fijos para marcar las modificaciones de diferentes ramas.

"<<<<<<< HEAD" representa la rama actual, no necesariamente la rama principal.
"=======" es el separador
">>>>>>>> dev": representa la rama de desarrollo, que es relativo a la rama actual. Las ramas son otras ramas.

Si envía en este momento, no habrá ningún error, pero el contenido definitivamente no será el que desea. Debido a que la parte en conflicto del archivo contiene los cambios de las dos ramas, también contiene el identificador y el separador de la rama.
Si esto fuera un programa, la compilación definitivamente saldría mal.
Entonces, antes de someternos, primero debemos resolver el conflicto. En el mismo lugar ambas ramas han realizado cambios, debemos elegir uno de los dos cambios y eliminar esos identificadores fijos.
Obviamente, esto sólo se puede solucionar manualmente, porque la máquina no sabe qué cambios desea conservar.
Solución 1: vaya al directorio, abra source1.c y edítelo.

Si, en el conflicto, elegimos el cambio de rama de desarrollo. Luego, eliminaremos la parte tachada de arriba y la guardaremos.

Este es el contenido modificado. Agréguelo al área de preparación y luego envíelo.

Solución 2: en la ventana de comandos de GIT, ábrala con vi o vim editor para editar

$ vim source1.c 或 $ vi source1.c

Después de ejecutar el comando, el editor vim (o vi) abrirá la ventana de source1.c. Este es el modo normal del editor vim, como se muestra arriba.

Después de hacer clic en "i", el editor vim ingresa al modo de inserción (editable), como se muestra arriba.

Después de editar, haga clic en "Esc" para volver al modo normal. Luego ingrese el carácter inglés ":" para ingresar al modo de comando. Ingrese wq (escribir bastante) para guardar y salir, luego agréguelo al área de preparación y envíelo.

11.A Métodos de fusión de uso común

11.A.1 --ff dar–no-ff

$ git merge --ff dev	//使用“Fast forward”（快进）模式合并，默认的，可以不写
$ git merge --no-ff dev	//禁用快进模式

Por lo general, al fusionar ramas, git generalmente usa el modo de "avance rápido". En este modo, solo se fusionan las modificaciones de la rama, es decir, se fusionan los registros de confirmación de la rama fusionada, y luego el HEAD que apunta a la última versión apunta al último registro de confirmación de la rama fusionada. No se crea ninguna confirmación durante este proceso, pero HEAD apunta al último registro de confirmación fusionado.

Por ejemplo, cuando la rama maestra tiene solo dos registros de confirmación, cree una rama de desarrollo. Después de que el desarrollador cambie y confirme 4, combínelo nuevamente con la rama maestra.

La imagen de arriba muestra que la rama de desarrollo se envió 4 veces. La primera vez, el contenido de source1.c se cambió a: 111111111, y cada vez se agregó una línea de números.

La figura anterior muestra que al fusionar, -ff (modo de avance rápido) se usa de forma predeterminada para fusionar las confirmaciones agregadas a la rama de desarrollo y apuntar HEAD a la última confirmación. No se envían nuevas confirmaciones durante la fusión.
Si vuelve a la versión anterior, la versión anterior es la versión anterior de la versión fusionada.
La razón por la que les recuerdo esto es porque si el modo de avance rápido está deshabilitado, es decir, -no-ff, HEAD apunta a la versión enviada durante la fusión. Revertir la versión anterior no es la versión fusionada, sino la versión maestra. rama antes de la fusión.última versión.

Veamos qué diferencia hay al fusionar con –no-ff (desactiva el modo de avance rápido).

Quizás todos puedan ver que la diferencia es exactamente lo que dice el texto anterior.

Sin embargo, me gustaría recordarles que el modo de avance rápido es condicional. Es decir, en comparación con el momento en que se creó la rama, solo la rama fusionada ha cambiado y la rama actual no ha cambiado.
¿Qué sucede si la rama actual tiene cambios antes de fusionarse y aún especificamos -ff (modo de avance rápido)?

Se puede ver que cuando hay cambios en ambos lados, incluso si especifica -ff (modo de avance rápido) para fusionar, es inútil. El sistema todavía usa -no-ff (deshabilitar modo de avance rápido) para fusionar.

En otras palabras, el modo de avance rápido solo es efectivo cuando hay cambios unilaterales en la rama fusionada y tiene sentido usar –ff y –no-ff. De lo contrario, no importa cuál especifique, el sistema utilizará el modo –no-ff para fusionar.
Independientemente de si hay cambios en la rama actual, se recomienda utilizar el modo –no-ff para fusionar. Hay dos beneficios:
1. Habrá nuevos envíos durante la fusión (por supuesto, si hay un conflicto , el sistema no lo enviará automáticamente y debemos resolver el conflicto manualmente (envíe manualmente), sabrá que esta versión se fusionará más adelante al observar los comentarios o el modo gráfico ($ git log -graph).

2. La ruta de reversión de la versión será mucho más limpia, sin tener que preocuparse por los registros de confirmación desordenados en la rama. La fusión es una versión y la reversión de la versión anterior es la versión anterior a la fusión.

11.A.2 --aplastar y rebase

De la combinación anterior, podemos encontrar que ya sea en modo -ff o -no-ff, después de la combinación, los registros de confirmación de la rama fusionada se integrarán en los registros de confirmación de la rama principal. Si el registro de confirmación de la rama fusionada está muy desordenado, el registro de confirmación de la rama principal también quedará muy sucio después de la fusión.
¿Hay alguna forma de tener solo un registro de confirmación más en la rama principal después de la fusión?

Sí, pruebe los dos métodos siguientes.

11.A.2.1 --calabaza

Al fusionar, los registros de envío de las ramas fusionadas no se fusionan, y solo las modificaciones finales de las ramas fusionadas se fusionan en el espacio de trabajo y el área de preparación de la rama actual. No se envía automáticamente después de la fusión y los programadores deben enviarlo manualmente.

El uso es el mismo que –ff y –no-ff, echemos un vistazo al efecto:

se puede ver que después de la fusión, el registro de envío de la rama maestra no se integra con el registro de envío de la rama de desarrollo. y el sistema no inicia automáticamente el envío de la versión fusionada.
Entonces, después de la fusión, podemos enviar manualmente una versión o realizar las modificaciones apropiadas antes de enviarla.
Pero hay otro problema, es decir, no se puede ver ningún rastro de la modificación y fusión de la rama de desarrollo en el registro de envío del maestro. No hay una versión histórica enviada por el desarrollador y no sé qué versión es el cambio combinado de la rama de desarrollo.
Esto no parece nada bueno ¿Hay alguna forma de solucionarlo?

Sí, de hecho todavía se puede hacer así; consulte la siguiente sección.

11.A.2.2 rebase

Rebase puede editar, eliminar, copiar, pegar y fusionar un determinado historial de envío lineal, por lo que el uso razonable del comando rebase puede hacer que nuestro historial de envío sea limpio y conciso.
Por lo tanto, antes de fusionar ramas, podemos usar rebase para derivar los registros de confirmación de las ramas fusionadas en una o varias con cambios importantes.
Generalmente, se puede sintetizar en uno.
Por ejemplo, cree una rama de desarrollo que modifique y envíe unilateralmente el archivo source1.c tres veces.

Si usa el método de fusión general:
Método 1.$ git merge dev (consulte 11.8.1 para más detalles)
La rama maestra no se ha modificado y todo se fusiona en modo de avance rápido (–ff). Se agregarán tres registros de confirmación. al registro de confirmación de la rama maestra, es decir, los tres enviados por la rama de desarrollo.
Método 2.$ git merge --no-ff dev (ver 11.A.1 para más detalles)
Debido a que se especifica que el modo de avance rápido (–no-ff) se fusionará, todos los registros de confirmación de la rama maestra excepto aquellos agregado a la rama de desarrollo Se enviarán tres registros y un registro nuevo, lo que suma un total de cuatro registros.
Método 3.$ git merge --squash dev (ver 11.A.2.1 para más detalles)
Después de la fusión, no hay envío automático de registros. Podemos enviar un registro manualmente. Sin embargo, no hay rastros de modificaciones y fusiones de la rama de desarrollo en el registro de envío de la rama maestra, a menos que se indique claramente en los comentarios.

Entonces, veamos qué sucede si hacemos lo siguiente.

La rama de desarrollo se cambió y envió tres veces. Queremos combinar estas tres confirmaciones en una y luego fusionar las confirmaciones derivadas en la rama principal. Luego, en el registro de confirmación de la rama maestra, el registro combinado indicará claramente que fue modificado y enviado por la rama de desarrollo.
Primero ejecute el comando rebase y especifique la rama maestra actual como línea de base. En otras palabras, sincronice los cambios en la rama maestra y luego edite el registro de cambios de desarrollo en este punto de referencia.
En otras palabras, las modificaciones en la rama maestra después de que se establezca la rama de desarrollo se fusionarán. Luego edite, elimine, copie, pegue y combine todos los registros de confirmación de las modificaciones de la rama actual en esta línea base. Ahora queremos fusionar, es decir, rebase.

Después de ejecutar el comando anterior, aparecerá la siguiente ventana de edición de comandos.

• elegir: mantener el compromiso (abreviatura: p)
• reformular: mantener el compromiso, pero necesito modificar el comentario del compromiso (abreviatura: r)
• editar: mantener la confirmación, pero quiero detener y modificar la confirmación (no solo los comentarios) (abreviatura: e)
• squash: fusiona esta confirmación con la confirmación anterior (abreviatura: s)
• Solución: fusionar esta confirmación con la confirmación anterior, pero no quiero conservar la información del comentario de la confirmación (abreviatura: f)
• ejecutivo: ejecutar comando de shell (abreviatura: x)
• soltar: quiero eliminar este compromiso (abreviatura: d)

Queremos derivarlo en un registro de envío, por lo que solo puede haber un registro de envío, es decir, dejar uno (seleccionar) y usar squash para fusionar los demás.

Mantenga el primer registro de confirmación (porque squash se fusiona con el anterior, por lo que conservamos el primero y puede usar squash para el resto) y use squash para fusionar el resto.

Después de editar el comando, guardar y salir, el sistema procesará los tres envíos uno por uno:
1. Fusionar el primer envío con los cambios sincronizados desde la rama maestra en este momento
2. Fusionar el segundo envío con los resultados anteriores
3. Fusionar las terceras confirmaciones de envío se fusionan con los resultados anteriores

En cada paso anterior, se verifican los conflictos.
Si se conserva el envío (seleccionar, etc.), también se nos pedirá que modifiquemos los comentarios.

Primero se procesa el primer registro y primero se comprueba si hay conflictos.
Si no hay ningún conflicto, ingrese a la ventana de edición de notas para el envío de este registro.

Primero se verifica que cada registro no tenga conflictos. Si no hay conflictos, se ingresa a la ventana de edición de notas. Si hay un conflicto, se detendrá y nos permitirá resolver el conflicto manualmente. Después de resolver el conflicto, debemos agregarlo manualmente (git add) y luego continuar (git rebase --contiune), e ingresaremos a la ventana de edición de la nota del registro. Recuerde, no es necesario comprometerse después de agregar, simplemente continúe. Después de guardar y salir, comience a fusionar el siguiente registro.
La siguiente imagen es la nota para editar el cuarto registro.

Modifique los comentarios relevantes (como recordatorio, está bien modificar todos los comentarios al editar el último). La siguiente imagen muestra la ventana de edición de la última nota. Después de guardar y salir, la rebase se completa. Antes de completar la sugerencia, agregue una nota al frente como nota para este envío de rebase. Cuando vea el registro de envío en una sola línea (git log --pretty=oneline), se mostrará la primera. Si no agrega un comentario general al frente, cuando lo vea en una sola línea (git log --pretty = oneline), se mostrará el comentario del primer registro de confirmación (agregue una línea: 22222), lo cual es obviamente inadecuado.

Tenga en cuenta que ahora solo conservamos (seleccionamos) un registro de envío, por lo que editamos los comentarios de envío solo una vez. Si mantenemos varios registros de envío (selección, etc.), este paso se repetirá varias veces y se escribirán notas para cada envío. Por supuesto, si un determinado envío entra en conflicto durante el proceso, se detendrá. Después de resolverlo, agregarlo y continuar, la ventana de edición de notas para el siguiente envío seguirá apareciendo.

Después de que la rebase sea exitosa, aparecerá el siguiente mensaje: En este punto, el comando de rebase se completa.

Fusionémonos y veamos.

Todas las modificaciones se han fusionado y solo se ha agregado un registro de envío a la rama maestra. Este registro también indica el "autor" del envío de modificación.

Lo anterior se hizo con cambios unilaterales realizados por dev. Entonces, ¿qué pasará si también hay cambios en la rama maestra?

Evidentemente, tras la fusión, no queda más registro. Además, el registro de envío no está en una línea de reversión, a la que algunos amigos no están acostumbrados.
¿Hay alguna forma de solucionarlo?

Sí, hay tres métodos:
1. Primero combine todos los registros de modificación y envío de dev en uno (no use master como base, de lo contrario será muy problemático si el contenido entra en conflicto. Cuantas más modificaciones y envíos de dev, más será más problemático), y luego use git rebase -i master Sincronice los cambios en la rama maestra y finalmente combínelos en la rama maestra.
2. Primero combine los cambios en master con la rama de desarrollo, luego combine los registros de confirmación de modificación de la rama de desarrollo en uno y finalmente combínelos con master. La fusión en este momento se puede realizar en modo de avance rápido. No se enviarán nuevos registros. Solo se fusionará el registro enviado de la rebase de desarrollo.
3. Primero combine todos los registros de envío de modificaciones de dev en uno y luego combine las modificaciones de la rama maestra. Debido a que ambas partes han realizado cambios, esta fusión definitivamente agregará un nuevo registro de confirmación, y todo tendrá que reorganizarse en uno y finalmente fusionarse nuevamente en la rama maestra. (No recomendado)

Se recomienda utilizar el método 1. La versión rebasada (información de registro de git) solo tiene el seguimiento de las modificaciones del desarrollador.
El método 2 también es posible, pero la versión rebasada tiene el rastro del maestro fusionado (el último registro de confirmación es el maestro fusionado).
El método 3 es un poco estúpido, no solo es problemático, sino que también tiene rastros de fusión maestra, no se recomienda.

El método 1 se demuestra a continuación:

11.A Eliminar rama

11.A.1 Eliminar la sucursal en el almacén local

$ git branch –d 分支名称 （如果该分支没有被合并，会出错并提示：The branch '***' is not fully merged.）
$ git branch –D 分支名称（强制删除分支）

11.A.2 Eliminar la sucursal del almacén remoto

$ git push origin --delete 分支名称

12. Enviar al almacén remoto

12.1 Enviar actualizaciones de sucursales locales a hosts remotos

$ git push <远程仓库名> <本地分支名>:<远程分支名>		（与git pull命令相仿）

Tenga en cuenta que el orden de inserción de rama se escribe como <fuente>:<destino>, por lo que git pull es <rama remota>:<rama local> y git push es <rama local>:<rama remota>.

Si se omite el nombre de la sucursal remota, significa que la sucursal local será enviada a la sucursal remota que tiene una "relación de seguimiento" con ella (generalmente ambas tienen el mismo nombre). Si la sucursal remota no existe, se creado.

Si se omite el nombre de la sucursal local, significa que la sucursal remota especificada se elimina, porque esto equivale a enviar una sucursal local vacía a la sucursal remota.

$ git push origin :master

Equivalente a

$ git push origin --delete master

Si la rama actual tiene solo una rama de seguimiento, se puede omitir el nombre de host.

$ git push

Por ejemplo: enviar la rama maestra actual a la biblioteca remota

$ git push –u(第一次要用-u 以后不需要) origin master 

Dado que la biblioteca remota está vacía, cuando insertamos la rama maestra por primera vez, agregamos el parámetro -u. Git no solo enviará el contenido de la rama maestra local a la nueva rama maestra remota, sino que también enviará la rama maestra local a la rama maestra remota. Al asociar la rama maestra, los comandos se pueden simplificar al empujar o tirar en el futuro.

El comando anterior envía la rama maestra local al host Demo_hub y especifica Demo_hub como el host predeterminado. Luego puede usar $git push sin agregar ningún parámetro.

12.2 Independientemente de si hay sucursales remotas correspondientes, envíe todas las sucursales locales al host remoto

$ git push --all origin

13. Obtenga la última versión de forma remota a local

Si la versión en el almacén remoto es más reciente que la versión en el almacén local, puede usar los dos comandos siguientes para extraerla:

$ git fetch origin master	//将远程仓库中master分支的更新拉取到本地，但不合并
$ git pull origin master	//将远程仓库中master分支的更新本拉取到本地，而且自动合并

El uso es similar al push, la operación específica se discutirá en la sección 15.1.3.1.

14. Reversión de versión

14.1 Ver el historial de todas las confirmaciones

$ git log 

Se pueden agregar muchos parámetros después de git log, los más utilizados son los siguientes:
-p: Muestra las diferencias entre cada actualización por parche, que es más completo que el siguiente - comando -stat
-stat: Muestra la información estadística de los modificados archivos de cada actualización. Cada confirmación enumera el archivo modificado, el número de líneas agregadas y eliminadas, y un subtotal de todas las líneas agregadas y restadas al final –abbrev-commit: solo se muestran los
primeros caracteres de SHA-1, en su lugar de los 40 caracteres
–graph: muestra el historial de fusión de ramas representado por gráficos ASCII
–pretty=oneline: visualización de una línea, solo se muestran el valor hash y la descripción de confirmación (–online en sí también se puede usar como un atributo separado)
-n: visualización antes de n registros

14.2 Ver todos los registros de operaciones de todas las sucursales (incluidos los registros de confirmación eliminados y las operaciones de reinicio)

14.3 Vuelva a una versión anterior y todas las versiones enviadas después de esa versión se descartarán.

Puede usar DEAD para especificar la versión de recuperación, o puede usar el número de ID de la versión para especificar la versión de recuperación. Si usa un número de ID de versión, puede ser el número de ID en el registro de confirmación (git log) o el número de ID en el registro de operación (git reflog).

14.3.1 Utilice HEAD para especificar la versión de recuperación

$ git reset --hard HEAD

HEAD: versión actual
HEAD^: versión anterior
HEAD^^: versión anterior
HEAD~100: versión número 100 hasta

14.3.2 Restaurar la versión usando el número de identificación de la versión

$ git reset --hard bf5b760d5a18246d516e7fa62853c6c151623e21

Se puede ver que después de usar el reinicio para restaurar, la versión con el número de identificación "ba36bfe75e5d7b3c275acd2f0b7928801bf98fd0" desapareció.

14.4 Restaurar un archivo a una versión histórica

14.4.1 Restaurar un determinado archivo a una versión histórica y sobrescribirlo nuevamente en el espacio de trabajo actual y el área de almacenamiento temporal

$ git checkout 7a655ee57a031c4387d38e2a9042ea9411dd881c -- source4.c

14.4.2 Restaurar un archivo a una versión histórica y sobrescribirlo nuevamente en el área de almacenamiento temporal actual

$ git reset HEAD -- source1.c

14.5 Deshacer una confirmación (esta versión no es un tipo de combinación), deshacer los cambios en esta versión, pero desea conservar todas las versiones anteriores

git revert deshace una confirmación. Los registros de confirmación (vistos por $ git log) y los registros del historial (vistos por $ git reflog) antes y después del envío se conservarán, y esta revocación se considerará como el último envío.
Git revert consiste en enviar una nueva versión y modificar a la inversa el contenido de la versión que debe revertirse. La versión se incrementará y no afectará la versión enviada antes de git revert.
Por ejemplo: enviamos tres veces antes y el último envío fue para agregar source5.c. Más tarde descubrimos que source5.c era redundante y queríamos cancelar este envío.

Consejo: No solo puedes deshacer el último, sino que también puedes deshacer cualquiera de los registros de confirmación ($ git log para ver) y registros del historial ($ git reflog para ver). La operación es la misma.

Recuerde cambiar al método de entrada en inglés al escribir ":wq", de lo contrario, la ventana de comando parpadeará en blanco al escribir ":" y es posible que no se dé cuenta de que se trata de un problema con los métodos de entrada en chino e inglés. Como no hay otras indicaciones, es posible que no se dé cuenta de cuál es el problema.

Una vez completado, verifique la versión confirmada y encontrará que todas las versiones enviadas anteriormente están allí, pero se ha creado una nueva versión.
Diferencias con el reinicio:
1. Después de usar el reinicio para restaurar a una versión determinada, se borrarán todas las versiones más recientes que esta versión. Después de usar revertir para cancelar el envío de una determinada versión, se conservarán todas las versiones anteriores y se creará una nueva versión.
2. Después de usar restablecer para restaurar a una versión determinada, el contenido será exactamente el mismo que esa versión. Después de usar revertir para deshacer los cambios realizados en una determinada versión del envío, el contenido se modifica de forma inversa según la versión actual. Por ejemplo, esta versión se modifica agregando source5.c. Después de revertir esta versión, el contenido es que source5.c se elimina en la versión actual.

Al mirar el directorio, puede encontrar que source5.c se ha eliminado.

Si desea deshacer las modificaciones enviadas más recientemente, puede usar directamente:

$ git revert HEAD		//HEAD指向最近一次提交

Por ejemplo: hace un momento revocamos el último envío, lo que resultó en la eliminación de source5.c. Más tarde, de repente descubrimos que source5.c todavía es útil, por lo que podemos revocar las modificaciones del último envío. Porque después de revocar la última revocación, también la presentamos, que también es un registro de presentación. Una vez completado, puede volver a hacerlo según este registro de envío.

Descripción de parámetros comunes de $ git revert:

$ git revert --no-edit    //不启动提交消息编辑器，就是不需要写提交备注
$ git revert -n 或 $ git revert --no-commit	//不提交，只是恢复到暂存区

Para conocer otros parámetros de git revert, consulte la documentación oficial: https://git-scm.com/docs/git-revert

15. Tres formas de desarrollo colaborativo entre varias personas

Los proyectos actuales son cada vez más grandes, con cada vez más funciones y requieren un equipo para su desarrollo. Si varios desarrolladores desarrollan un proyecto juntos, ¿cómo colaboran?

Tres formas de desarrollo colaborativo de varias personas en GitHub:

• método de horquilla
• Organización, enfoque de equipo.
• Modo socio

15.1 método de la horquilla

Proceso aproximado:

1. El líder del proyecto construye el almacén original de un proyecto, llamado origen.

El almacén fuente tiene dos funciones:
1. Resumir el código de varios desarrolladores que participan en el proyecto
; 2. Almacenar código estable y liberable. El almacén fuente debe estar protegido y los desarrolladores no deben desarrollarlo directamente. Sólo el director del proyecto puede realizar operaciones de nivel superior en él.

2. Repositorio de fuentes de bifurcación para desarrolladores

Ningún desarrollador operará directamente el almacén de origen. Una vez establecido el almacén de origen, lo que cada desarrollador debe hacer es "copiar" una copia del almacén de origen como almacén para su desarrollo diario. Esta copia es un tenedor.

3. Clonar el almacén bifurcado localmente

4. Cree ramas de funciones para el desarrollo.

5. Envíe una solicitud de extracción al administrador.

Después de haber completado la función de la que es responsable (por supuesto, es posible que haya fusionado su desarrollo varias veces durante el proceso) y después de realizar la prueba, si cree que no hay ningún problema, puede pedirle al administrador que fusione la rama de desarrollo de su propio almacén en la sucursal de desarrollo del almacén de origen en la sucursal.

6. Pruebas y fusión de administradores

El administrador inició sesión en gitlab y vio la solicitud de extracción iniciada por el desarrollador en el repositorio de origen. Lo que el administrador debe hacer es:
1. Revisar el código del desarrollador.
2. Cree una nueva rama de prueba en su prueba local, pruebe el código del desarrollador y determine si acepta fusionarlo con el desarrollo del almacén fuente.

Entre los 6 pasos anteriores, muchos de ellos se han mencionado en los capítulos anteriores, y otros pasos de bifurcación, clonación y solicitud de extracción se mencionarán a continuación.

15.1.1 tenedor

A continuación se muestra el almacén gestionado por el líder del proyecto.

Nadie ha bifurcado (copiado) este almacén todavía. El siguiente desarrollador "kejirenshen" realizará la operación de copia.
Una vez completada la bifurcación, el proyecto estará disponible en el almacén de kejirenshen.

En la lista de almacenes de GitHub, también puedes ver qué almacén se bifurcó.

15.1.2 Clonar el repositorio remoto a local

Clonar consiste en copiar el almacén del almacén remoto al local, incluidas cada sucursal, el registro de envío y todos los archivos. Este es un proceso desde cero, generalmente se realiza cuando se cambia una computadora o se pierde el almacén local.

Pasos de clonación:
1. Asegúrese de que la CLAVE SSH local se haya agregado a la lista de permitidos de github (consulte la Sección 9.3 para obtener más detalles).
2. Haga clic derecho donde desea que se almacene el almacén y abra el cuadro negro de Git Base.
3. Ingrese el comando de clonación.

El formato del comando es el siguiente:

$ git clone <版本库的网址> <本地目录名（可省略）>

como:

方法一（用SSH协议）：$ git clone [email protected]:wuzulie/Demo_hub.git（速度最快）
方法二（用HTTPS协议）：$ git clone https://github.com/wuzulie/Demo_hub.git

La diferencia entre usar SSH y HTTPS:

• Es más conveniente para los principiantes usar la URL https para clonar. Copie la URL https y luego
  use el comando de clonación en git Bash para clonarla localmente. Sin embargo, debe ingresar su cuenta y contraseña cada vez que obtenga y presione el código. Este es también el método https del problema.
• Usar la URL SSH para clonar requiere configurar y agregar la clave SSH antes de la clonación. Por lo tanto, si desea usar la URL SSH para clonar, debe ser el propietario de este proyecto. De lo contrario, no podrá agregar una clave SSH. Además, de forma predeterminada, SSH no requiere que ingrese su cuenta y contraseña cada vez que obtenga y presione el código. Si desea ingresar su cuenta y contraseña cada vez Para buscar y empujar, también puedes configurarlo por separado.

A continuación, se supone que el desarrollador "wuzulie" ha bifurcado el proyecto en su propio repositorio de github y luego puede clonarlo localmente para su desarrollo.

En este punto, el almacén remoto ha sido clonado y se puede realizar el siguiente desarrollo.

Operaciones como ver archivos en el directorio actual (ls -a) y ver registros de confirmación (git log) no son pasos necesarios, solo quiero resaltar los efectos de ciertas operaciones.

Nota:
Si está utilizando la computadora de otra persona, o si no ha configurado un nombre de usuario predeterminado para GIT en su propia computadora, debe configurarlo primero para facilitar la identificación de los envíos de diferentes usuarios.

$ git config --global user.name "wuzulie"			//设置用户名为：wuzulie
$ git config --global user.email "[email protected]"	//设置用户邮箱为：[email protected]

Con este parámetro, significa que todos los almacenes Git en su máquina usarán esta configuración. Por supuesto, también puede especificar diferentes nombres de usuario y correos electrónicos para un determinado almacén. Simplemente elimine –global al configurar. Si es para todos los usuarios en el sistema, uso –sistema.

Además, el origen/maestro de arriba indica qué rama se selecciona de forma predeterminada (es decir, al clonar). Por defecto, origen/HEAD apunta a la rama origen/maestro, como origen/HEAD -> origen/maestro.
La rama remota marcada como rama predeterminada se puede eliminar o modificar.

Al clonar, la rama predeterminada (maestra por defecto) se crea automáticamente localmente. Aunque otras ramas (como dev) no se crean automáticamente, las ramas remotas correspondientes (como origin/dev) se han clonado localmente. Puede crear esta rama y dejar que rastree la rama correspondiente en la rama remota.

$ git branch dev origin/dev			//创建dev分支，同让其跟踪远程的dev分支
$ git checkout -b dev origin/dev	//创建并切换到dev分支，同时让其跟踪远程的dev分支
$ git checkout dev					//如果你确定有这个远程分支，可以直接切换过去，系统会自己创建、切换和跟踪。

Tenga en cuenta que los nombres de los almacenes remotos no siempre son de origen. Si el repositorio local se clona desde un repositorio remoto, el nombre del repositorio remoto predeterminado es origen. Pero si el almacén no está clonado, entonces este nombre se denominará después de que agreguemos el almacén remoto (git remoto add xxx). Generalmente se llama origen. Si lo nombra o lo cambia a otro nombre (como myhub), origen/dev en el comando anterior se cambiará a myhub/dev.

Lo anterior es el proceso de usar la clonación para lograr algo desde cero. Si ya existe un almacén local, pero puede que no sea la última versión, ¿todavía usas la clonación? Consulte la siguiente sección.

15.1.3 Extraer la última versión del almacén remoto

En el desarrollo de colaboración en equipo, todos actualizan constantemente el código en el almacén remoto, por lo que es posible que nuestra versión local no sea la más reciente.
A veces necesitamos obtener la última versión del código:

• Por ejemplo, necesitamos utilizar los resultados de modificación de otros durante el proceso avanzado del que somos responsables.
• Para otro ejemplo, si queremos enviar los resultados de modificación de la rama actual al almacén remoto, primero debemos obtener la última versión en el almacén remoto y fusionarla localmente con la rama actual, y luego enviarla. Si presiona directamente, es muy probable que otros colegas hayan actualizado varias versiones antes que usted. La versión que está modificando actualmente es anterior a la versión en el almacén remoto actual y se producirá un error al presionar. Si fuerza la inserción, se sobrescribirán las modificaciones de otras personas, lo que causará grandes problemas.

Revise las instrucciones para retirar del almacén remoto:

$ git fetch origin master	//将远程仓库中master分支的更新拉取到本地，但不合并
$ git pull origin master	//将远程仓库中master分支的更新本拉取到本地，而且自动合并

Supongamos que desde la última vez que se clonó localmente el repositorio remoto, otros colegas han enviado una versión actualizada al repositorio remoto. En este momento, si queremos obtener la última versión localmente, debemos seguir las dos instrucciones anteriores.

15.1.3.1 tirar

Si la fusión automática de pull causa un conflicto y no desea resolver el conflicto y desea cancelar la fusión, puede usar:

$ git merge --abort	//取消合并

Sin embargo, la fusión generalmente no se cancela, sino que se resuelven los conflictos, se agregan envíos y luego el repositorio local se actualiza al estado más reciente.

15.1.3.2 buscar

Antes de fusionar, también puede verificar los cambios de las actualizaciones extraídas a la versión actual:

Después de la búsqueda, puede fusionar de las dos maneras siguientes:

1.$ git merge FETCH_HEAD	//将FETCH_HEAD指向的版本合并到当前分支
2.$ git merge origin/master	//将远程仓库的master分支合并到当前分支

Sin embargo, FETHC_HEAD no necesariamente apunta a la rama maestra del almacén remoto, ¿cómo determinarlo?

La clave para comprender la recuperación es comprender FETCH_HEAD. FETCH_HEAD se refiere a: el estado más reciente de una determinada rama en el servidor.
En términos generales, hay dos situaciones:
1. Si la rama remota no se especifica explícitamente, el maestro de la rama remota se utilizará como FETCH_HEAD predeterminado.
2. Si se especifica una rama remota, utilice esta rama remota como FETCH_HEAD.

Hay cuatro formas de utilizar git fetch:

1.$ git fetch

En realidad, este paso realiza dos operaciones clave:
1. Crear y actualizar sucursales remotas locales de todas las sucursales remotas.
2. Configure FETCH_HEAD de la rama actual en la rama maestra del servidor remoto (el primer caso mencionado anteriormente).

Cabe señalar que: a diferencia de push, fetch obtendrá automáticamente la rama remota "recién agregada".

2.$ git fetch origin

Igual que el anterior, excepto que el control remoto se especifica manualmente como origen.

3.$ git fetch origin master

Establezca FETCH_HEAD de la rama actual en la última versión de la rama maestra del servidor remoto.

Este comando también se puede utilizar para probar si existe una rama remota del host remoto. Si existe, devuelve 0. Si no existe, devuelve 128 y genera una excepción.

4.$ git fetch origin master:dev

Esto significa actualizar la rama maestra del almacén remoto a la rama de desarrollo local, pero no cambiar allí. Si la rama de desarrollo local no existe, se creará automáticamente.

git fetch origin :dev
es equivalente a:
git fetch origin master:dev

15.1.4 El proceso de modificación y envío al almacén remoto

Supongamos que la colaboración del proyecto acaba de comenzar, la versión inicial se guarda en el almacén remoto y cada programador comienza su propia parte responsable.

15.1.4.1 Modificación y envío de xiaming (no estándar)

Después de que Xiaming completa la modificación y el envío, solo se cambia la rama de desarrollo local. Si quiere actualizar esta modificación a la rama maestra del almacén remoto, ¿qué debe hacer?

Algunos amigos pueden decir que es muy simple: simplemente combine las modificaciones de la rama de desarrollo en la rama maestra y luego empújela hacia arriba, de la siguiente manera: empújela hacia arriba y vea qué cambios sucederán

en el almacén remoto.

Después de hacer clic en el registro de envío, podrá ver los detalles de este envío.

En este punto, la versión modificada de xiaming se ha actualizado al almacén remoto y otros colegas pueden verla y usarla.

El proceso de operación anterior parece estar bien, pero en realidad la operación es muy irregular.
1. La última versión en el almacén remoto no se extrae ni se fusiona localmente antes de enviarla. Si hay una versión más nueva en el almacén remoto, se producirá un error.
2. Solo se envía la rama maestra y no se envían los registros relevantes de la rama de desarrollo. Revisemos los registros de la rama de desarrollo en el almacén remoto:

más tarde, Xiaming descubrió este problema e hizo un impulso adicional:


se complementaron los registros de la rama de desarrollo. Sin embargo, debe tenerse en cuenta que la operación de inserción anterior solo se realiza con éxito cuando otros colegas no han actualizado el registro de desarrollo. Si la rama de desarrollo se ha actualizado, la inserción fallará. Si fuerza el push (git push origin dev --force), se sobrescribirán las actualizaciones de otros colegas. A menos que primero extraiga la rama localmente, combínela y luego empújela.

En resumen, la operación de Xiaming de modificar e impulsar nuevas versiones es muy irregular. Entonces, ¿cuál debería ser el proceso operativo estandarizado? Echemos un vistazo a la operación de xiahua en la siguiente sección:

15.1.4.2 Modificación y envío de xiahua (especificación)

El envío fue exitoso, echemos un vistazo a los cambios en el almacén remoto:

en resumen, la operación estándar de modificación y actualización al almacén remoto es:

• 1. Clonar el repositorio remoto al local
• 2. Desarrollar en desarrollo local u otras sucursales.
• 3. Extraiga actualizaciones del repositorio remoto y combínelas en la rama maestra local
• 4. Derive todos los registros de modificación local en un solo registro.
• 5. Sincronice las actualizaciones de la rama maestra con los registros de rebase de la rama de desarrollo
• 6. Fusionar la rama de desarrollo sincronizada con la rama maestra
• 7. Empuje la rama maestra fusionada y la rama de desarrollo al almacén remoto

El primer paso se utiliza cuando se obtiene el archivo del proyecto por primera vez. En el desarrollo posterior, los pasos 2 a 7 se repetirán continuamente.
Por lo tanto, las instrucciones comúnmente utilizadas son:

$ git checkout dev				//切换分支
$ git pull origin				//拉取远程仓库的更新
$ git rebase -i HEAD~n			//编辑最近n条提交记录，一般是衍合成一条
$ git rebase -i master			//同步master分支上的更新，并编辑master之外的所有记录
$ git merge dev					//合并dev分支到当前（master）分支
$ git push origin master(或dev)	//推送master分支和dev分支到远程仓库

15.1.5 solicitud de extracción

15.2 Método de socio

15.2.1 Agregar colaboradores

Primero abra el almacén que necesita desarrollarse cooperativamente y podrá agregar colaboradores en "Configuración". Puede agregarlo ingresando su nombre de usuario o dirección de correo electrónico.
Actualmente, la biblioteca privada de la cuenta personal gratuita de GitHub solo puede agregar 3 colaboradores, si desea agregar más colaboradores, debe usar una cuenta paga o usar una biblioteca pública como código abierto.

Después de hacer clic en "Agregar colaborador", el invitado recibirá un correo electrónico de invitación con un enlace, que podrá aceptar o rechazar haciendo clic en el enlace.
El que invita también puede hacer clic en "copiar enlace de invitación" en la imagen siguiente para copiar el enlace de invitación y enviárselo al invitado, quien puede aceptarlo o rechazarlo después de hacer clic en él.

Una vez que el invitado esté de acuerdo, el repositorio se agregará a su lista de repositorios de github.

15.2.2 Proceso de colaborador

El proceso de desarrollo posterior es el mismo que el método de bifurcación, excepto que no se utiliza "solicitud de extracción". Consulte las Secciones 15.1.2-15.1.4 para conocer el proceso de operación específico.

15.3 Organización y enfoque de equipo

15.3.1 Crear una organización

Haga clic en el signo "+" en la esquina superior derecha de github y luego haga clic en "Nueva organización".

Paso 1, complete la información relacionada con la organización.


Si elige el tipo pago, también deberá completar el método de pago y otra información, no es necesario completar el tipo gratuito.

Una vez completado el paso 1, ingrese el paso 2.

Paso 3, investiga un poco, no es necesario y puedes omitirlo.


En este punto, la organización se crea con éxito.

15.3.2 Agregar y eliminar almacenes a la organización

15.3.2.1 Agregar un almacén a la organización

15.3.2.2 Eliminar un repositorio en una organización

Si desea eliminar un almacén, el método es el mismo que el de un almacén normal.

Luego, desplácese hasta el final de la página.

15.3.3 Agregar miembros a la organización

Cuando aparezca la ventana de invitación, ingrese su nombre de usuario o correo electrónico para invitar.

Establezca el rol de este miembro.

El usuario recibirá un correo electrónico de invitación con una URL adjunta, y podrá aceptarla o rechazarla luego de ingresar.
Una vez que la otra parte lo acepte, se unirá a su organización, como se muestra a continuación.

Si quieres eliminar a un miembro del equipo, es aún más fácil, simplemente haz clic en la cruz de la imagen de arriba.

15.3.4 Crear equipos para organizaciones

Complete la información relacionada con el equipo.

Después de una creación exitosa, como se muestra a continuación.

También podrás visualizarlo ingresando a la organización a la que pertenece el equipo.

Si el equipo es responsable de muchas tareas, también se puede dividir en equipos. Por ejemplo, el equipo de "sistema de aviónica" también se puede dividir en equipos como "sistema de control de vuelo", "sistema de visualización", "sistema de comunicación" y "sistema de radar", todos los cuales son gestionados por el equipo de "sistema de aviónica". .
Al crear un subequipo, solo necesita seleccionar el equipo principal al crear. Los otros pasos no son diferentes de los anteriores. Si hace clic en Nuevo dentro del equipo principal, ni siquiera necesita seleccionar el equipo principal.

15.3.5 Agregar un repositorio al equipo

Complete el nombre del almacén.

15.3.6 Establecer permisos de equipo

Las descripciones de los cinco permisos están todas en inglés. Si no las comprende, tradúzcalas.

15.3.7 Agregar y eliminar miembros del equipo

15.3.7.1 Agregar miembros del equipo

A continuación habrá un recordatorio.

Después de agregar, GitHub enviará un correo electrónico de notificación a la persona agregada. Este proceso de adición no requiere el consentimiento de la persona que se agrega, porque el usuario ya es miembro de la organización y el administrador tiene derecho a decidir qué equipo agregar.

Luego, el equipo y el almacén del equipo también se pueden ver en la página de inicio de GitHub de la persona que se agrega.

15.3.7.2 Eliminar miembros del equipo

Seguirá un recordatorio.

15.3.8 Establecer permisos para los miembros del equipo

Puede utilizar el método de la sección anterior, primero marque la casilla y luego haga clic en "cambiar función" en el menú desplegable para establecer permisos.

También puede hacer clic en el nombre del miembro para ingresar a la página del miembro o establecer roles, es decir, permisos.


Después de cambiar los permisos, el miembro recibirá un correo electrónico de notificación.

15.3.9 Desarrollo del equipo

Cada miembro puede ver el repositorio del equipo en su propio github, puede clonar el repositorio localmente y luego comenzar a escribir el código del que es responsable.
A continuación, cada miembro del equipo puede desarrollar de la manera habitual. El proceso de desarrollo es el mismo que el método fork, excepto que no hay necesidad de "solicitud de extracción". Para conocer el proceso de operación específico, consulte las Secciones 15.1.2-15.1. .4.

15.3.A Discutir las funciones de comunicación.

Después de enviar el contenido, cada miembro recibirá un correo electrónico de la siguiente manera:

Cada miembro también puede verlo en las "Discusiones" del equipo de github y puede participar en discusiones e intercambios aquí.

Por supuesto, la cena nocturna fue solo una broma y el contenido discutido aquí está relacionado con el proyecto. Aunque las discusiones se pueden realizar usando WeChat, QQ, etc., aquí se recomiendan algunas discusiones importantes. Porque si lo discutimos aquí, los registros de discusión se pueden guardar en github junto con el almacén como datos del proyecto para verlos fácilmente más adelante.

En este punto, el contenido relacionado con git casi se ha presentado. Los amigos interesados ​​pueden obtener más información sobre Gitlab. Además, también puede aprender software de herramientas auxiliares relacionadas con git, como GitHub Desktop y Gitflow.