uso de la herramienta git: administración de sucursales

uso de la herramienta git – administración de sucursales

rama de entendimiento

La administración de sucursales es una de las características principales de Git. Branch: Es el universo paralelo de la ciencia ficción, cuando estás aprendiendo C++ frente a la computadora, otro estás aprendiendo Java en otro universo paralelo. Si los dos universos paralelos no interfieren entre sí, no tendrá ningún efecto sobre ti ahora. Sin embargo, en algún momento, los dos universos normales se fusionaron y, como resultado, aprendiste tanto C++ como Java.

En la reversión de la versión, ya sabe que para cada confirmación, Git las encadena en una línea de tiempo, que puede entenderse como una rama. Hasta ahora, en Git, esta rama se llama la rama principal, que es masterla rama.

Entendamos de nuevo HEAD. Estrictamente hablando, HEAD no apunta al envío, sino que apunta master,masteral envío. Por lo tanto, HEAD apunta a la rama actual.

Cada vez que envíe, masterla rama avanzará una vez, de modo que a medida que continúe enviando, masterla línea de la rama se hará cada vez más larga, y HEAD masterpuede apuntar a la rama actual siempre que siga apuntando a la rama.

Podemos usar git log para verificar:

[Lxy@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/master
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master 
7804665c14faf8e894e023f04576ba6b17632f85
[Lxy@aliyun gitcode]$ git log
commit 7804665c14faf8e894e023f04576ba6b17632f85
Author: Lxy <2357246060@qq.com>
Date:   Mon Jun 26 13:48:27 2023 +0800

    delete file1

crear rama

Git nos apoya para ver o crear otras ramas, aquí creamos nuestra primera rama dev, el comando correspondiente es:

Ver todas las sucursales locales actuales

git branch

* indica que HEADla rama a la que se apunta actualmente es masteruna rama.

[Lxy@aliyun gitcode]$ git branch
* master

crear nueva sucursal

git branch dev # 新建分支dev

[Lxy@aliyun gitcode]$ git branch dev
[Lxy@aliyun gitcode]$ git branch
  dev
* master

Cuando creamos una nueva rama, Git crea un nuevo puntero llamado dev, una vez que se completa la creación, lo usamos git branchpara ver la rama actual.

Alternativamente, las nuevas sucursales se pueden ver a través de la estructura del directorio:

[Lxy@aliyun gitcode]$ tree .git/refs/heads/
.git/refs/heads/
├── dev
└── master

0 directories, 2 files
[Lxy@aliyun gitcode]$ ls .git/refs/heads/
dev  master
[Lxy@aliyun gitc

Discovery ahora dev和masterapunta a la misma modificación. Y también puede verificar que HEAD esté apuntando actualmente a master.

cambiar de rama

Ahora que se ha creado con éxito una nueva rama dev, ¿cómo cambiar a devla rama para el desarrollo? El cambio se puede hacer con git checkoutel comando:

[Lxy@aliyun gitcode]$ git checkout dev
Switched to branch 'dev'
[Lxy@aliyun gitcode]$ git branch
* dev
  master
[Lxy@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/dev

En este punto, HEADse ha señalado a dev, lo que significa que hemos cambiado con éxito a ¡ devarriba! A continuación, devmodifique ReadMeel archivo en la rama, agregue una línea de contenido y realice una operación de confirmación.

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "modify ReadMe"
[dev 2690f7f] modify ReadMe
 1 file changed, 2 insertions(+)
[Lxy@aliyun gitcode]$ git status
# On branch dev
nothing to commit, working directory clean

Ahora que devel trabajo de la rama está hecho, podemos volver a masterla rama:

[Lxy@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

Después de volver a masterla rama, ¡descubrí que ReadMeel nuevo contenido del archivo había desaparecido! ! vamos a devrecortar

[Lxy@aliyun gitcode]$ git checkout dev
Switched to branch 'dev'
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

En devla sucursal, el contenido sigue ahí, ¿por qué ocurre este fenómeno? Echemos un vistazo a devla rama y masterla rama apuntando nuevamente, y encontremos que las confirmaciones a las que apuntan los dos son diferentes:

[Lxy@aliyun gitcode]$ cat .git/refs/heads/dev 
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master 
7804665c14faf8e894e023f04576ba6b17632f85

[Lxy@aliyun gitcode]$ git cat-file -p 2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
tree 68c0c174cb2cbb0258f1979bfa92ff0fe06ec5d6
parent 7804665c14faf8e894e023f04576ba6b17632f85
author Lxy <2357246060@qq.com> 1689396001 +0800
committer Lxy <2357246060@qq.com> 1689396001 +0800

modify ReadMe

Al ver esto, podemos entender, porque enviamos deven la rama, y ​​el punto de envío de la rama maestra no ha cambiado en este momento, el estado en este momento se muestra en la figura:

Cuando cambias a masterla rama, HEAD la señala mastery, por supuesto, no puedes ver la confirmación.

fusionar rama

Para masterver nuevas confirmaciones en la rama maestra, devla rama debe fusionarse con masterla rama, como se muestra en el siguiente ejemplo:

[Lxy@aliyun gitcode]$ git checkout master #切换到master上进行合并
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge dev # 合并dev分支
Updating 7804665..2690f7f
Fast-forward
 ReadMe | 2 ++
 1 file changed, 2 insertions(+)
[Lxy@aliyun gitcode]$ cat ReadMe # 发现已经成功了
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

git mergeEl comando se utiliza para fusionar la rama especificada en la rama actual. Después de la fusión, masterpuede ver devel contenido de la confirmación de la rama.

[Lxy@aliyun gitcode]$ cat .git/refs/heads/master 
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/refs/heads/dev 
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/master

El diagrama de estado en este momento es el siguiente:

Fast-forwardSignifica "modo de avance rápido", es decir, apunta directamente mastera la confirmación actual de dev, por lo que la velocidad de fusión es muy rápida. Por supuesto, no se pueden realizar todas las fusiones Fast-forward.

eliminar rama

Una vez que se completa la fusión, devla rama no nos sirve, por lo que devla rama se puede eliminar. Tenga en cuenta que si actualmente se encuentra en una determinada rama, no puede eliminar la rama actual , como:

[Lxy@aliyun gitcode]$ git branch -d dev
Deleted branch dev (was 2690f7f).
[Lxy@aliyun gitcode]$ tree .git/refs/heads/
.git/refs/heads/
└── master

0 directories, 1 file

El estado en este momento se muestra en la siguiente figura:

Debido a que crear, fusionar y eliminar ramas es muy rápido, Git nos anima a usar ramas para completar una determinada tarea y luego eliminar la rama después de la fusión. Esto es lo mismo que mastertrabajar directamente en la rama, pero el proceso es más seguro.

fusionar conflicto

Sin embargo, en la fusión de ramas real, no es posible fusionar con éxito si desea fusionar A veces podemos encontrar conflictos de código. Para demostrar este problema, creamos una nueva rama dev1y cambiamos a la rama de destino, podemos usar git checkout -b dev1un paso para completar la acción de crear y cambiar.

[Lxy@aliyun gitcode]$ git checkout -b dev1
Switched to a new branch 'dev1'
[Lxy@aliyun gitcode]$ git branch 
* dev1
  master

dev1Modifique el archivo bajo la rama , ReadMecambie el contenido del archivo de la siguiente manera y realice una confirmación:

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

I am Coding in dev1......   #新增内容
[Lxy@aliyun gitcode]$ git add .  #提交修改
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe" 
[dev1 50ba571] md ReadMe
 1 file changed, 2 insertions(+)

Cambie a mastery observe ReadMeel contenido del archivo:

[Lxy@aliyun gitcode]$ git checkout master  #切换至master分支
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git branch 	#查看当前所有分支
  dev1
* master
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

Descubrimos que después de volver a cambiar, el contenido del archivo volvió a ser la versión anterior, lo cual estaba en línea con nuestras expectativas, y ahora podemos entenderlo. En este momento, en masterla sucursal, ReadMehacemos otra modificación al archivo y lo enviamos, de la siguiente manera:

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!


i am Coding in master ......
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[master a8d6985] md ReadMe
 1 file changed, 3 insertions(+)

Ahora, mastertanto la rama como dev1la rama tienen sus propias confirmaciones nuevas que se ven así:

En este caso, Git solo puede intentar fusionar los cambios respectivos, pero dicha fusión puede tener conflictos, como se muestra a continuación:

[Lxy@aliyun gitcode]$ git merge dev1 #合并dev1到master
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[Lxy@aliyun gitcode]$ git status  #查看当前状态
# On branch master
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#	both modified:      ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")

Después de encontrar ReadMeun conflicto de archivos, puede ver directamente el contenido del archivo. Lo que quiero decir es que Git usará <<<<<<<,=============,>>>> >>>>>>> >>> para marcar el contenido conflictivo de diferentes ramas, como se muestra en la siguiente figura:

[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

<<<<<<< HEAD

i am Coding in master ......
=======
I am Coding in dev1......
>>>>>>> dev1

En este momento, tenemos que ajustar manualmente el código en conflicto y debemos enviar el resultado modificado nuevamente (es muy importante enviarlo nuevamente, no lo olvide)

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

i am Coding in master ......
I am Coding in dev1.....
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[master 832d4a2] md ReadMe

El conflicto se resuelve aquí, y el estado en este momento se vuelve

También puede ver el proceso de fusión de sucursales con git log con parámetros

[Lxy@aliyun gitcode]$ git log --graph --pretty=oneline --abbrev-commit
*   832d4a2 md ReadMe
|\  
| * 50ba571 md ReadMe
* | a8d6985 md ReadMe
|/  
* 2690f7f modify ReadMe
* 7804665 delete file1
* 2f86525 第三次修改ReadMe
* 02716a9 修改ReadMe
* 0c3e2b8 add file2
* cfd11ac add file
* 3b64204 add first file

Finalmente, no olvide que dev1la rama se puede eliminar después de su uso:

[Lxy@aliyun gitcode]$ git branch
  dev1
* master
[Lxy@aliyun gitcode]$ git branch -d dev1
Deleted branch dev1 (was 50ba571).
[Lxy@aliyun gitcode]$ git branch
* master

estrategia de gestión de sucursales

Por lo general, al fusionar ramas, Git toma Fast forwardel patrón si es posible. En este Fast forwardmodo, después de eliminar la sucursal, al ver el historial de la sucursal, la información de la sucursal se perderá y es imposible ver si el último envío se realizó mergeo se envió normalmente.

Pero en la parte del conflicto de fusión, también vemos que al resolver el problema del conflicto, se realizará una nueva presentación y el estado final obtenido es:

Entonces esto no es Fast forwardun patrón, la ventaja de esto es que la información de la sucursal se puede ver desde el historial de la sucursal. Por ejemplo, ahora hemos eliminado dev1la rama creada en la parte del conflicto de fusión, pero aún podemos ver masterque en realidad fue fusionada por otras ramas:

[Lxy@aliyun gitcode]$ git branch #查看当前分支
* master
[Lxy@aliyun gitcode]$ git branch dev1 #创建dev1分支
[Lxy@aliyun gitcode]$ git checkout dev1 #切换到dev1分支
Switched to branch 'dev1'
[Lxy@aliyun gitcode]$ git branch 
* dev1
  master
[Lxy@aliyun gitcode]$ vim ReadMe  #修改ReadMe文件
[Lxy@aliyun gitcode]$ git add .   #提交修改
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev1 f41d236] md ReadMe
 1 file changed, 3 insertions(+)
[Lxy@aliyun gitcode]$ git checkout master #切换到master分支
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge --no-ff -m "merge dev1" dev1 #将dev1分支使用no-ff方式合并到master分支
Merge made by the 'recursive' strategy.
 ReadMe | 3 +++
 1 file changed, 3 insertions(+)
[Lxy@aliyun gitcode]$ cat ReadMe #查看ReadMe文件内容
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

i am Coding in master ......
I am Coding in dev1.....


I am Coding in dev1..................
[Lxy@aliyun gitcode]$ git log --graph --abbrev-commit #查看日志信息
*   commit 9c17f2d
|\  Merge: 832d4a2 f41d236
| | Author: Lxy <2357246060@qq.com>
| | Date:   Sun Jul 16 18:21:49 2023 +0800
| | 
| |     merge dev1 #这里能够看到合并的信息
| |   
| * commit f41d236
|/  Author: Lxy <2357246060@qq.com>
|   Date:   Sun Jul 16 18:20:46 2023 +0800
|   
|       md ReadMe
|    
*   commit 832d4a2
|\  Merge: a8d6985 50ba571
| | Author: Lxy <2357246060@qq.com>
| | Date:   Sat Jul 15 13:10:06 2023 +0800
| | 
| |     md ReadMe
| |   
| * commit 50ba571
| | Author: Lxy <2357246060@qq.com>
| | Date:   Sat Jul 15 12:59:18 2023 +0800
| | 
| |     md ReadMe
| |   
* | commit a8d6985
|/  Author: Lxy <2357246060@qq.com>
|   Date:   Sat Jul 15 13:05:11 2023 +0800
|   
|       md ReadMe
|  
* commit 2690f7f
| Author: Lxy <2357246060@qq.com>
| Date:   Sat Jul 15 12:40:01 2023 +0800

Git nos apoya para forzar el Fast forwordmodo deshabilitado, luego mergese generará uno nuevo en ese momento commit, para que la información de la sucursal se pueda ver desde el historial de la sucursal.

Explicar:

--no--ffEl parámetro indica el Fast forwardmodo deshabilitado. Fast forwardDespués de que el modo deshabilitado se fusione y se cree uno nuevo commit, agregue -mel parámetro y escriba la descripción. Después de la fusión, puede ver la rama histórica:

git log --graph --pretty=oneline --abbrev-commit

Sin usar Fast forwardun patrón, mergela publicación se ve así:

Por lo tanto, al fusionar ramas, --no-ffpuede usar el modo normal para fusionar agregando parámetros. El historial fusionado tiene ramas. Se puede ver que la fusión se ha realizado, pero no se puede ver fast forwardque la fusión se haya realizado.

estrategia de sucursal

En el desarrollo real, debemos seguir varios principios básicos para la gestión de sucursales:

En primer lugar, masterla rama debe ser muy estable, es decir, solo necesitamos lanzar nuevas versiones, y generalmente no podemos trabajar en ella: por lo tanto, generalmente desarrollamos en la devrama, es decir, devla rama es inestable, y en algún momento, por ejemplo, cuando se lanza la versión 1.0, la devrama se fusiona con masterla anterior y masterse lanza la versión 1.0 en la rama.

Por lo tanto, todos tienen su propia rama, y ​​es suficiente fusionarse con la rama de desarrollo de vez en cuando. Así que la rama de trabajo en equipo se ve así:

rama de bicho

Si estamos dev2desarrollando en una rama ahora, a la mitad del desarrollo, de repente encontramos que masterhay un error en la rama que debe resolverse. En Git, cada uno bugse puede arreglar creando una nueva rama temporal, después de la corrección, la rama se fusiona y luego se elimina la rama temporal. Pero el dev2código actual generalmente se desarrolla en el espacio de trabajo y no se puede enviar. Git proporciona git stashcomandos para almacenar la información del espacio de trabajo actual, y el contenido almacenado se puede restaurar en un momento determinado en el futuro.

[Lxy@aliyun gitcode]$ git branch dev2 #创建dev2分支
[Lxy@aliyun gitcode]$ git checkout dev2 #切换至dev2分支
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ vim ReadMe  #修改ReadMe文件
[Lxy@aliyun gitcode]$ cat ReadMe  #查看ReadMe文件
hello git
hello world
hello ReadMe

I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git checkout master  #切换至master
M	ReadMe
Switched to branch 'master'
[Lxy@aliyun gitcode]$ cat ReadMe  #查看ReadMe文件
hello git
hello world
hello ReadMe

I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git status  #查看状态
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
[Lxy@aliyun gitcode]$ git checkout dev2
M	ReadMe
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ git stash #储存文件
Saved working directory and index state WIP on dev2: 9c17f2d merge dev1
HEAD is now at 9c17f2d merge dev1
[Lxy@aliyun gitcode]$ git status #再查看状态
# On branch dev2
nothing to commit, working directory clean
[Lxy@aliyun gitcode]$ cat ReadMe  #再次查看master的ReadMe文件内容发现恢复到之前
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

i am Coding in master ......
I am Coding in dev1.....


I am Coding in dev1..................

Con git statusun espacio de trabajo de vista, está limpio (a menos que sea de su propiedad, no hay archivos administrados por Git), por lo que se pueden crear sucursales con confianza para corregir errores.

Después de almacenar el espacio de trabajo dev2, dado que estamos masterbasados ​​en ramas, cree una rama temporal para corregir errores.

[Lxy@aliyun gitcode]$ git checkout master #切回master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git checkout -b fix_bug #新建并切换到fix_bug分支
Switched to a new branch 'fix_bug'
[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am fixing bug .........             #修复bug
[Lxy@aliyun gitcode]$ git add .       #重新add commit
[Lxy@aliyun gitcode]$ git commit -m "fix bug"
[fix_bug 76fef0d] fix bug
 1 file changed, 1 insertion(+), 7 deletions(-)

Una vez completada la reparación, cambie a masterla rama, complete la fusión y, finalmente, elimine fix_bugla rama:

[Lxy@aliyun gitcode]$ git merge --no-ff -m "merge fix_bug" fix_bug
Merge made by the 'recursive' strategy.
 ReadMe | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am fixing bug .........

Hasta ahora, se ha realizado el trabajo de corrección de errores, continuaremos volviendo a dev2la rama para el desarrollo, volvamos a dev2la rama:

[Lxy@aliyun gitcode]$ git checkout dev2
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean

¿El espacio de trabajo está limpio? ? ? ¿Adónde fue nuestro sitio de trabajo hace un momento? Puede usar git stash listel comando para ver

[Lxy@aliyun gitcode]$ git stash list
stash@{
    
    0}: WIP on dev2: 9c17f2d merge dev1

El sitio de trabajo todavía está allí. Git ha almacenado stashel contenido en algún lugar, pero necesita ser restaurado. ¿Cómo restaurar el sitio? Podemos usar git stash popel comando para restaurarlo y stasheliminarlo al mismo tiempo:

[Lxy@aliyun gitcode]$ git stash pop
# On branch dev2
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{
    
    0} (c6b7e92f49a38afc1461bcedbaa558aa7ecd0500)
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

I am Codeing in dev2............

Al verificar nuevamente, hemos encontrado que no hay una escena para restaurar

[Lxy@aliyun gitcode]$ git stash list
[Lxy@aliyun gitcode]$ 

Además, la recuperación también se puede usar en el sitio de recuperación git stash apply , pero después de la recuperación, stashel contenido no se elimina, debe git stash dropusarlo para eliminarlo. Puede ocultar varias veces. Al restaurar, primero use ``git stash list 查看，然后恢复指定的stash ，用命令git stash apply stash@{0}` para restaurar el código y luego podemos continuar para completar el desarrollo. Una vez que se completa el desarrollo, podemos enviarlo . Por ejemplo:

[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev2 477994a] md ReadMe
 1 file changed, 1 insertion(+), 9 deletions(-)

Pero hemos notado que el contenido de las correcciones de errores no se dev2muestra en el sitio web. El diagrama de estado en este momento es:

masterLa última confirmación actual de la rama está por delante de la confirmación de la rama dev2en la que se creó. masterEntonces, por supuesto, dev2no podemos ver el código relevante para corregir el error en . Nuestro objetivo final es masterfusionar dev2sucursales, por lo que, en circunstancias normales, podemos mastervolver a las sucursales y fusionarnos directamente, pero esto en realidad tiene ciertos riesgos. Es porque puede haber conflictos al fusionar ramas y los conflictos de código deben resolverse manualmente (en masterInternet). No podemos garantizar que los conflictos se puedan resolver correctamente al mismo tiempo, porque en los proyectos prácticos, los conflictos de código son más que solo uno. o dos líneas. Simple, puede haber decenas de cientos de líneas, o incluso más, y es inevitable que se cometan errores durante el proceso de solución, lo que resultará en la fusión del código incorrecto con el anterior. El estado en este momento masteres :

Una buena sugerencia para resolver este problema es que es mejor fusionar el maestro en su propia rama ahora y luego dejar que el maestro fusione dev. El propósito de esto es que los conflictos se pueden resolver y probar en la rama local sin afectar al maestro. .

El estado en este momento es:

La operación real correspondiente se muestra como: (Cabe señalar que la operación de combinación que se muestra a continuación no se usa --no-ff, pero la ilustración anterior se Fast forwardobtiene después de que el modo está desactivado, principalmente por la conveniencia de explicar el problema).

[Lxy@aliyun gitcode]$ git branch #查看当前分支
  dev1
* dev2
  fix_bug
  master
[Lxy@aliyun gitcode]$ git merge master  #合并master分支到dev2
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[Lxy@aliyun gitcode]$ cat ReadMe  #查看代码
hello git
hello world
hello ReadMe

<<<<<<< HEAD
I am Codeing in dev2............
=======
git --version

I am fixing bug .........
>>>>>>> master
[Lxy@aliyun gitcode]$ vim ReadMe #修改代码
[Lxy@aliyun gitcode]$ cat ReadMe #再次查看
hello git
hello world
hello ReadMe

I am Codeing in dev2.........
git --version 
bug is fixed .........
[Lxy@aliyun gitcode]$ git add . #add 并且 commit
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev2 8bdc3c9] md ReadMe

Hasta ahora, dev2el código anterior no necesita resolución de conflictos, podemos dev2volver a maestro y fusionar

[Lxy@aliyun gitcode]$ git checkout master  #切换回master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge dev2  #合并dev2
Updating ac63583..8bdc3c9
Fast-forward
 ReadMe | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
[Lxy@aliyun gitcode]$ cat ReadMe  #查看ReadME代码
hello git
hello world
hello ReadMe

I am Codeing in dev2.........
git --version 
bug is fixed .........
[Lxy@aliyun gitcode]$ git branch -d dev2 #删除dev2
Deleted branch dev2 (was 8bdc3c9).
[Lxy@aliyun gitcode]$ git branch -d fix_bug  #删除fix_bug
Deleted branch fix_bug (was 76fef0d).
[Lxy@aliyun gitcode]$ git branch -d dev1  #删除dev1
Deleted branch dev1 (was f41d236).
[Lxy@aliyun gitcode]$ git branch 
* master

eliminar rama temporal

En el desarrollo de software, siempre hay infinitas funciones nuevas que se agregan continuamente. Al agregar una nueva función, definitivamente no desea estropear la rama principal debido a algún código experimental, por lo que cada vez que agrega una nueva función, es mejor crear una nueva rama, que podemos llamar Como una rama, feature desarrollar en él, después de completarlo, fusionarlo y, finalmente, eliminar la featurerama. Sin embargo, si hoy estamos featurea medio camino del desarrollo de una determinada rama, el gerente de producto se detiene repentinamente y dice que queremos detener el desarrollo de nuevas funciones. Aunque esté seca, esta featurerama debe ser destruida en el acto, dejándola inservible. git branch -dEn este momento , no es factible usar el comando tradicional para eliminar la rama. La demostración es la siguiente:

#新建并且切换到dev3分支
[Lxy@aliyun gitcode]$ git checkout -b dev3 
M	ReadMe
Switched to a new branch 'dev3'
#开始开发新功能并提交
[Lxy@aliyun gitcode]$ vim ReadMe  
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

I am Codeing in dev2.........
git --version 
bug is fixed .........

hello dev3
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev3 00a37ca] md ReadMe
 1 file changed, 2 insertions(+)
 
 #此时新功能叫停
 #切回master准备删除dev3
[Lxy@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
#常规删除dev3分支时失败
[Lxy@aliyun gitcode]$ git branch -d dev3
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.

No es posible utilizar directamente el método tradicional de eliminación de ramas. Según el indicador, existe el siguiente método:

[Lxy@aliyun gitcode]$ git branch -D dev3
Deleted branch dev3 (was 00a37ca).
[Lxy@aliyun gitcode]$ git branch
* master

Resumir

¿Cuál es el uso de la ramificación en la práctica? Suponga que va a desarrollar una nueva función, pero tarda dos semanas en completarse. Escribió el 50% del código en la primera semana. Si lo envía de inmediato, porque el código aún no se ha escrito, el código base incompleto se recuperará. evitar que otros trabajen en él. Si espera hasta que todo el código esté escrito y lo envía de nuevo, existe un gran riesgo de perder su progreso diario.

Ahora que hay sucursales, no hay que tener miedo. Creas una rama que te pertenece, otros no pueden verla y continúas trabajando normalmente en la rama original, mientras trabajas en tu propia rama, envíala como quieras, hasta el desarrollo Después de completarla, fusionala con la rama original nuevamente, para que sea seguro y no afecte el trabajo de otras personas.

Y no importa que Git cree, cambie y elimine ramas, ¡Git puede completarlo en 1 segundo! No importa si su biblioteca de versiones es de 1 archivo o de 10 000 archivos.

(Fin de este artículo)