Hexo-theme-volantis: Cómo actualizar correctamente los temas

Creado en 24 ago. 2020  ·  5Comentarios  ·  Fuente: volantis-x/hexo-theme-volantis

Si te enfocas en la creación de contenido, se recomienda usar la versión estable:

npm i hexo-theme-volantis

Al actualizar, cambie el número de versión en package.json a * y luego ejecute npm i .

Si necesita realizar cambios en los archivos de origen del tema, se recomienda la bifurcación

Consulte y modifique su bifurcación, y combínelo con su bifurcación cuando se actualice el tema.

Si modifica el código fuente del tema directamente sin bifurcación, ¡no hay forma de obtener la actualización!

Comentario más útil

Cómo actualizar correctamente un tema (Fork)

Este artículo se basa en el uso del software GitKraken , enlaces relacionados: GitKraken: Cliente Git GUI gratuito - Windows, Mac, Linux

Si ya ha clonado un tema y lo ha agregado al repositorio de su blog siguiendo el artículo Configuración de submódulos en el artículo del tema, entonces este artículo le será de gran ayuda, si aún no lo ha hecho, pruébelo. Este es el entorno de almacén para este artículo: blog warehouse Hexo-Blog , tema warehouse volantis .

1. Operación simple de GitKraken

En la interfaz de software de GitKraken, el área con el área más grande en el medio es la información de envío histórica del almacén, los detalles del registro de envío seleccionado a la derecha y alguna información relacionada con el almacén a la izquierda, concéntrese en los SUBMÓDULOS barra de opciones a la izquierda, si normalmente ha agregado el repositorio de temas de Fork al repositorio del blog, puede verlo aquí. Expanda la pestaña SUBMÓDULOS, haga clic con el botón derecho y seleccione Abrir este submódulo para abrir el submódulo:

Repositorio de blogs

image

submódulo abierto

Snipaste_2020-08-25_09-40-13

El repositorio ingresado de esta manera es su repositorio de temas, y puede ver el historial de todos los envíos, etc., en la página actual. Para evitar los efectos adversos causados ​​por algunos nombres irónicos, la configuración es la siguiente: el repositorio de Fork se denomina repositorio de temas y el repositorio de hexo-theme-volantis se denomina repositorio de volantis .

Repositorio de temas

image

En la figura, la rama donde se encuentra el repositorio de temas del Fork actual es master-theme , y la información de la última confirmación del repositorio de temas personales se muestra en el lado derecho de la figura. En la zona central, la parte superior es la sucursal del repositorio volantis marcada con master (puedes distinguirla por la imagen del Logo a la derecha). Obviamente, el repositorio de temas actual se ha quedado rezagado con respecto al repositorio de Volantis. A continuación, debemos fusionar el código en nuestro propio repositorio de temas. Si no ve la información del almacén de Volantis en la interfaz después de abrirla, significa que el almacén de Volantis no está agregado actualmente como remoto. Puede agregarlo de la siguiente manera:

Agregar información del repositorio remoto de Volantis

En la pestaña REMOTO en el panel izquierdo, haga clic en el signo más para ingresar a la interfaz que se muestra en la siguiente figura, seleccione volantis-x/hexo-theme-volantis y agréguelo.

Snipaste_2020-08-25_09-42-16

En segundo lugar, la operación de fusión de GitKraken

1. Combinar

Haga clic con el botón derecho en la rama principal del repositorio de volantis y seleccione Fusionar volantis/master en xxxx para fusionar. En cuanto a por qué no elegir Rebase, personalmente creo que es mejor mantener el historial de confirmaciones del repositorio que modificar el historial. Por lo general, la operación de fusión se completará automáticamente, pero si hay un conflicto, recibirá este recordatorio: Fusión fallida, hay conflictos de fusión que deben resolverse. Como dice, hay conflictos que deben resolverse y la pestaña derecha mostrará Fusionar la ventana detectada en conflicto , donde se muestran los archivos resueltos y en conflicto.

