Tutorial introductorio de GitHub: sentido común e inicio rápido de Git

Prólogo:
Tal vez antes de leer este artículo, tu concepto de Git y GitHub es todavía muy vago, tal vez pensaste que son lo mismo, pero de hecho no lo son, de hecho, los dos son cosas completamente diferentes. , Si queremos entrar por la puerta de GitHub, primero debemos cruzar la montaña de Git. El autor aquí audazmente hace una metáfora de los dos. Git es como un camión, y GitHub es un almacén, y la identidad de Git es actuar como un enlace entre cada almacén. Transporte. Por supuesto, esta analogía no es muy apropiada, y el talento literario del autor también es muy limitado. Pero creo que debes entender rápidamente qué son Git y GitHub después de leer las explicaciones y aplicaciones a continuación. No lo venderé aquí. Ingresemos al tema de hoy;

1. Los antecedentes de Git

• Git fue escrito por Linus Torvalds, el fundador del sistema Linux, en 2005. En ese momento, era solo una forma rudimentaria y no podía llamarse Git en el verdadero sentido, debido a la licencia de desarrollador del sistema de administración de versiones existente utilizado en el desarrollo del kernel de Linux. Ocurrieron cambios Para reemplazar el nuevo sistema de administración de versiones, Linus desarrolló Git más tarde sobre la base del anterior. Es bien sabido que la velocidad de actualización del kernel de Linux es insuperable en el mundo, por lo que un sistema de gestión de versiones potente y de alto rendimiento aumentará la velocidad de desarrollo. En el entorno de código abierto en ese momento, aunque se han desarrollado varios software de gestión de versiones, las funciones y el rendimiento no son satisfactorios. Además, Git fue desarrollado personalmente por Linus Torvalds, por lo que se puede decir que es impecable en términos de funcionalidad y rendimiento. La voluntad de los programadores de aceptar Git depende en gran medida de estos antecedentes para beneficiarse del desarrollo.

• De hecho, existen muchas herramientas de control de versiones en el mercado, como CSV (Concurrent Version System), SVN (Subversion), etc.

• Entonces, ¿por qué aparece Git y en qué se diferencia de otras herramientas de control de versiones? Aquí hay una por una
  
  (1) En primer lugar, la mayor diferencia entre Git y SVN, CSV es: Git se distribuye y los dos últimos Una no lo es, esta es la diferencia más esencial
  
  (2) La integridad del contenido de Git es mejor que la de SVN: el almacenamiento de contenido de Git utiliza el algoritmo hash SHA-1. Esto puede garantizar la integridad del contenido del código y reducir el daño al repositorio en caso de fallas en el disco y problemas de red.
  
  (3) La rama Git es diferente de la rama SVN: la rama no es especial en SVN, de hecho es el repositorio En otro directorio en Git, la rama casi no se da cuenta del usuario cuando llega. Sientes completamente que no hay conexión entre las dos ramas. Parece ser dos entornos diferentes, que es un poco similar al del teléfono móvil actual. El efecto de un clon de teléfono móvil.

  Nota: De hecho, hay muchas diferencias, no todas se enumeran aquí.

• Anteriormente, cuando hablamos de la diferencia entre Git y otras herramientas de control de versiones, mencionamos una palabra clave ( distribuida ). Con el desarrollo de big data ahora, se puede ver en todas partes. Luego, las herramientas de control de versiones distribuidas y las centralizadas ordinarias ¿Cuál es la diferencia entre una herramienta de control de versiones y quién es mejor?

• De hecho, este autor puede decir con certeza que no hay diferencia entre las dos arquitecturas diferentes de las herramientas de control de versiones, la que utilice dependerá totalmente de sus necesidades de trabajo.

• Echemos un vistazo al modelo de arquitectura de la herramienta de control de versiones centralizada :

Según la figura anterior, podemos ver que el almacén está almacenado en el servidor, por lo que solo hay un almacén. Es por eso que este sistema de gestión de versiones se llama centralizado. El tipo centralizado almacena todos los datos en el servidor, lo que tiene la ventaja de una fácil gestión. La desventaja es que una vez que el entorno del desarrollador no se puede conectar al servidor, no se puede obtener el código fuente más reciente y el desarrollo es casi imposible. Lo mismo ocurre cuando el servidor está inactivo, y si el servidor falla y los datos desaparecen, me temo que el desarrollador nunca volverá a ver el código fuente más reciente.

