Estoy participando en el reclutamiento del programa de firma de creadores de la Comunidad Tecnológica de Nuggets, haga clic en el enlace para registrarse y enviar .
La característica principal de Git es que trae ramas livianas. Si usa ramas svn, se sorprenderá de lo rápido que Git puede crear y cambiar ramas.
Las ramas operativas son muy frecuentes en Git. El aprendizaje de las operaciones de rama es la base del aprendizaje de Git. Sin embargo, en el trabajo real, descubrí que muchos estudiantes no están familiarizados con las operaciones de rama de Git. El modelo de ramificación de Git detrás del comando.
rama maestra
Después de crear un nuevo proyecto en Git, hay una rama por defecto, es decir, la rama principal. La rama principal generalmente representa la versión estable del proyecto. La rama principal debe contener código estable y libre de errores y mantener un estado que pueda ser liberado en cualquier momento. Para proyectos pequeños, solo una rama principal es suficiente. Cada vez que enviamos , se creará una confirmación.
$ git commit -m "c1"
$ git commit -m "c2"
$ git commit -m "c3"
El comando anterior creará tres nodos de confirmación. En este momento, la rama maestra se muestra en la siguiente figura:
La rama principal solo debe empaquetarse, fusionarse y enviarse, y todas las iteraciones deben realizarse en la rama. Si es un cambio simple, también es posible modificarlo directamente en la rama principal. Si la función es compleja y requiere envíos múltiples, no se recomienda usar la rama principal Modificar directamente.
rama característica
Cuando hay una nueva característica a desarrollar, se debe crear una nueva rama de característica.El comando es el siguiente:
$ git checkout -b feature/a
A continuación, cree dos confirmaciones en la rama con los siguientes comandos:
$ git commit -m "c4"
$ git commit -m "c5"
En este punto, el árbol de confirmación se ve así:
Cuando se completa el desarrollo de la rama de funciones, debe volver a fusionarse con la rama principal. Hay dos opciones para volver a fusionarse con la rama principal, fusión rápida y fusión no rápida. La diferencia entre las dos es si se debe crear un nodo de confirmación El comando es el siguiente:
$ git merge feature/a # 快速合并
$ git merge --no-ff feature/a # 非快速合并
El resultado de la combinación rápida apuntará directamente al maestro a la característica/a, como se muestra en la siguiente figura:
El resultado de una combinación no rápida creará un nodo de confirmación de combinación en el maestro, como se muestra en la siguiente figura:
Ambos métodos de fusión están disponibles. Si elige fusionar rápidamente, debe asegurarse de que cada confirmación sea independiente y completa. Si no cumple con los requisitos, Git admite la modificación del historial de confirmación, que debe modificarse y fusionarse nuevamente.
Puede usar el comando rebase para modificar el historial. Los siguientes comandos pueden modificar las últimas tres confirmaciones, cambiar la selección de la segunda confirmación para aplastar, fusionar la primera y la segunda confirmación, y cambiar la selección de la tercera confirmación para editar. La información de confirmación para la tercera confirmación se puede modificar.
$ git rebase -i HEAD~3
pick d24b753 feat: update ci
squash f56ef2f feat: up ci
edit 6c91961 feat: up
# Rebase 50ece5c..6c91961 onto 50ece5c (3 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
Después de crear la rama actual, la rama maestra puede tener nuevas confirmaciones, como se muestra en la siguiente figura:
在合并之前，建议先将主分支新的提交合并到当前分支，有两种策略可以选择，合并和变基，合并操作更简单，变基操作提交树更清晰，建议使用变基的方式。
先来看下合并操作的过程，命令如下：
$ git merge master
$ git checkout master
$ git merge feature/a
合并操作后的提交树如下图所示：
变基会修改feature/a的历史，就像 feature/a 是在 master 之后开发的一样，变基命令如下：
$ git rebase master
$ git checkout master
$ git merge feature/a
变基操作后的提交树如下图所示，虚线的提交是feature/a变基之前的状态，在变基后，虚线的提交不再有分支指向，但并不会删除，而是变成Git中的游离节点，在Git执行GC（垃圾清理）操作后，节点才会彻底删除。
故障分支
如果发现存在 Bug，要尽快修复，此时可以基于主分支新建故障分支，命令如下：
$ git checkout -b bugfix/b
当验证没问题后，故障分支需要合并回主分支，并在主分支上发布新的补丁版本，命令如下：
$ git checkout master
$ git merge --no-ff bugfix/b
# 测试 构建 打标签 发布到npm
主分支更新后，下游的公共分支要及时同步变更，建议使用变基进行同步，命令如下：
$ git checkout feature/a
$ git rebase master
故障分支模型如下图所示，bugfix/b 分支合并到 master 后，feature/a 分支进行了变基操作。
标签与历史
每次发布新版本时都要打标签，版本号需要符合第四章介绍的语义化版本规范，一般功能分支发布次版本号，故障分支发布修订版本号，使用Git添加tag的命令如下所示：
# 假设当前版本是 1.1.0
$ git tag 1.1.1 # 修改次版本号
$ git tag 1.2.0 # 修改主版本
Git 的版本号，还可以添加 v 前缀，两种风格都可以，建议在一个项目里面保持统一，添加v前缀的版本示例如下：
# 假设当前版本是 v1.1.0
$ git tag v1.1.1 *# 修改次版本号
$ git tag v1.2.0 *# 修改主版本号
添加标签后，提交树示例如下图所示。
现在假设最新版本是 v1.2.0 了，突然用户反馈了 v1.0.0 版本存在 bug，如果是比较小的问题，一般我们会建议用户升级到最新版本 ，但如果用户不能升级怎么办，比如 1.x 到 2.x 存在大版本变化。
出于各种原因，存在需要维护历史版本的需求，对于还有用户使用需求的历史版本，需要提供 bug 修复的支持。
此时创建的标签就起作用了，可以基于标签新建一个版本分支，并在版本分支上修复 bug，且发布新的版本，历史版本分支，不需要再次合并回主干分支，创建标签分支的示例如下：
$ git checkout -b v1.0.x v1.0.0
此时历史分支的示例如下图所示。
总结
Este artículo presenta los comandos de rama comunes y los modelos de rama de Git, con la esperanza de ayudarlo a comprender mejor los principios de Git. Si cree que este artículo es útil para usted, haga clic en Me gusta y siga al autor. Si tiene alguna pregunta sobre este artículo, Bienvenido a Exchange en los comentarios.
Además, el autor mantiene muchos buenos proyectos de código abierto en GitHub, bienvenido a verlos: github.com/yanhaijing