Haga clic en la ventana para resolver el conflicto. En esta página, la parte superior es el código local y remoto, y la parte inferior es el contenido fusionado. Puede elegir si desea seleccionar el local a la izquierda, el remoto a la derecha o ambos según la situación actual, como recuperar el historial de modificaciones. Si no está satisfecho con el resultado seleccionado, también puede modificar manualmente el contenido. en la ventana Salida Cuando haya terminado, haga clic en Guardar para finalizar la operación. (En principio, debe elegir uno de ellos, en lugar de modificar directamente el contenido de Salida)

A veces, puede encontrar un archivo eliminado por el extremo remoto y recibirá el siguiente mensaje: GitKraken no pudo determinar si mantener fuente/css/_plugins/gitalkstyl, ¿le gustaría conservarlo? GitKraken no eliminará activamente su Sin embargo, en general, no es necesario conservarlo, solo elimine el archivo .

Finalmente, después de resolver todos los archivos en conflicto, regrese a la interfaz de la lista de repositorios y haga clic en Confirmar y fusionar para completar el envío.

A. Operación de fusión

image

B. Detección de conflictos de fusión

image

C. Elija el contenido adecuado

image

D. Presentaciones

image

2. Rebase

En resumen, Rebase vuelve a colocar todos sus cambios (confirmaciones) al final de la rama pública, con la consecuencia de que a menudo puede enfrentar confirmaciones forzadas, y no es adecuado para usar con la operación Merge.Lo siguiente es un extracto de: Rebase - Sitio web oficial de Liao Xuefeng

Los conflictos pueden surgir fácilmente cuando varias personas colaboran en la misma rama. Los zapatos de los niños del post-Empuje deben tirarse primero y fusionarse localmente antes de que el Empuje pueda tener éxito.

En resumen, parece desordenado, y los zapatos de los niños obsesivo-compulsivos preguntarán: ¿Por qué el historial de confirmaciones de Git no puede ser una línea limpia? ¡En realidad se puede hacer! Git tiene una operación llamada Rebase, que algunas personas traducen como "rebase".

Características de la operación Rebase: "Organizar" el historial de confirmaciones bifurcadas en una línea recta, lo que parece más intuitivo. La desventaja es que la confirmación bifurcada local ya se ha modificado.

  • La operación Rebase puede organizar el historial local de confirmaciones bifurcadas no insertadas en una línea recta;

  • El propósito de la reorganización es que nos resulte más fácil ver los cambios en las confirmaciones históricas, ya que las confirmaciones bifurcadas requieren una comparación a tres bandas.

La ocurrencia y evitación del conflicto.

Los conflictos generalmente ocurren cuando diferentes personas modifican el mismo lugar, Git no puede manejarlo automáticamente y arroja un error para que el usuario lo resuelva. Dado que el tema aún se encuentra en la etapa adolescente, la velocidad de iteración de la actualización es relativamente rápida y el fenómeno del conflicto puede ser más obvio. Aquí hay algunas ideas para reducir este tipo de situaciones.

1. El primero es el archivo de configuración. De acuerdo con las reglas de Hexo, todas las modificaciones a la configuración se pueden realizar de forma independiente. No es necesario modificar directamente el config.yml en el repositorio de temas. Aquí puede consultar: Uso en lugar de archivos de configuración de temas . El archivo de clase de configuración es el lugar menos probable de conflicto .

2. Para archivos de estilo, de acuerdo con las reglas de cobertura de css, usar la cobertura de estilo es más alegre que modificar estilos directamente.Por ejemplo, el cursor en el tema es la idea de cobertura de estilo.

Cuarto, mantenimiento del historial de código.

Puede ver el historial de un solo archivo para comparar sus modificaciones personales y evitar al máximo la pérdida de código. Como dice el refrán, la práctica hace al maestro, y la actualización del tema ya no será una molestia después de más operaciones. Al final, espero que llegue hasta el final y finalmente regrese a la intención original de crear un blog y termine el flor ★,° :.☆( ̄▽ ̄)/$: .°★ .