• Hablemos del modelo de arquitectura de la herramienta de control de versiones distribuida.
  
  Puedes ver en la figura que GitHub es equivalente a un puente público. A través de este puente y la herramienta Git, podemos comunicarnos con otros desarrolladores en cualquier momento y lugar. GitHub Proporcione a los usuarios almacenes de almacenamiento en la nube y pueda entregar bifurcaciones de almacén a cada usuario (tenga en cuenta que está abierto o autorizado). Fork es copiar un repositorio específico en GitHub a su cuenta. El almacén de Fork y el almacén original son dos almacenes diferentes. Los desarrolladores pueden editar en sus propios almacenes (los almacenes mencionados anteriormente todavía se almacenan en el lado del servidor). En el desarrollo real, generalmente Clonaré mi propio almacén en GitHub al local, y luego estableceré el remoto (upstream) del almacén local de Git en el lado de GitHub. La herramienta de control de versiones de la arquitectura distribuida tiene varios almacenes, lo cual es relativamente complicado. Sin embargo, dado que hay un almacén en el entorno de desarrollo local, los desarrolladores pueden desarrollar sin conectarse a un almacén remoto. Aquí hay solo ejemplos simples en la figura. De hecho, bajo las intrincadas relaciones en Internet, el modelo de Git real es mucho más complicado que el que se muestra en la figura.

Nota: En la explicación anterior, se han mencionado muchos conceptos de modelos de Git. Tal vez todavía no hayas escuchado nada, por lo que es mejor que eches un vistazo a las siguientes aplicaciones para profundizar tu comprensión.

2. Inicialización

• La instalación en un sistema
  Linux es muy simple, solo un comando:

  # Debian 发行版(Ubuntu,Kali ..):
  sudo apt install -y git
  # Red Hat 发行版(CentOS):
  sudo yum install -y git
  

  En Windows , debido a que la línea de comandos usa el comando Dos para interactuar, debe ir al sitio web oficial para descargar la versión de Windows
  Git para Windows
  . No lo mencionaré aquí por razones de espacio, porque no es el tema central de este artículo. Los lectores pueden consultar Google o Baidu. Tutoriales de instalación relacionados.
  Si es un principiante, también puede intentar usar la interfaz gráfica Git para operar

  Los usuarios de MacOs pueden usar homebrew para instalar

  brew install git
  

• Configuración Una vez
  completada la instalación, aún necesitamos configurar Git. Después de todo, así es como podemos usarlo.
  (1) Establezca su nombre. Como excelente desarrollador, otros estarán más interesados ​​en usted después de ver su código. Tienes que dejar que los demás te recuerden, por lo que ponerte un nombre es muy importante y también para distinguir el registro de identidad al enviar el código.

  git config --global user.name "firstname lastname"
  

  (2) El simple hecho de tener un nombre no es suficiente. En la Internet ilimitada, no hay nadie que pueda garantizar que no haya nadie con el mismo nombre que usted, por lo que necesitamos una identificación única que pueda representarlo, así que simplemente configure una dirección de correo electrónico. Es conveniente que otros se comuniquen con usted.

  git config --global user.email "[email protected]"
  

  (3) El libro de códigos es aburrido. ¿Por qué no decorar este mundo gris con algunos colores? Es una buena opción para poner el punto culminante.

  git config --global color.ui auto
  

  (4) ¿Qué hacen estas pocas líneas de código? Bien podría volver a su directorio HOME y echar un vistazo.

  cat .gitconfig
  ============================= .giticonfig ==========================
  [user]
  	name = firstname lastname
  	email = [email protected]
  [color]
  	ui = auto
  ================================= END ===============================
  

  Habrá un archivo adicional llamado gitconfig en su directorio HOME, el contenido dentro es lo que acabamos de configurar, también puede modificar directamente la información de configuración en este archivo para que sea la misma.

  Nota: Por supuesto, los parámetros son mucho más que estos y hay muchos parámetros que se pueden configurar.Los lectores pueden consultar la documentación oficial para la configuración.

