He estudiado git muchas veces seguidas, pero muchas veces lo he olvidado. Al final, solo cargará y empujará sus cambios en la idea. Recientemente vi otro que hablaba de git. No está mal. Al menos no lo he olvidado después de muchos días, así que lo grabé especialmente.
Precuela
Hablemos primero sin sentido (solo quiero aprender comandos, se recomienda comenzar desde la biografía)
Linus creó Linux de código abierto en 1991. Desde entonces, el sistema Linux ha seguido desarrollándose y se ha convertido en el software de sistema de servidor más grande.
Aunque Linus creó Linux, el crecimiento de Linux depende de la participación de voluntarios entusiastas de todo el mundo. Mucha gente está escribiendo código para Linux en todo el mundo. ¿Cómo se maneja el código Linux?
Antes de 2002, voluntarios de todo el mundo enviaron los archivos de código fuente a Linus por diff, ¡y luego el propio Linus fusionó el código manualmente!
Puede pensar, ¿por qué Linus no pone el código de Linux en el sistema de control de versiones? ¿Existen sistemas de control de versiones gratuitos como CVS y SVN? Debido a que Linus se opone firmemente a CVS y SVN, estos sistemas de control de versiones centralizados no solo son lentos, sino que también deben conectarse a Internet antes de que puedan usarse. Existen algunos sistemas comerciales de control de versiones, aunque son más fáciles de usar que CVS y SVN, son de pago y no coinciden con el espíritu del código abierto de Linux.
Sin embargo, para el año 2002, el sistema Linux se había desarrollado durante diez años. El tamaño de la base del código dificultaba que Linus continuara administrándolo manualmente. Los hermanos de la comunidad también expresaron una gran insatisfacción con este método, por lo que Linus eligió un negocio El sistema de control de versiones de BitKeeper, el propietario de BitKeeper BitMover, por espíritu humanitario, autorizó a la comunidad de Linux a usar este sistema de control de versiones de forma gratuita.
La buena situación de estabilidad y unidad se rompió en 2005, porque la comunidad de Linux reunió personas, y era inevitable que algunos de los hábitos de los héroes de Liangshan estuvieran contaminados. Andrew, que desarrolló Samba, trató de descifrar el protocolo de BitKeeper (no es solo él), y fue descubierto por BitMover (¡el trabajo de monitoreo se hizo bien!), Por lo que BitMover estaba furioso y quería recuperar los derechos de uso gratuito de la comunidad Linux.
Linus puede disculparse con BitMover y prometer disciplinar estrictamente a sus hermanos en el futuro. Bueno, esto es imposible. La situación actual es esta:
Linus pasó dos semanas escribiendo un sistema de control de versiones distribuido en C por sí mismo, ¡eso es todo! ¡Dentro de un mes, el código fuente del sistema Linux ha sido administrado por Git! ¿Cómo se define el ganado? Todos pueden apreciarlo.
Git se convirtió rápidamente en el sistema de control de versiones distribuido más popular. Especialmente en 2008, el sitio web de GitHub se puso en línea. Proporciona almacenamiento gratuito de Git para proyectos de código abierto. Numerosos proyectos de código abierto comenzaron a migrar a GitHub, incluidos jQuery, PHP, Ruby, etc.
La historia es tan accidental, si no fuera por la amenaza de BitMover para la comunidad Linux, es posible que ahora no tengamos Git gratis y súper fácil de usar.
Principio 1. principio de git
Primero, git funciona en base a las instantáneas de la versión.
Git es más como ver datos como un conjunto de instantáneas de un pequeño sistema de archivos. Cada vez que envía una actualización o guarda el estado del proyecto en Git, toma principalmente una instantánea de todos los archivos en ese momento y guarda el índice de la instantánea. Para mayor eficiencia, si el archivo no se modifica, Git ya no volverá a almacenar el archivo, sino que solo mantendrá un enlace al archivo almacenado anteriormente. Git trata los datos más como una secuencia de instantáneas.
Principio 2. git garantiza la integridad de los datos
Todos los datos en Git se calculan con una suma de verificación antes del almacenamiento y luego se hace referencia con la suma de verificación. Esta función está construida en la parte inferior de Git y es una parte integral de la filosofía de Git. Si pierde información o daña archivos durante el proceso de transferencia, Git puede encontrarlo.
El mecanismo que utiliza Git para calcular la suma de comprobación se denomina hash SHA-1 (hash). Esta es una cadena de 40 caracteres hexadecimales (0-9 y af), calculados en función del contenido del archivo en Git o la estructura del directorio. El hash SHA-1 se ve así:
24b9da6552252987aa493b52f8696cd6d3b00373
Hay muchos casos de uso de este tipo de valor hash en Git, a menudo verá este tipo de valor hash. De hecho, la información almacenada en la base de datos Git está indexada por el valor hash del contenido del archivo, no por el nombre del archivo.
Principio 3. Falta la versión
Las operaciones de Git que realiza casi solo agregan datos a la base de datos de Git. Es difícil para Git realizar una operación irreversible o borrar los datos de alguna manera. Al igual que otras herramientas de control de versiones, es posible perder o estropear el contenido modificado cuando no se envía la actualización; pero una vez que envía la instantánea a Git, es difícil perder datos, especialmente si empuja regularmente la base de datos a otros repositorios.
Esto hace que nuestro uso de Git sea un proceso de tranquilidad, porque sabemos que podemos hacer todo tipo de intentos sin riesgo de estropear las cosas.
Intermedio: conceptos muy importantes: repositorio (almacén), área de trabajo, área de almacenamiento temporal, área de sucursal
1. Biblioteca de versiones (almacén)
El repositorio también se conoce como repositorio, y el nombre en inglés es repositorio. Simplemente puede entenderlo como un directorio. Git puede administrar todos los archivos en este directorio. Git puede rastrear la modificación y eliminación de cada archivo para que pueda rastrearse en cualquier momento. Historia, o puede ser "restaurada" en algún momento en el futuro.
2. Área de trabajo
Ubicación donde se almacenan los archivos a administrar
3. Área de almacenamiento temporal
La operación de agregar el comando git add o el comando git rm en el repositorio al área de almacenamiento temporal se registra en el área de almacenamiento temporal
4. Área de la sucursal
El área de bifurcación en el repositorio es donde se guarda la información de la versión final. El comando git commit envía las operaciones registradas en el área temporal a la bifurcación.
Se pueden configurar múltiples bifurcaciones. Si no se especifica, el valor predeterminado es la bifurcación maestra y un puntero de cabeza apunta al maestro. La última ubicación de la sucursal.
1. Crear un repositorio
Primero, si desea que git administre sus archivos, debe declarar su carpeta como una carpeta git. El comando utilizado es:
git init
Después de ejecutar el comando, habrá un directorio .git adicional debajo de este directorio. Git usa este directorio para rastrear y administrar el repositorio. No lo modifique manualmente.
Git es una herramienta de administración de versiones que muchas personas pueden usar, entonces, ¿cómo hacerles saber a los demás que eres tú? Podemos hacer alguna configuración
Primero configure user.name, use git config --global suer.name "el nombre que desea configurar"
git config --global user.name "zhangsan"
A veces, el nombre se repetirá, por lo que debe configurar un correo electrónico. Simplemente use git config --global user.email buzón.
git config --global user.email zhangsan@qq.com
Debido a que esta no es una discusión sobre la configuración relacionada con git, solo dé una breve introducción.
Vea su propia información de configuración usando git config --list
git config --list
2. Área de trabajo y almacén.
La carpeta administrada por git se puede dividir en tres áreas: área de trabajo, área de almacenamiento temporal y área de sucursal.
El área de trabajo puede entenderse como el área donde se modifica el archivo.
El área de la sucursal se puede entender como: el área del archivo enviado (archivo de confirmación exitoso).
El área de almacenamiento temporal está entre los dos, que puede entenderse como el área de transición entre los dos. Puede enviarse al área de sucursal, también puede retirarse al área de trabajo.
3. Nuevos documentos y agregar y confirmar
Primero, escribamos un archivo a voluntad, llamado text01.txt. Podemos usar un comando para ver los cambios en la carpeta administrada por git.
git status
Esta es una explicación de la salida.
Debido a que agregamos el archivo text01.txt, git nos indica que hay un archivo que no se rastrea (es decir, este archivo no se puede enviar al área de la rama). Podemos usar el comando git add file name para rastrear el archivo y, al mismo tiempo, el archivo se enviará al área de almacenamiento temporal.
git add text01.txt
Al mismo tiempo, verifiquemos nuevamente el estado de git
git status
La segunda línea de texto en la imagen de abajo estaba mal, debe ser ningún contenido no comprometida
Hemos añadido más de los documentos, sino que también presenta a la zona de espera y, a continuación, siempre y cuando se sometió a la zona de la rama puede ser.
Utilice la información relacionada con git commit -m. La información relevante son los comentarios de esta presentación.
-m后面输入的是本次提交的说明，可以输入任意内容
本例中只经历了一个修改就提交了，其实完全可以 多个修改后一次提交
git commit -m "add file test.txt"
Verifique nuevamente el estado del repositorio
git status
Al dibujar, el repositorio ahora se convierte en el siguiente estado:
4. Modificar y comparar archivos
Primero modifique test01.txt. Verifique el estado del repositorio después de la modificación
git status
El estado de la biblioteca de dibujo es el siguiente:
en este momento, podemos ver la información de modificación del archivo. Use el comando de nombre de archivo git diff.
git diff test.txt
En mi computadora,
agregue el archivo al área de preparación como se muestra a continuación .
git add test01.txt
Ver estado
git status
El estado de la biblioteca de versiones de la imagen es el siguiente:
en este momento, envíe la modificación a la rama.
git commit -m "change Git to git"
Verificar estado nuevamente
git status
El estado de la biblioteca de imágenes es el siguiente
5. Ver versiones históricas
Modifique test01.txt nuevamente. Agregue archivos al área de almacenamiento temporal después de la modificación.
git add text01.txt
Luego envíe el archivo a la sucursal.
git commit -m "...some msg..."
En este punto, se han enviado varios archivos al área de sucursal, puede usar el comando git log para ver la versión histórica
git log
6. Retroceda la versión
Un día, mientras estaba siendo modificado, de repente descubrí que cometí un error y que necesitaba volver a una confirmación anterior. Esta operación se llama reversión. Puede usar el siguiente comando:
git reset --hard HEAD^
En Git, HEAD se usa para indicar la versión actual. La versión anterior es HEAD ^, y la última versión es HEAD ^^. Por supuesto, escribir 100 ^ en las 100 versiones principales es más fácil de contar, por lo que se escribe como HEAD ~ 100.
Si eres demasiado vago para contar la versión anterior, también puedes retroceder al número de versión especificado.
git reset --hard 5527510751b4303390bb4f321bfa8b7f997cbfd0
Puedes llamar a los primeros si eres demasiado vago.
git reset --hard 55275
Vuelva a la versión anterior y use git log nuevamente para ver la versión histórica.
git log
Cuando utilice este comando, encontrará que solo se muestran la versión actual y la versión anterior; las versiones posteriores a la versión actual no se pueden ver.
Entonces, ¿significa que solo podemos retroceder y no retroceder?
Por supuesto que no.
Use el comando git reflog para ver todas las versiones.
git reflog
Con el comando git reset, puedes retroceder fácilmente a cualquier versión.
7. Deshacer la modificación
De vuelta al original. Revisamos el archivo nuevamente, pero descubrimos que la modificación era incorrecta y quería deshacerla. Puede usar el nombre de archivo de pago git. Este comando restaurará el archivo de espacio de trabajo para el estado de la última adición o cometer antes.
git checkout -- test.txt
Continuamos modificando el archivo y agregando el archivo al área de almacenamiento temporal (aún no enviado al área de la sucursal). De repente, encontramos que estaba mal otra vez ... No es fácil usar el comando git checkout solo. En este momento, podemos cooperar con otros comandos.
Primero, podemos retroceder a la versión actual (al retroceder a otras versiones, los archivos en el área de ensayo desaparecerán, de modo que los archivos en el área de ensayo se borren)
git reset HEAD test.txt
Luego use el comando git checkout para deshacer.
git checkout -- test.txt
Esta vez, continuamos modificando el archivo, agregando y confirmando el archivo. Luego descubrí que estaba mal otra vez ... Puedo deshacer esta modificación retrocediendo. Sin embargo, incluso si retrocede, aún puede ver esta confirmación utilizando git reflog. Por lo tanto, siempre que se envíe al área de rama de git, es imposible eliminarlo.
8. Eliminar archivos
Encontramos un archivo inútil y lo eliminamos.
rm test01.txt
Por supuesto, también se puede eliminar manualmente. Verifique el estado del repositorio después de eliminar
git status
Agregue los archivos eliminados al área de almacenamiento temporal. Utilice el comando de nombre de archivo git rm.
git rm test01.txt
Por supuesto, también puede usar el comando git add. Ver el repositorio.
git status
Envíalo a la sucursal.
9. ¿Qué gestiona y rastrea git?
git rastrea y gestiona cambios, no archivos.
Por ejemplo, primero, agregamos una nueva línea de texto a test01.txt: 111111.
Luego agregue el archivo al área de preparación.
Luego agregue un archivo de arrepentimiento a test01.txt: 222222.
Luego comprométete con la rama.
Luego verifique el estado del repositorio, encontrará que 222222 no se ha enviado.
10. Resumen del comando
11. Especifique el nombre de la etiqueta de versión por etiqueta
La versión en git tiene un número de versión. El envío y la reversión del código se basan en el número de versión, pero el número de versión en git es una cadena aleatoria, que no es fácil de recordar. En este momento, puede usar el mecanismo de etiquetado para confirmar Agregue etiquetas para facilitar la búsqueda futura. Después de que la etiqueta se amplía, todas las posiciones donde se necesita usar el número de versión se pueden reemplazar con la etiqueta correspondiente. La etiqueta también puede entenderse como un alias.
Primero, etiquete la confirmación actual de la rama actual.
git tag v1.0
También puedes ver todas las etiquetas
git tag
También puede etiquetar la versión enviada anteriormente
git tag v0.9 f52c663
También puede crear etiquetas con instrucciones. Use -a para especificar el nombre de la etiqueta y -m para especificar el texto descriptivo.
git tag -a v0.1 -m "version 0.1 released " 1094adb
Puede ver la información de una etiqueta con el siguiente comando:
git show v0.1
Si la etiqueta es incorrecta, puede eliminarla
git tag -d v0.1
Si desea insertar etiquetas en un control remoto, use git push origin tagName.
git push origin v1.0
También puede insertar todas las etiquetas locales que no se han insertado en el control remoto de una sola vez.
git push origin --tags
Sin embargo, si la etiqueta se ha enviado al control remoto, será problemático eliminarla. Primero quite la etiqueta local
git tag -d v0.9
Luego eliminar del control remoto
git push origin :refs/tags/v0.9
12. Especifique git para ignorar algún contenido
Puede configurar el archivo .gitIgnore en el almacén. Los archivos que están configurados en él no requieren la administración de git. Cuando git procesa este almacén, ignorará automáticamente el contenido de la declaración.
Formato de archivo .gitIgnore:
1) Los espacios no coinciden con ningún archivo, se pueden usar como separador y se pueden escapar con una barra diagonal inversa
2) Git ignorará las líneas que comienzan con "#". Es decir, el comentario de identificación de archivo que comienza con # se puede escapar con una barra diagonal inversa.
3) Se puede utilizar la coincidencia estándar de patrón glob. El llamado patrón glob se refiere a la expresión regular simplificada utilizada por el shell.
4) El comienzo de una barra inclinada "/" indica un directorio; el patrón final "/" solo coincide con la carpeta y el contenido de la ruta de la carpeta, pero no coincide con el archivo; "/" El patrón inicial coincide con el proyecto y el directorio; si Un patrón no contiene una barra oblicua, coincide con el contenido relativo a la ruta actual del archivo .gitignore, si el patrón no está en el archivo .gitignore, es relativo al directorio raíz del proyecto.
5) Use el asterisco " " para hacer coincidir múltiples caracteres, es decir, para hacer coincidir múltiples caracteres arbitrarios; use dos asteriscos " **" para hacer coincidir cualquier directorio intermedio, como a/**/za / z, a / b / z o a / b / c / z etc.
6) Use un signo de interrogación "?" Para hacer coincidir un solo carácter, es decir, para hacer coincidir un carácter arbitrario;
7) Use corchetes "[]" para contener una lista de coincidencia de un solo carácter, es decir, para hacer coincidir cualquiera de los caracteres enumerados entre corchetes. Por ejemplo, [abc] significa unir a a, a b o a c; si se usa un guión para separar dos caracteres entre corchetes, significa que todos los caracteres dentro de estos dos caracteres pueden coincidir. Por ejemplo, [0-9] significa hacer coincidir todos los dígitos del 0 al 9, y [az] significa hacer coincidir cualquier letra minúscula).
8) El signo de exclamación "!" Significa que los archivos o directorios coincidentes no se ignoran (rastrean), es decir, se deben ignorar los archivos o directorios que no sean el modo especificado. Puede agregar un signo de exclamación (!) Frente al modo para revertirlo. Se necesita especial atención: si el directorio principal del archivo ha sido excluido por la regla anterior, entonces la regla "!" No funcionará para este archivo. En otras palabras, el patrón al comienzo de "!" Significa negativo, el archivo se incluirá nuevamente. Si se excluye el directorio principal del archivo, el uso de "!" No se incluirá nuevamente. Puedes usar barras invertidas para escapar.
Debe recordar: las reglas de git coinciden de arriba a abajo para el archivo de configuración .ignore, lo que significa que si la regla anterior coincide con un rango mayor, la siguiente regla no tendrá efecto;
debido a problemas de sintaxis de reducción, algunos símbolos Puede mostrar errores, así que adjunte la versión de la imagen a continuación:
Ejemplo:
# significa que este es un comentario y Git
lo ignorará. A significa ignorar todos los archivos que terminan en .a
! Lib.a significa excepto lib.a
/ TODO significa solo ignorar los archivos TODO en el directorio raíz del proyecto, excluyendo subdir / TODO
build / significa ignorar todos los archivos en el directorio build / y filtrar toda la carpeta de compilación;
doc / .txt significa ignorar doc / notes.txt pero no doc / server / arch.txt
bin /: significa ignorar la carpeta bin debajo de la ruta actual, se ignorará todo el contenido de esta carpeta, no ignorar el archivo
bin / bin: significa ignorar el archivo bin en el directorio raíz
/ .c: significa ignorar cat.c, no Ignorar build / cat.c
debug / .obj: Ignorar debug / io.obj, no ignore debug / common / io.obj y tools / debug / io.obj
/ foo: Ignore / foo, a / foo, a / b / foo, etc.
a / / b: significa ignorar a / b, a / x / b, a / x / y / b,
etc./bin/run.sh significa no ignorar el archivo run.sh en el directorio bin
* .log : Significa ignorar todos los archivos .log
config.php: significa ignorar el archivo config.php en la ruta actual
/ mtk / significa filtrar toda la carpeta
* .zip significa filtrar todos los archivos .zip
/mtk/do.c significa filtrar un archivo específico
Los archivos filtrados no aparecerán en el repositorio de git (gitlab o github), por supuesto, todavía están en la biblioteca local, pero no se cargarán cuando se envíen.
Cabe señalar, agregando gitignore también especificar los archivos de gestión de versiones, de la siguiente manera:
! .Zip
! /Mtk/one.txt
La única diferencia es el comienzo de la regla más que un signo de exclamación, Git va a satisfacer dichas reglas El archivo se agrega a la gestión de versiones. ¿Por qué hay dos tipos de reglas?
Imagine un escenario: si solo necesitamos administrar el archivo one.txt en el directorio / mtk /, y no es necesario administrar otros archivos en este directorio, entonces la regla .gitignore debería escribirse como:
/ mtk /
! /Mtk/one.txt
Suponiendo que solo tenemos reglas de filtrado sin agregar reglas, ¡entonces necesitamos escribir todos los archivos excepto one.txt en el directorio / mtk /!
Tenga en cuenta que el / mtk / * anterior no se puede escribir como / mtk /, de lo contrario, el directorio principal está excluido por las reglas anteriores, aunque se agrega el archivo one.txt. ¡Las reglas de filtro no tendrán efecto!
Hay algunas reglas de la siguiente manera:
fd1 / *
Descripción : ignore todo el contenido del directorio fd1; tenga en cuenta que si se trata del directorio / fd1 / bajo el directorio raíz o un subdirectorio / child / fd1 /, se ignorará;
/ fd1 / *
Descripción: Ignora todo el contenido del directorio / fd1 / en el directorio raíz
/ *
! .gitignore
! / fw /
/ fw / *
! / fw / bin /
! / fw / sf /
Descripción: Ignora todo, pero no los archivos .gitignore, / fw / bin / y / fw en el directorio raíz / sf / directory; use principalmente la regla! en el directorio padre de bin / para que no se excluya.
Debido al problema de sintaxis de rebajas, algunos símbolos pueden mostrar errores, así que adjunte la versión de la imagen a continuación:
13. Resumen
Este es el final de la administración local de git. Para la administración local, estos comandos son básicamente suficientes
: 1. Distinga el área de trabajo, el área de almacenamiento temporal y el área de sucursal
2. add se envía al área de trabajo, commit se envía al área de sucursal. Una vez enviado al área de sucursal, nunca se puede eliminar. Incluso si regresa a la versión anterior, aún puede encontrar la información enviada.
3. git log para ver la información de todas las versiones anteriores de la versión actual, y git reflog para ver la información de todas las versiones.
4. Cuando git commit, debe escribir la información detrás de -m
5. En realidad, olvidé decir que, si le resulta problemático, puede usar git add * para enviar todos los archivos, o git add / src para enviar todos los archivos en el directorio raíz src. El comando agregar todavía es muy flexible.
6. No es necesario memorizar el contenido especificado por git. Sé que existe tal cosa. Simplemente verifíquelo cuando lo use.