registro de la historia

image

Todos 5 comentarios

@inkss, ayúdame a completar el método de bifurcación sobre cómo actualizar el tema. 😀

Cómo actualizar correctamente un tema (Fork)

Este artículo se basa en el uso del software GitKraken , enlaces relacionados: GitKraken: Cliente Git GUI gratuito - Windows, Mac, Linux

Si ya ha clonado un tema y lo ha agregado al repositorio de su blog siguiendo el artículo Configuración de submódulos en el artículo del tema, entonces este artículo le será de gran ayuda, si aún no lo ha hecho, pruébelo. Este es el entorno de almacén para este artículo: blog warehouse Hexo-Blog , tema warehouse volantis .

1. Operación simple de GitKraken

En la interfaz de software de GitKraken, el área con el área más grande en el medio es la información de envío histórica del almacén, los detalles del registro de envío seleccionado a la derecha y alguna información relacionada con el almacén a la izquierda, concéntrese en los SUBMÓDULOS barra de opciones a la izquierda, si normalmente ha agregado el repositorio de temas de Fork al repositorio del blog, puede verlo aquí. Expanda la pestaña SUBMÓDULOS, haga clic con el botón derecho y seleccione Abrir este submódulo para abrir el submódulo:

Repositorio de blogs

image

submódulo abierto

Snipaste_2020-08-25_09-40-13

El repositorio ingresado de esta manera es su repositorio de temas, y puede ver el historial de todos los envíos, etc., en la página actual. Para evitar los efectos adversos causados ​​por algunos nombres irónicos, la configuración es la siguiente: el repositorio de Fork se denomina repositorio de temas y el repositorio de hexo-theme-volantis se denomina repositorio de volantis .

Repositorio de temas

image

En la figura, la rama donde se encuentra el repositorio de temas del Fork actual es master-theme , y la información de la última confirmación del repositorio de temas personales se muestra en el lado derecho de la figura. En la zona central, la parte superior es la sucursal del repositorio volantis marcada con master (puedes distinguirla por la imagen del Logo a la derecha). Obviamente, el repositorio de temas actual se ha quedado rezagado con respecto al repositorio de Volantis. A continuación, debemos fusionar el código en nuestro propio repositorio de temas. Si no ve la información del almacén de Volantis en la interfaz después de abrirla, significa que el almacén de Volantis no está agregado actualmente como remoto. Puede agregarlo de la siguiente manera:

Agregar información del repositorio remoto de Volantis

En la pestaña REMOTO en el panel izquierdo, haga clic en el signo más para ingresar a la interfaz que se muestra en la siguiente figura, seleccione volantis-x/hexo-theme-volantis y agréguelo.

Snipaste_2020-08-25_09-42-16

En segundo lugar, la operación de fusión de GitKraken

1. Combinar

Haga clic con el botón derecho en la rama principal del repositorio de volantis y seleccione Fusionar volantis/master en xxxx para fusionar. En cuanto a por qué no elegir Rebase, personalmente creo que es mejor mantener el historial de confirmaciones del repositorio que modificar el historial. Por lo general, la operación de fusión se completará automáticamente, pero si hay un conflicto, recibirá este recordatorio: Fusión fallida, hay conflictos de fusión que deben resolverse. Como dice, hay conflictos que deben resolverse y la pestaña derecha mostrará Fusionar la ventana detectada en conflicto , donde se muestran los archivos resueltos y en conflicto.

Haga clic en la ventana para resolver el conflicto. En esta página, la parte superior es el código local y remoto, y la parte inferior es el contenido fusionado. Puede elegir si desea seleccionar el local a la izquierda, el remoto a la derecha o ambos según la situación actual, como recuperar el historial de modificaciones. Si no está satisfecho con el resultado seleccionado, también puede modificar manualmente el contenido. en la ventana Salida Cuando haya terminado, haga clic en Guardar para finalizar la operación. (En principio, debe elegir uno de ellos, en lugar de modificar directamente el contenido de Salida)