• Inicializar el directorio de trabajo de git
  Una vez completada la instalación y configuración, necesitamos ejecutar un directorio como nuestro directorio de trabajo. Creemos un nuevo directorio para las pruebas de Git en el directorio HOME y usemos el comando Git para ingresar a este directorio. Este directorio está inicializado;

  mkdir GitTest
  
  cd GitTest
  
  git init
  

  Este es el primer comando de git que aprendiste. ¿Es simple? Echemos un vistazo a lo que hace este comando.

  ls -a
  

  Podemos ver que hay un directorio oculto adicional llamado .git en el directorio de GitTest. De hecho, guarda todo el árbol de trabajo de Git. Guarda la información de metadatos del archivo, versión histórica, registro de operaciones, etc. Espere.

3. Práctica de mando

• El
  indicador de estado de git después de que debería poder realizar la limpieza en la figura a continuación, la
  
  primera línea indica que estamos en la rama maestra (después de que init git crea automáticamente una rama maestra que es nuestra rama principal, la rama elaborará el concepto detrás)
  segundo La línea indica nuestro estado o el estado de envío inicial. La
  tercera línea indica que actualmente no tenemos archivos para enviar.

  Echemos un vistazo a un nuevo archivo:
  
  El archivo que creamos es el archivo REDEME.md. Este archivo usa la sintaxis MarkDown. Se usa para presentar el propósito de su código a las personas que ven su código. Puede tratarlo como un archivo normal. Por supuesto que También puede aprender la sintaxis de MarkDown. Sigue siendo muy útil. También se usa a menudo en el trabajo. En la imagen de arriba, puede ver que tenemos una línea adicional de indicador cuando ejecutamos el comando 'git status', y todavía está en rojo (vea la comparación Importante), su mensaje es que este archivo aún no se ha enviado, puede probar el comando dado para enviarlo

• git add
  Aquí ejecutamos el comando de acuerdo con el indicador dado arriba, y agregamos el archivo recién creado al área de almacenamiento temporal del archivo.
  
  Desde el proceso de ejecución en la figura, podemos ver que ya hemos agregado el archivo recién creado al área de almacenamiento temporal del archivo. , Pero tenga en cuenta que aún no se ha enviado.

• git commit,
  por lo que debemos enviar los archivos almacenados en el área de almacenamiento temporal nuevamente.
  
  Usé el parámetro '-m' aquí, que escribirá directamente la siguiente cadena (es decir, una descripción de nuestro envío) Ingrese este registro de envío, si no agrega este parámetro, ingresará a una interfaz de línea de interacción de comandos y luego completará la información relevante. Después de completar el envío, podemos usar el comando de estado de vista anterior para encontrar que todo el proyecto El estado se restaura a su estado original.

• git log
  A veces queremos ver el registro de envío histórico de todo el proyecto, podemos usar este comando para verlo.
  
  De acuerdo con la figura anterior, podemos ver que la información de registro de la mente está dividida en cuatro líneas. La
  primera línea representa el código Hash del envío. Este código está en este El elemento es único y se utiliza para indicar la única operación. La
  segunda línea es la información, el nombre y el correo electrónico del remitente. La
  tercera línea es la fecha y hora del envío. La
  cuarta línea es la información de descripción que se completó al enviar.

• git diff
  Ahora intentemos agregar una línea de contenido al archivo. Intente
  
  en la figura, puede ver que primero agregamos una línea de contenido al archivo, y luego usamos el comando "git diff" para ver la diferencia entre el archivo y el estado actual Puede ver que la información de salida indica que el contenido de nuestro archivo y el archivo almacenado en la rama son diferentes. El archivo actual ha agregado una línea de contenido en comparación con el original.
  Entonces todavía usamos el método anterior para enviar este cambio juntos :
  
  Puede ver que el archivo REDERME actualmente no es diferente de la última versión

Bueno, ya dominas los comandos más básicos de Git. Por supuesto, hay operaciones más avanzadas esperándote, como ramificar, retroceder, modificar la información de envío, enviar los datos del almacén local al almacén remoto y extraerlos del almacén remoto. , Clonación de proyectos, etc., porque no le importa aprender conocimientos, sino comprender, demasiado contacto a la vez no se puede digerir de inmediato, por lo que el blogger explicará las operaciones más avanzadas en detalle en el artículo más adelante en este tema. Después de ver esto, gracias por tomarse un tiempo tan valioso para leer el blog del blogger, y gracias por su actitud ávida de conocimiento, gracias por la plataforma CSDN, ¡gracias!