A veces sobreestimo mi propio peso en el corazón de los demás, porque espero, pero también espero con ansias, y espero que los demás sean buenos. No debe considerarse un mal hábito, es solo que puede sentirse decepcionado o perdido más, o se adaptará lentamente y luego aprenderá a ajustar su posición.
git entender
1. Git es un software de control de versiones distribuido.
a. Distribuido:
b) Control de versiones: los artículos universitarios se revisan una y otra vez, y eventualmente habrá muchas versiones, esto es control de versiones de archivos.
Se guardan demasiadas versiones, no lo que quiero, avanza. . .
c. Control de versión local: (En este momento, solo hay una versión actual, y puede ver los documentos de diferentes versiones en el pasado a través de comandos). En este momento, solo puede controlarlo usted mismo, y puede ' t controlarlo con varias personas
d) Centralizado: (hay un servidor central) Hay todas las versiones diferentes, SVN, y solo hay una versión en cada computadora.Si el servidor central actual no funciona, la integridad del código puede ser destruida en este momento.
Distribuido: a diferencia de lo centralizado, cada computadora guarda una copia de todas las versiones del código, y el servidor principal está inactivo sin afectar la integridad del código, y el desarrollo individual aún se puede llevar a cabo.
Software: descargar e instalar en la computadora para ejecutar se llama software
2. El objetivo principal del control de versiones es evitar problemas en línea y facilitar la reversión.
3. Git configura la información personal
git config --global user.email "[email protected]"
git config --global user.name "wangzi"
4. Instalación del sitio web oficial de git para lograr el control de la versión local
①Abre git e ingresa a la carpeta que será administrada por git
②Inicialice el git init del almacén para generar un archivo .git, que contendrá información sobre el control de versiones posteriores y, por lo general, no es necesario modificarlo (comenzar a administrar)
③git status Ver el estado de los archivos en la carpeta actual (rojo significa no administrado), los archivos rojos están en el área de trabajo
④git add demo.txt El archivo se vuelve verde y el archivo está administrado. Si desea que todo esté administrado, ingrese git add. Add e ingrese al área de almacenamiento temporal
⑤git commit -m "v1" Después de implementar la primera confirmación de control de versiones, ingrese al repositorio, que es el repositorio local
⑥git log ver la versión generada
5. Revertir
git log Ver una larga cadena de caracteres después de la confirmación del registro enviado
Confirme la información de la versión a la que desea regresar después del comando git reset --hard + git_log
Después de la reversión, el comando git log no mostrará el registro que se revirtió. Debes ingresar git reflog. En este momento, puedes mostrar todos los registros de confirmación. Si quieres volver a esa versión, ejecuta git reset - -hard + número de versión (comando git reflog Después de eso, cada confirmación tiene un número de versión)
6, desarrollo de la rama
V1 es la rama más original, V2 se modifica y solo el contenido modificado se conserva en forma de punteros, y la forma no modificada de una instantánea se guarda, apuntando a V1 y V3 de la misma manera. V4 y 5 indican que se crea la rama.
El desarrollo de sucursales es una muy buena forma de soluciones de emergencia para errores en línea.
Por ejemplo, v3 es actualmente contenido en línea, un error necesita ser arreglado con urgencia, v5 está actualmente en desarrollo, luego puede crear una nueva rama sobre la base de v3, como v4, después de que se complete la reparación, V4 se puede fusionar en la rama principal directamente. Conéctese directamente en línea sin afectar el desarrollo continuo de V5.
Crear una rama: git branch dev
Cambiar de rama: dev de git checkout
Crear y cambiar de rama: git checkout -b dev
7. Proceso de corrección de errores:
Cree un error de rama basado en la rama principal, modifique la confirmación de contenido, vuelva a la rama principal actual y fusione la rama del error. ------- error de fusión de git
Una vez completada la reparación, la rama de msater es normal. En este momento, puede descargar el molino y matar al burro y matar la rama de error. —Git branch -d error
8 、 github 与 gitlab
Almacén de alojamiento de código Github gitlab (código abierto, construye tu propio servidor, crea tu propio almacén, administra tu propio código)
9 、 git pull origin dev
git fetch origin dev primero tire al almacén local git merge origin / dev Para mostrar que se extrae de forma remota, debe agregar origin / delante de él
10. Existe una situación en la que la mitad del código se desarrolla en casa pero se olvida de presionar de forma remota. Luego, cuando fui a casa para extraer el código, descubrí que no había ningún push. En este momento, puede desarrollar otras funciones primero, luego presionar y luego extraer el código después de llegar a la empresa para resolver el conflicto, continuar desarrollando y completar, y luego empujar.
11. Rebase de uso
Beneficios ① puede hacer que los registros de git sean más concisos
Combine varios registros de envío locales en un solo registro (no se recomienda la fusión de rebase para aquellos que han sido enviados al almacén remoto, será más problemático)
git rebase -i HEAD ~ 2 significa fusionar el último registro actual con los dos registros enviados anteriormente o git rebase -i + número de versión
Escenario ②: el comando git pull generalmente produce bifurcaciones. Para evitar bifurcaciones, puede ingresar el siguiente comando: git fetch origin dev luego git rebase origin / dev Si hay un conflicto, resuélvalo primero y luego git rebase --continue
Escenario desarrollo de rama ③, múltiples bifurcaciones, si no desea bifurcar, puede usar rebase
12. Resuelve múltiples conflictos de software incomparable
git config --local merge.tool aaa
git config --local mergetool.path 'directorio de instalación de software'
git config --local mergetool.keepBackup false significa que el archivo de copia de seguridad no se guardará después de que se resuelva el conflicto
Software de aplicación para resolver conflictos: git mergetool
13. Grabar visualización gráfica: git log --graph --pretty = formato: "% h% s"
especificación de etiqueta
La etiqueta Git se utiliza principalmente para etiquetar el número de identificación de la versión generada después de un determinado envío de código
Cada proyecto debe etiquetarse después de fusionar el maestro.
Producción: GIC2021-01-21
Entorno de prueba: k8s_test_20210111
Los comentarios de las etiquetas deben ser lo más claros posible
Operación de comando de etiqueta:
Ver la etiqueta local git tag
Llame a uno localmentetag git tag 1-25
Eliminar etiqueta local git tag -d 1-25
Las etiquetas creadas solo se almacenan localmente y no se enviarán automáticamente al control remoto. Por lo tanto, la etiqueta incorrecta se puede eliminar de forma segura de forma local.
Agrega una nota a la etiqueta: git tag V1 -m "first version“
Si desea enviar una etiqueta al control remoto, use el comando git push origin 1-25
Empuje múltiples etiquetas locales a remoto git push origin --tags
Elimine la etiqueta, si se ha enviado al control remoto, puede eliminar el local primero y luego eliminar el remoto git push origin :refs/tags/1-25
Eliminar etiqueta o usar: git push origin :111
Cambie al código correspondiente a una etiqueta:git checkout <tagname>
Si desea editar el código correspondiente a una etiqueta, debe crear una rama y luego cambiar la etiqueta: git checkout -b <branch-name> <tagname>
Escenarios de uso de etiquetas:
mc-service se conectará en línea del 1-22 para modificar la etiqueta: GIC2021-01-22
La nueva etiqueta de adquisición de información de usuario de contenido: GIC2021-01-26 se lanzó el 1.26. Se encontró un error en el código durante el proceso en línea. En este momento, hay dos formas:
Una es: corrija el error y comience una nueva ronda en línea. En este caso, el tiempo requerido puede ser relativamente alto y el problema debe resolverse rápidamente y en línea.
La otra es: use la etiqueta existente GIC2021-01-22 para revertir directamente. Implemente el código debajo de la etiqueta en el entorno de producción y luego corrija cuidadosamente el error y vuelva a ejecutarlo en línea.
Tire del código remoto:
1. Descarga la herramienta de escritorio y abre git bash aquí
2. Cree una carpeta e ingrese la carpeta para inicializar el almacén mkdir test / cd test / git init
3. Asociar el origen del almacén remoto git remote add <dirección del almacén remoto>
4. Extraiga el código del almacén remoto git pull origin master o git clone <dirección de clonación> Este comando no necesita inicializar el almacén, puede clonar el código directamente en el local
Operación de sucursal:
Ver sucursales locales: sucursal de git
Ver ramas remotas: git branch -r
Ver ramas locales y remotas: git branch -a
Lleva todas las ramas al local: git fetch (a veces no puedes encontrar una rama remota para hacer esto)
Ver la rama remota vinculada a la rama local: git branch -vv
Enlazar la rama remota: git branch --set-upstream-to = origin / master
Cree una sucursal local: git branch <nombre de la sucursal>
Crear y cambiar de rama: git checkout -b <nombre de rama>
Empuje la rama local al remoto: git push origin test: test
Elimina la rama local: git branch -D <nombre de la rama>
Eliminar la rama remota: git push origin --delete <nombre de la rama>
Cambie el nombre de la rama: git branch -m <nombre original> <nombre nuevo>
Envíe todas las modificaciones locales al área de almacenamiento temporal: git add.
Envíe un archivo local (agregue el nombre del archivo): git add test.py
Envíe el área de ensayo a la sucursal local: git commit -m "Comentarios"
Envíe la rama local al control remoto: git push
operación git stash:
Guarde el progreso actual y guarde todas las modificaciones no confirmadas (incluidas las temporales y no temporales) para la restauración posterior del directorio de trabajo actual.
git alijo
Se recomienda agregar un mensaje a cada alijo para registrar la versión y usar git stash save para reemplazar el comando git stash. Los ejemplos son los siguientes:
Mostrar todo lo almacenado:
git stash list ---- 
restaura el progreso especificado (no se eliminará de la lista):
git stash apply + stash @ {}:
Restaurar el último progreso eliminará el último progreso de la lista:
git stash pop
Borrar todo el almacenamiento
git alijo claro
Borrar un cierto almacenamiento
git stash drop stash @ {}:
operación de reversión de git:
Empuje al almacén local, no quiera enviar, regrese a la última versión enviada
1. suave ① Mueve el puntero HEAD de la biblioteca local
Esto significa que después de la reversión, solo se mueve el puntero de la biblioteca local y no se realizan cambios en el área de almacenamiento temporal ni en su código local.
Y el código que envió a la biblioteca local la última vez es verde, es decir, no se envió
2. mixto ① Mueva el puntero HEAD de la biblioteca local
②Restablecer el área de almacenamiento temporal
Esto significa que después de la reversión, no solo se mueve el puntero de la biblioteca local, sino que también desaparece el área de almacenamiento temporal, lo que significa que el archivo que agregó al área de almacenamiento temporal la última vez debe agregarse nuevamente
3. Difícil ① Mueva el puntero HEAD de la biblioteca local
②Restablecer el área de almacenamiento temporal
③Restablecer el área de trabajo
Significa que después de la reversión, el código local es el código de su versión de reversión.
Confirme 4 veces seguidas y anote la información de envío ------------------ 
git log Vea el registro de envío, el encabezado señala la última confirmación ----- - 
git reset --hard <número de confirmación> ------------------------------- El 
registro de Git nuevamente encontró que no hay más registro de confirmación de 444, el código es más 333 
4. mantener
① Mueva el puntero HEAD de la biblioteca local
②Restablecer el área de trabajo
Esto significa que después de la reversión, el código local es el código de su versión de reversión y los archivos en el área de almacenamiento temporal aún se guardan.
Operación de rebase:
Combine varios registros de envío en un solo envío para facilitar code_review
git rebase -i <confirmación de una determinada confirmación>
git log para ver el registro de confirmación actual y
ejecutar el comando git rebase -i 02ee740b49912baf2ed7275c983124b131d87bfc (los anteriores se fusionarán, excluyendo esta confirmación) e ingresar a la página siguiente, elegir significa seleccionar la confirmación actual s significa no guardar y salir de esta commit, ingrese el primero Ingrese un registro de compromiso después de la combinación local en las dos páginas, guarde y salga, y git log nuevamente, ¡la combinación es exitosa! ! !
git push -f Force push al control remoto, y la fusión es exitosa.
La operación de rebase tiene ciertos riesgos. Sobrescribirá algunos de los registros de envío anteriores. Se recomienda crear una nueva rama para la operación. Luego, después de que no haya ningún problema, combine todas las confirmaciones de la rama recién creada y luego combínela con la maestra.
operación de fusión:
El maestro de la rama actual
git merge branch_test ---- Fusiona la rama branch_test con el maestro, y la operación mediante merge producirá una bifurcación, como se muestra en la Figura 1. Si no quieres producir una bifurcación, puedes usar rebase, como se muestra en Figura 2, el comando es git rebase <nombre de rama>, si después de que se resuelva el conflicto, git rebase --continuar
Flujo de trabajo de desarrollo de sucursales:
Al recibir una nueva solicitud, como modificar el nombre de usuario y contraseña de la base de datos, el proceso habitual es el siguiente:
Cambiar a la rama maestra del proyecto: git checkout master
Extraiga el último código: git pull origin master
Cree una nueva rama y cambie a la rama recién creada: git checkout -b feature / update_database_username_pwd (el nombre de la rama generalmente comienza con feature /, seguido del nombre de la función correspondiente)
Modifique en la rama recién creada y envíe al control remoto después de completar: git add. / Git commit -m "update_finish" / git push orgin feature / update_database_username_pwd: feature / update_database_username_pwd
Fusionar el código actual con master: git checkout master / git merge feature / update_database_username_pwd
Envíe la solicitud de fusión al colega de la revisión de código relevante para code_review.
Una vez aprobado el código, etiquetar el master, el tag estándar se refiere al anterior de cada proyecto, y luego se realiza la prueba de prelanzamiento.
Si no hay ningún problema, conéctese normalmente. Si se produce una reversión, se debe proporcionar la etiqueta de la versión anterior. Debe prepararse con anticipación antes de conectarse en línea para retroceder en el tiempo.
Un error en línea necesita un proceso de reparación de emergencia:
Hay una ligera diferencia al crear una rama y nombrarla, el nombre es el siguiente: hotfix / + "Resumen de contenido reparado"
El resto del proceso es el mismo que el proceso durante el desarrollo de la rama.