A veces, puede encontrar un archivo eliminado por el extremo remoto y recibirá el siguiente mensaje: GitKraken no pudo determinar si mantener fuente/css/_plugins/gitalkstyl, ¿le gustaría conservarlo? GitKraken no eliminará activamente su Sin embargo, en general, no es necesario conservarlo, solo elimine el archivo .

Finalmente, después de resolver todos los archivos en conflicto, regrese a la interfaz de la lista de repositorios y haga clic en Confirmar y fusionar para completar el envío.

A. Operación de fusión

image

B. Detección de conflictos de fusión

image

C. Elija el contenido adecuado

image

D. Presentaciones

image

2. Rebase

En resumen, Rebase vuelve a colocar todos sus cambios (confirmaciones) al final de la rama pública, con la consecuencia de que a menudo puede enfrentar confirmaciones forzadas, y no es adecuado para usar con la operación Merge.Lo siguiente es un extracto de: Rebase - Sitio web oficial de Liao Xuefeng

Los conflictos pueden surgir fácilmente cuando varias personas colaboran en la misma rama. Los zapatos de los niños del post-Empuje deben tirarse primero y fusionarse localmente antes de que el Empuje pueda tener éxito.

En resumen, parece desordenado, y los zapatos de los niños obsesivo-compulsivos preguntarán: ¿Por qué el historial de confirmaciones de Git no puede ser una línea limpia? ¡En realidad se puede hacer! Git tiene una operación llamada Rebase, que algunas personas traducen como "rebase".

Características de la operación Rebase: "Organizar" el historial de confirmaciones bifurcadas en una línea recta, lo que parece más intuitivo. La desventaja es que la confirmación bifurcada local ya se ha modificado.

  • La operación Rebase puede organizar el historial local de confirmaciones bifurcadas no insertadas en una línea recta;

  • El propósito de la reorganización es que nos resulte más fácil ver los cambios en las confirmaciones históricas, ya que las confirmaciones bifurcadas requieren una comparación a tres bandas.

La ocurrencia y evitación del conflicto.

Los conflictos generalmente ocurren cuando diferentes personas modifican el mismo lugar, Git no puede manejarlo automáticamente y arroja un error para que el usuario lo resuelva. Dado que el tema aún se encuentra en la etapa adolescente, la velocidad de iteración de la actualización es relativamente rápida y el fenómeno del conflicto puede ser más obvio. Aquí hay algunas ideas para reducir este tipo de situaciones.

1. El primero es el archivo de configuración. De acuerdo con las reglas de Hexo, todas las modificaciones a la configuración se pueden realizar de forma independiente. No es necesario modificar directamente el config.yml en el repositorio de temas. Aquí puede consultar: Uso en lugar de archivos de configuración de temas . El archivo de clase de configuración es el lugar menos probable de conflicto .

2. Para archivos de estilo, de acuerdo con las reglas de cobertura de css, usar la cobertura de estilo es más alegre que modificar estilos directamente.Por ejemplo, el cursor en el tema es la idea de cobertura de estilo.

Cuarto, mantenimiento del historial de código.

Puede ver el historial de un solo archivo para comparar sus modificaciones personales y evitar al máximo la pérdida de código. Como dice el refrán, la práctica hace al maestro, y la actualización del tema ya no será una molestia después de más operaciones. Al final, espero que llegue hasta el final y finalmente regrese a la intención original de crear un blog y termine el flor ★,° :.☆( ̄▽ ̄)/$: .°★ .

registro de la historia

image

Ilustrado y detallado.

muy bien, marca

¿Cómo cambiar el tema en gitee?

¿Fue útil esta página
0 / 5 - 0 calificaciones