Saltar parte del entorno
Cree un proyecto desde 0 para explicar git, incluida la creación de nuevas ramas remotas, la reversión y otras operaciones.
Habrá preguntas y preguntas durante cada explicación.
- Explicación básica de la parte
- Práctica parte avanzada
Contenido básico
Si ya tiene un almacén en github, use idea para clonar
Si está en la interfaz a continuación, siga los pasos a continuación
Realizar descarga de clonación
Si es la siguiente interfaz, pase
Lo mismo que arriba
Si no tiene un proyecto existente en github o desea crear un nuevo proyecto
Cree un nuevo proyecto ordinario a través de IDEA (lo que sea, maven está bien)
Como se muestra abajo
Un proyecto maven ordinario de TestGit (un nuevo proyecto no está controlado por versiones)
El primer paso es introducir VCS (acrónimo del sistema de control de versiones para VCS), correspondiente a la opción VCS en la parte superior de la idea. Hay ventanas y Ayuda al lado
Active el control de versiones como se muestra a continuación
Elija Git como demostración aquí
Como se muestra en la figura siguiente: hay una explicación en la captura de pantalla
En este punto, debe tenerse en cuenta que el control de versiones aquí es el almacén local.
Se enviará al envío local y al envío remoto (se requiere iniciar sesión en la cuenta de github)
Inicie sesión en github en idea como se muestra a continuación
Hay dos formas de iniciar sesión:
Cuenta + contraseña para iniciar sesión la máxima autoridad tiene todos los privilegios de la cuenta
Los permisos de inicio de sesión del token los crea el propietario de la cuenta y se asignan los permisos correspondientes.
Dirección de creación de tokens: https://github.com/settings/tokens
Como se muestra abajo:
Como se muestra en el ejemplo a continuación: debe seleccionar los permisos correspondientes asignados y completar la Nota (para la conveniencia de la administración directa más adelante, es principalmente para saber qué Token es este Token)
Después de la creación, puede iniciar sesión en el Token obtenido directamente con IDEA
Enviar localmente
En primer lugar, debe prestar atención a los archivos que deben enviarse. Seleccione el archivo ===》 haga clic con el botón derecho ===》 git ==》 agregar a la versión controlar el archivo
Errores comunes para los principiantes:
Seleccione directamente el elemento para Agregar (algunos archivos innecesarios también estarán controlados por la versión)
Mi consejo es:
Simplemente agregue la carpeta src y el archivo pom.xml a la operación Agregar, y el archivo de configuración relacionado con el código, para los siguientes archivos
carpeta .idea
archivo xxxxx.iml
Idea genera automáticamente estos archivos para no enviarlos porque estos archivos de configuración son configuraciones de entorno en su computadora.
Si se envían estos archivos, no es bueno que el equipo se desarrolle en colaboración.
Porque estos archivos se clonarán cuando el clon esté inactivo, de modo que la idea de la otra parte usará el archivo de configuración en el proyecto en lugar de cargar la configuración en su propia computadora.
La versión y la ruta específicas del jdk (es posible que la otra parte no encuentre el jdk y deba configurar manualmente el SDK) y los hábitos de uso de ideas de la otra parte y otras configuraciones serán la configuración de la idea en su propia computadora. Por lo tanto, no seleccione directamente el elemento para agregar
Asegúrese de seleccionar manualmente el archivo correspondiente usted mismo, no agregue este tipo de archivos innecesarios.
Deshacer Agregar se puede deshacer presionando Ctrl Z, o seleccionando el archivo Git como se muestra a continuación
En términos generales, solo se necesitan la carpeta Add src y el archivo pom.xml
Hay una función de envío de git. Si no hay archivos en la carpeta bajo control de versión, cuando lo envíe, encontrará que no hay carpetas como src en el almacén, sino solo un archivo pom.xml.
En otras palabras, Git solo controla las versiones de los archivos, no de las carpetas, lo que es fácil de entender.
Hacer un compromiso local
Principalmente para generar algunos datos para una demostración posterior, aquí creo una nueva clase Hello (ruta del paquete top.huashengshu) en src y la agrego a
El símbolo √ en la barra de herramientas del botón enviar
Por supuesto, también puede hacer clic derecho para enviar, o puede enviar a través de git en la barra de opciones de VCS arriba. Haga clic en el botón de arriba para enviar directamente
Haga clic en Confirmar para envío local
Para envío remoto, elija:
Ver registro después del envío local
Comparta el proyecto en el almacén remoto en github (cree si no lo hay, envíelo si lo hay y créelo directamente aquí)
Debe iniciar sesión en la cuenta de github, y luego aparecerá el siguiente cuadro emergente, ingrese el nombre del almacén, la descripción y si es privado
Corresponde a nuevo en github
Después del éxito como se muestra a continuación:
Descripción del icono:
La rama verde representa la rama local.
El amarillo es el puntero principal, la etiqueta amarilla se moverá después de la reunión de presentación local.
La captura de pantalla anterior es incorrecta, hay 3 registros de sucursales y la marca amarilla de la cabeza solo se usa para indicar la posición actual de la sucursal. Al enviar, la sucursal se retrasará de acuerdo con la marca amarilla.
Nueva sucursal local
Nueva sucursal remota
Las sucursales remotas deben ser generadas por push de sucursal local
Es decir, la operación push activará la creación de una sucursal. Si no ha enviado una sucursal remota y planea enviar la sucursal local a la remota para generar una nueva sucursal, siga los pasos a continuación.
Luego haga clic en Push para crear una nueva rama. Como se muestra a continuación, vaya a github para verificar la rama recién creada
Además, también puede presionar de la siguiente manera
Además, puede activar el empuje a través de los siguientes
Además, haga clic derecho para activar la creación de una nueva rama remota
Lo anterior es una operación de rama más básica
Parte avanzada
Incluyendo gestión de conflictos, reversión de sucursales, error de procesamiento de confirmación
Manejo de conflictos de código
En términos generales, un gran proyecto será desarrollado conjuntamente por muchas personas. A menudo enviamos y extraemos código mientras usamos Git para las operaciones diarias.
Mucha gente encontrará algunos problemas al modificar el proyecto.
Por ejemplo, el programador A envió un código por la noche
Al día siguiente se pusieron manos a la obra el programador A y el programador B. Lo primero es comprobar si el código del servidor está actualizado, es decir, la siguiente operación:
Entonces el código obtenido por el programador B es:
Después de que el programador A se puso a trabajar, de repente pensó que había un error en el código anoche, por lo que el programador A lo corrigió rápidamente y envió el código.
La versión anterior de git del programador B es la versión anterior.
Una vez que el programador A envía el código, el código del almacén remoto se convierte en
Debido a que el programador B no sabe que el programador A ha enviado el código nuevamente, y luego, después de que el programador B termina su propio código, el código en la computadora del programador B se ve así
En este momento, debido a que la versión en el servidor ha sido modificada, para asegurar que el código del programador A pueda ser retenido, el programador necesita integrar el código de la siguiente manera al presionar a la rama principal:
Aquí, debido al diferente número de líneas de código, se fusionan directamente. Porque el programador A y el programador B operan en la misma clase, pero no se afectan entre sí y se fusionan directamente.
En la confirmación y envío anteriores, se sugiere que este código de clase es diferente, y el color de fondo es su propio código, y el servidor remoto es la ventana izquierda.
Resultados finales:
Si el programador B y el programa A modifican la misma línea de código, debe confirmar manualmente si usar el código del programador A o el código del programador B, o agregar ambos.
Suponiendo que la versión del servidor es
Ambos han llevado a cabo un proyecto de actualización. Los programadores A y B han modificado el código del otro. El programador A primero envía lo siguiente:
B también modificó el código, y ambos cambiaron la misma línea de código
Pídale al programador A que envíe primero, y A puede enviar normalmente. B pedirá
Operación del programador B:
Si elige Aceptar el suyo, se sobrescribirá el código del programador A
Si elige Aceptar el suyo, los cambios del programador B en la línea no entrarán en vigor y lo enviarán.
Si elige fusionar, selecciónelo manualmente (esto generalmente se selecciona en desarrollo, porque necesita saber el código cambiado por el programador A)
El resultado de la combinación se rechazará porque el conflicto debe resolverse primero, lo que significa que la combinación se realiza localmente y luego el código se envía al control remoto después de la combinación.
En este momento, no puede usar el botón para operar, debe seleccionar una sucursal para fusionar (fusionar el almacén remoto con una sucursal local) y luego empujar la sucursal hacia arriba
En este punto, encontrará que tiene éxito y es fácil de entender. El código fusionado es más código modificado por el mismo programador B. Para git, es equivalente a una operación de una sola persona (énfasis) . Se considera seguro y natural. Puede enviar con éxito
El github final también debe ser la rama maestra actual local después de que el programador B se fusiona. El resultado final en github se muestra en la figura
La explicación es acertada y se solucionan diversas situaciones de modificación de una misma línea de código.
Para este tipo de conflicto, debe fusionarse en una rama localmente y asegurarse de que nadie más envíe el código nuevamente. Para git, solo una persona puede modificar el código a la vez. Si varias personas modifican el código, aún es necesario asegurarse de que sea a la vez. Solo una persona en el párrafo puede modificar el código y otras personas quieren enviar el código. El conflicto debe resolverse primero y luego enviarse.
Si el programador A sigue enviando, entonces el programador B debe esperar a que se envíe la versión final de A. El programador B fusiona el código del almacén remoto en el almacén local y lo envía después de resolver el conflicto. Si el programador A envía el código nuevamente durante el período de envío, entonces el programa B deberá fusionarse y luego enviarlo (solo una persona puede enviarlo correctamente en un período de tiempo)
Operación de reversión de código
Tome el programador A como ejemplo:
El registro de envío local del programador A es el siguiente
En primer lugar, debe comprender que el código de reversión tiene cuatro formas: Soft, Mixed, Hard, Keep
Para distinguir la diferencia entre suave, mixto, duro y mantener, primero debe comprender cómo git realiza el control de versiones y cuál es el principio de git.
El principio de git:
Git realiza el control de la versión al juzgar el estado del archivo. ¿Cómo juzga git el estado del archivo? Git realizará un algoritmo de valor hash en el archivo y obtendrá un valor hash a través del algoritmo hash. Si este valor hash y el Head actual (llamo Puntero de cabeza) compara el valor hash de la rama actual a la que apunta. Si es diferente, significa que el archivo actual ha sido modificado (al menos en comparación con Head)
Entonces el archivo modificado definitivamente requerirá control de versiones.Cuando enviemos el código, juzgará el valor hash actual y lo comparará con el valor hash del último proyecto actualizado localmente. Primero, juzgará la comparación entre el último hash obtenido del almacén remoto y el valor de hash realizado por el jefe en el almacén remoto. Ya sea que sea consistente o no, significa que no habrá conflicto, porque el código solo lo modifica usted. Si no es así, significa que alguien ha modificado el almacén remoto, lo que hace que el puntero principal del almacén remoto apunte a la nueva ubicación y el valor hash es el nuevo valor hash.
Es un poco como el algoritmo CAS primero para determinar si el archivo del almacén de servicios se ha modificado.
Nuestro análisis del registro de envío del programador B:
Verá que la etiqueta amarilla y las verdes y moradas apuntan a la misma ubicación
La etiqueta amarilla es la ubicación del registro de envío al que apunta el puntero principal, y la verde representa el registro de envío actual (cuando git realiza una operación de carga, primero se envía localmente, que es la marca verde. Después del envío, la marca amarilla Head señalará la misma posición que la verde )
Cuando se realiza una inserción para una confirmación remota, se inserta en un determinado registro de rama
En este momento, antes de enviar la operación, se juzgará si el código del servidor ha sido modificado por otros programadores (comparando el valor hash)
- Es decir, la computadora del programador B debe guardar el valor hash obtenido durante la última actualización cuando el almacén local fue actualizado por última vez.
- Compare el último valor hash con el valor hash de github en este momento. Determine si se ha modificado el archivo del almacén remoto. Si se ha cambiado (el valor hash en el mismo archivo). En este momento, el valor hash no es el valor hash original. Si es así, debes fusionar el almacén de github con el almacén local antes de enviar. Si no hay ningún cambio, significa que nadie ha modificado el código en github, entonces puede enviarlo directamente, porque solo una persona ha cambiado el código)
Hay 3 conceptos en Git
- Enviar registro
- Área de amortiguamiento
- Área de trabajo
El espacio de trabajo es el momento en el que nuestra idea modifica el código y las operaciones en tiempo real
El área de caché es para seleccionar manualmente los archivos que necesitan ser controlados por versión a través del comando git Add y el comando Rollback
El registro de envío es enviar los archivos en el área de caché
No se enviará a través del espacio de trabajo, sino a través de la capa intermedia de la caché.
La diferencia entre suave, mixto, duro, mantener
La pista en la idea es
Lo anterior sobre Los archivos no cambiarán se refiere al área de trabajo (es decir, modifica el archivo en tiempo real sin cambiar el contenido del archivo)
Tanto el suave como el mixto se pueden revertir Vuelva a ejecutar el puntero del cabezal en la posición que seleccionó, como se muestra en la figura siguiente.
Pero la diferencia entre las dos reversiones es que la operación suave no deshará los archivos en la caché, mientras que la mezcla hará que la caché y los registros de partición sean iguales.
Suponga que estamos hablando de agregar un archivo al área del búfer, como se muestra en la figura siguiente, haga clic derecho en agregar
Rojo significa archivos que no son administrados por git, agréguelos al caché
Después de eso, el estado del archivo cambia a verde, lo que indica que el archivo está administrado por git
Si solo realizamos una reversión suave, el estado de la caché no cambiará y el archivo tampoco cambiará
Es equivalente a suave simplemente diciendo que el puntero de la cabeza apunta a la posición de registro que eliges retroceder. El estado actual del archivo es el siguiente. Regresamos a la segunda posición de envío a través de suave
SUAVE Y MIXTA
Para demostrar el efecto, enviaremos una vez y veremos cómo fue este registro de sucursal por primera vez.
Simplemente envíe localmente, encontrará una rama más, de hecho mixto también puede lograr este efecto, siempre que el valor de hash ejecutado por el jefe sea diferente del área de caché, se puede realizar el envío
Si desea cambiar el estado de un archivo, como cancelar el control de versiones de algunos archivos, podemos elegir mezclado y retrocederá al momento seleccionado. Para los archivos bajo control de versiones, si hay algunos archivos en el área de caché que no han sido versionados en este momento, el efecto de control de versiones se cancelará como se muestra a continuación. Solo quiero mezclar al momento inicial
Si se fusiona, debe conectarse al frente
El siguiente es el elemento de actualización, es posible que no se muestre, así que simplemente actualícelo
DIFÍCIL 和 MANTENER
Difícil es fácil de entender, es decir, reversión obligatoria. Esta operación revertirá todos los estados al momento seleccionado, el archivo cambiará al envío anterior y el código volverá al anterior, no hay demostración de esto. Rodar realmente retrocedió. Y nunca regrese al estado anterior. A diferencia del anterior suave y mixto
Y mantener
Tengo entendido que HARD y KEEP operan en el espacio de trabajo
Y suave y mixto operan en el área de amortiguación
Caso real
El programador A es un antiguo empleado
El programa B es un empleado nuevo. Debido a un mal funcionamiento, la carpeta .idea se envió al github del almacén remoto. El programador principal A y otros empleados deben cambiar el entorno de la idea a su propio entorno, como SDK
problema:
Ahora es necesario eliminar la carpeta .idea del almacén remoto github a través de la operación Git de IDEA, pero el código enviado por el programador B no se eliminará
responder:
Mi enfoque es crear un caché en la computadora del empleado B que solo contenga el código integrado correctamente y no incluya la carpeta .idea en el caché de control de versiones.
Luego, cree una nueva rama a través del área de caché para omitir la rama que se envió incorrectamente a la carpeta .idea. Y configura la rama como rama predeterminada
Es decir, a través de la reversión mixta para no contener la carpeta .idea en el control de versiones, porque el método mixto no modificará el código del espacio de trabajo, pero el puntero principal apunta a la ubicación donde elige revertir. Por supuesto, debe actualizar el proyecto. Combine de forma remota en el almacén local del programador B, luego mezcle y luego agregue manualmente los archivos que deben ser controlados por versiones para el control de versiones de git.
Es mejor crear una nueva sucursal mediante push
Opere como se muestra a continuación
Estado inicial
Se puede encontrar en github que el envío está activo y ahora está reorganizado
En este momento, no se incluye en el control de versiones y se envía. Si ocurre la siguiente fusión, generalmente elija su versión, porque aquí soy una simulación, de hecho, el código debe estar basado en el espacio de trabajo local.
Entonces puedes empujar
Después del éxito, encontrará la rama newBranch creada en github
El siguiente paso es configurarlo como la rama predeterminada (debería haber operaciones correspondientes en IDEA)
Si desea eliminar la rama como se muestra a continuación
