Git, no te limites a tirar pero no empujar, prueba estos cinco comandos para mejorar la eficiencia.
Este artículo comparte comandos prácticos que he practicado en mi trabajo de desarrollo. Estos pueden mejorar enormemente la eficiencia del trabajo y resolver muchos escenarios difíciles. A continuación se presentarán los comandos y se enumerarán los escenarios de aplicación de la enseñanza táctil para que los estudiantes puedan aprenderlo después de leerlo.
Explicación oficial: cuando desee registrar el estado actual del directorio de trabajo y el índice, pero también desee volver a un directorio de trabajo limpio, utilice git stash. Este comando guardará las modificaciones locales y restaurará el directorio de trabajo para que coincida con los encabezados enviados.
El comando Stash puede guardar código no confirmado y mantener limpio su directorio de trabajo.
Supongo que estarás pensando: ¿Por qué debería estar limpio?
Escenario de aplicación: un día está desarrollando nuevos requisitos en la rama de funciones y, de repente, el gerente de producto se acerca y le dice que hay un error en línea y que debe solucionarse de inmediato. En este punto, su función ya está a mitad de desarrollo, por lo que debe apresurarse a la rama maestra y luego verá el siguiente error:
Porque actualmente hay archivos que se han modificado, antes de dividir la rama, se requieren compromisos para mantener limpio el espacio de trabajo. Debido a que la situación era urgente, tuve que enviar rápidamente, y la información de envío también estaba escrita en "código temporal", por lo que el registro de envío de la sucursal dejó una historia oscura... (en la vida real, he visto este envío)
El alijo aprendido no será tan vergonzoso. Todo lo que necesitas hacer es:
Eso es todo, el código está guardado.
Cuando solucionas el problema en línea y vuelves a la rama de funciones, solo necesitas restaurar el código:
Cuando hay varias tiendas, puedes especificar la tienda operativa. Primero, enumere todos los registros usando la lista oculta:
Aplicar segundo registro:
Popular y descendente son lo mismo.
Ocultar código
Rellena los comentarios, o introdúcelo directamente sin rellenarlo.
Puedes ver tus alijos guardados en el menú Alijos.
Primero haga clic en la flecha pequeña al lado del registro de alijo, luego haga clic en Aplicar o abrir para restaurar el alijo.
No toque el archivo de índice ni el árbol de trabajo en absoluto (pero restablezca los encabezados en todos los modos). Esto cambiará todos los archivos modificados a "Cambios para confirmar".
Revertir su confirmación y colocar los cambios de la confirmación nuevamente en el área de almacenamiento temporal.
Generalmente, cuando usamos el comando reset, mencionaremos git reset - hard more, que puede forzar que el registro de confirmación se rastree hasta un determinado nodo. La función de git reset-soft es tal como sugiere el nombre. -Soft (soft) no solo volverá sobre el nodo, sino que también retendrá el contenido modificado del nodo.
Retrocediendo nodos, ¿por qué deberíamos conservar el contenido modificado?
Escenario de aplicación 1: a veces, el contenido que no debería enviarse se envía accidentalmente. Si desea volver a cambiar en este momento, solo puede hacerlo nuevamente y agregar otra parte de la "historia negra".
Escenario de aplicación 2: los equipos estandarizados generalmente requieren que el contenido enviado tenga responsabilidades claras y una granularidad fina para facilitar la investigación posterior del problema. Es irregular realizar dos modificaciones con diferentes funcionalidades juntas. Esta vez mi mano volvió a resbalarse y fue un error.
Después de aprender reset-soft, solo necesitas:
Reset-soft es equivalente a la medicina del arrepentimiento, dándote la oportunidad de cambiar tu pasado. Para el escenario anterior, puede revisar nuevamente y volver a enviar para mantener un registro de confirmación limpio.
Lo anterior es una confirmación que aún no se ha enviado. También puede usar este comando para los confirmados que se han enviado. Sin embargo, al presionar nuevamente, debido a que existen diferencias entre la rama remota y la rama local, debe forzar push git push -f para sobrescribir el reinicio confirmado.
Otra cosa a tener en cuenta es que cuando reset-soft especifica un número de confirmación, se restaurarán todas las modificaciones desde la confirmación hasta la confirmación más reciente, no solo la confirmación.
Por ejemplo:
Los registros de envío son c, b y a.
Restablecer a.
En este momento, el cabezal llega a A y las modificaciones de B y C se devuelven al área de almacenamiento temporal.
Dadas una o más confirmaciones existentes, aplique los cambios introducidos por cada confirmación y registre una nueva confirmación para cada confirmación. Esto requiere que su árbol de trabajo esté limpio (no se hayan realizado cambios desde cero).
Copie el compromiso enviado y aplique el nuevo compromiso a la rama.
El envío ha sido enviado, ¿por qué necesitas copiar uno nuevo?
Escenario de aplicación 1: a veces, algunos requisitos de optimización de la versión están en desarrollo y un determinado requisito en desarrollo puede suspenderse temporalmente o el requisito a desarrollar está bloqueado en línea por algún motivo. En este momento, debe eliminar el compromiso y manejarlo por separado.
Escenario de aplicación 2: a veces los registros de código en la rama de desarrollo están contaminados, lo que causa problemas cuando la rama de desarrollo se fusiona con la rama en línea. En este momento, debe extraer una rama de desarrollo limpia y luego copiar la confirmación de la rama de desarrollo anterior a la nueva rama.
Copia una sola
Ahora hay una rama de función y el registro de confirmación es el siguiente:
Necesitas copiar B a otra rama, primero copia el commitHash y luego cambie a la rama maestra.
El último registro del nodo maestro actual es a. Utilice cherry-pick para aplicar B a la rama actual.
Ver el registro más reciente una vez completado. b se ha aplicado al servidor maestro como la última confirmación. Puede ver que commitHash es diferente del anterior, pero el tiempo de envío sigue siendo el anterior. Búsqueda de WeChat Cuenta oficial de WeChat: programación back-end de Java, respuesta: Java para obtener información.
Duplicación múltiple
Lo anterior es una copia de un único envío. Echemos un vistazo a cómo elegir múltiples acciones de confirmación.
El comando anterior aplica commit1 y commit2 a la rama actual.
El comando anterior aplica todas las confirmaciones en el rango desde la confirmación1 a la confirmación2 a la rama actual (incluidas la confirmación1 y la confirmación2 es la confirmación más temprana).
Cuando cherry-pick tiene múltiples confirmaciones, puede encontrar conflictos de código y luego cherry-pick se detendrá y permitirá que el usuario decida cómo proceder. Veamos cómo solucionar esta situación.
Sigue siendo una rama de funciones, ahora necesitas copiar C, D y E a la rama principal. Primero escriba el commitHash del punto inicial c y el punto final e.
Corta hasta la rama principal y utiliza el hueso de cereza en el medio. Puede ver que C se copió correctamente. Al llegar a D, se encontró un conflicto de código y se interrumpió la selección. En este momento, el conflicto del código debe resolverse y volver a enviarse al área de almacenamiento temporal.
Luego use cherry-pick; continúe dejando que cherry-pick continúe. Finalmente, copie e y todo el proceso estará completo.
Lo anterior es un proceso completo, pero a veces puede ser necesario abandonar o salir del proceso después de un conflicto de código:
Volver a la forma en que estaba antes de la operación, como si no había pasado nada.
No vuelvas a ser como eras antes de la cirugía. Es decir, las confirmaciones que se seleccionaron exitosamente se retienen y se sale del proceso de selección.
Dadas una o más confirmaciones existentes, revierta los cambios introducidos por las confirmaciones relacionadas y registre algunas confirmaciones nuevas de esos cambios. Esto requiere que su árbol de trabajo esté limpio (sin cambios desde cero).
Restaurar envíos existentes, restaurar contenido enviado y generar registros de restauración.
Escenario de aplicación: un día, la prueba de repente te dice que hay un problema con la función que desarrollaste en línea y debes cancelarla de inmediato, de lo contrario afectará el uso del sistema.
En este momento, puede pensar en usar reset para revertir, pero si observa la última confirmación en la rama y el código de otros colegas, usar reset también eliminará esta parte del código. Debido a que la situación es urgente y no se le ocurre una buena solución, todavía usa reset voluntariamente y luego les pide a sus colegas que combinen su código (los colegas querrán golpearlos cuando lo escuchen), para que su imagen técnica tenga cayó en picado ante los ojos de sus colegas.
Responder al envío normal
Después de aprender a revertir, podrás salvar inmediatamente esta situación embarazosa.
El registro maestro ahora tiene este aspecto:
Revert abandona su propia confirmación.
Debido a que revertir generará un nuevo registro de envío, se le pedirá que edite la información de envío en este momento. Una vez completada la edición, wq guardará y saldrá.
Echemos un vistazo al registro más reciente y generemos un registro de recuperación. Aunque su registro de confirmación anterior aún se conservará, el contenido del código que modificó se retiró.
En el registro de confirmación de git, hay otro tipo de confirmación de fusión. Si desea volver a una confirmación de fusión, el uso es un poco diferente.
Ahora hay una confirmación de fusión en la rama maestra.
Utilizando el mismo método de reversión hace un momento, encontrará que la línea de comando informa un error. ¿Por qué sucede esto? Está explicado en la documentación oficial.
Revertir una fusión a menudo es imposible porque no se sabe qué lado de la fusión debe considerarse la línea principal. Esta opción especifica el número principal de la línea principal (comenzando en 1) y permite revertir los cambios relativos al número principal especificado.
Tengo entendido que la confirmación de fusión es la intersección de dos ramas y git no sabe qué rama debe deshacerse. Es necesario agregar el parámetro -m para especificar la rama maestra, el código de la rama maestra se conservará y la otra rama se retirará.
-m debe ir seguido de un número madre para identificar la "línea principal". Generalmente use 1 para reservar el código de sucursal principal.
Aún en el escenario anterior, después de revertir la rama principal y fusionarla y enviarla, luego corregir el error en la rama de características y luego fusionarla en la rama principal, encontrará que el contenido modificado por la La reversión anterior no se ha vuelto a fusionar.
Porque después de usar revertir, las confirmaciones de la rama de características aún permanecerán en el registro de la rama principal. Cuando lo fusionas nuevamente, git determina que existe el mismo commitHash e ignora las modificaciones del commit relacionado.
En este momento, primero debe restaurar la confirmación de fusión y luego restaurarla, lo cual es un poco vergonzoso. A continuación veamos la operación.
El registro actual del maestro es así.
Si vuelves a utilizar revertir, se restaurará el contenido previamente modificado mediante revertir.
Este comando gestiona la información registrada en la regrabación.
Si reset-soft es una medicina para el arrepentimiento, entonces reflog es una poderosa medicina para el arrepentimiento. Registra todos los registros de operaciones de envío para facilitar la recuperación de registros después de operaciones incorrectas.
Escenario de aplicación: un día, queda deslumbrado y descubre que envió el código en la sucursal de otra persona y lo envió a la sucursal remota. En este momento, debido a que la rama solo tiene su último envío, piensa en usar reset-hard, pero accidentalmente recuerda el commitHash incorrectamente, reinicia demasiado y el commit de su colega se pierde. No había forma, reset-hard se vio obligado a retirarse y no se pudo encontrar el commitHash, por lo que tuvo que pedirle a su colega que lo empujara nuevamente desde la sucursal local (el puño del colega de repente se endureció y era usted nuevamente) . Como resultado, su imagen técnica se desploma.
El registro de sucursal es el anterior, desea restablecerlo a b.
Hay demasiados errores de reinicio, B desapareció y el último es solo a.
En este punto, use git reflog para verificar el historial y anotar el commitHash del error de confirmación.
Reinicie nuevamente y encontrará que B ha regresado.
Para mí, un fanático de escribir comandos en lugar de herramientas gráficas, configurar comandos cortos puede aumentar la eficiencia. Aquí hay dos formas de configurar comandos cortos.
Abra el archivo de configuración global
Escriba contenido
Este artículo comparte principalmente cinco comandos prácticos de Git en desarrollo y cómo configurar comandos cortos.
Algunos de los escenarios de aplicación enumerados en el artículo no son apropiados y son solo para facilitar la comprensión de los estudiantes. Lo más importante es comprender cuál es el comando para poder aprenderlo y utilizarlo con el máximo efecto.
Bien, eso es todo para compartir hoy. Nos vemos la próxima vez~