Creación de un sitio web con Jekyll y GitHub Pages

Podemos crear y publicar gratuitamente un sitio web estático sencillo, creado con HTML, Twitter Bootstrap, GitHub Pages, y si así lo queremos, también un generador de sitios web estáticos como Jekyll.

GitHub Pages ofrece, para este cometido, un plan gratuito y planes de pago, a través de sus cuentas personales, empresariales o de organización (ver precios).

Al mencionar sitios gratuitos, no me refiero a sitios que deban contener publicidad, ni logotipos de patrocinio, ni sitios propiedad de terceros como Blogguer o WordPress.com, sino sitios web de calidad, rápidos, sobre los que tendremos el control total, y que podremos integrar con JavaScript y Frameworks relacionados, como p. ej. REACT.

Lecturas previas

Necesarias:

🗃 Jekyll, generador de sitios web estáticos. Comprender mínimamente acerca de Jekyl y los sitios web estáticos, en contraposición con los dinámicos.

Opcionales:

🗃 Markdown: Introducción, guía rápida y sintaxis. Aunque no en la instalación inicial del sitio, Markdown será imprescindible en la redacción de contenido. Markdown es un lenguaje legible y fácil de aprender.

🗃 Introducción a CSS y sintaxis básica. Igual que con Markdown, necesitaremos una buena base de comprensión de la aplicación de estilos con CSS.

Sobre Jekyll

Jekyll es un generador de sitios estáticos con soporte integrado para páginas de GitHub. Es libre (open source), gratuito, y permite crear sitios veloces y seguros.

Características de un sitio web construido con Jekyll y GitHub Pages

Una de las premisas principales de este tipo de sitios web, es crear una red de documentos, los cuales se sincronizarán entre nuestro equipo local y nuestro repositorio remoto en GitHub Pages. Esto, unido al uso del lenguaje Markdown para la redacción de contenido, nos dará una gran comodidad a la hora de construir.

Puede crear/editar/eliminar los archivos del repositorio en su equipo local, o bien en la página GitHub en remoto. En ambos casos podrá sincronizar los archivos entre local y remoto.

Si quiere previsualizar los cambios antes de publicarlos, puede editar localmente en vez de en GitHub.

Una vez realizados cambios locales en archivos del proyecto, deberá realizar commits de tus cambios.

La idea genial de un sitio con GitHub Pages y Jekyll es mantener una estructura de documentos Markdown en nuestro equipo local, y mientras escribimos en Markdown de forma natural, sin preocuparnos por la sintaxis HTML salvo en casos específicos, los documentos son publicados, automáticamente pero bajo nuestro control, tras enviarlos a la rama apropiada o enviarlos a un flujo de trabajo con el uso de GitHub Actions.

Un sitio web Jekyll no es para todos los casos de uso

Como ya se describe en Jekyll, los sitios construidos con este no son ideales para todos los casos de uso. Se trata de sitios estáticos, donde por definición no existe tecnología backend (de servidor).

Creación del repositorio en GitHub

[docs.github.com#config] El primer paso es crear una cuenta o iniciar sesión en GitHub. Una vez hecho, creamos un repositorio público, y seguimos el resto de pasos descritos en 🌐 GitHub Pages.

Observe: aunque puede crear un repositorio privado, no podrá publicar un sitio web desde este.

Al crear el repositorio, escoja la opción de añadir un archivo .gitignore. Este especifica que archivos o directorios deben ser ignorados por Git, y por tanto no se subirán al repositorio de Git. Podemos usarlo para excluir archivos temporales o de configuración.

Preste atención a la primera información que GitHub Pages nos ofrece, ya que es importante: «Obtendrá un sitio por cuenta y organización de GitHub, y sitios de proyectos ilimitados…»

Por lo tanto, puede crear los sitios web gratuitos que necesite, simplemente tenga en cuenta que solo uno de estos sitios será de Usuario/Organización, y el resto serán de proyecto.

Front Matter o cabecera YAML

Cada página o post en Jekyll puede tener un front matter o cabecera YAML en la parte superior del archivo, que almacena metadatos y variables en formato YAML.

El lenguaje de plantillas Liquid, usado por Jekyll, puede acceder a estos metadatos para generar contenido.

El front Matter YAML debe estar al inicio del archivo, y estar encerrado entre cadenas de 3 guiones simples. Tiene este aspecto:

---
layout: post
title: Tecnologia, programación, Linux y software libre
---

GitHub Desktop

GitHub Desktop es una aplicación libre bajo licencia MIT y gratuita, para ayudar a los usuarios a trabajar con código alojado en GitHub u otros servicios Git, proporcionando una interfaz gráfica que simplifica muchas tareas comunes asociadas con el control de versiones y la gestión de repositorios.

GitHub Desktop está basado en Electron, escrito en TypeScript y utiliza React.

Sin embargo, aunque GitHub Desktop facilita muchas tareas, también es posible aprovechar todas las capacidades de GitHub y GitHub Pages sin esta aplicación, usando la interfaz web de GitHub o la línea de comandos si se prefiere.

Instalación y configuración de GitHub Desktop

La descarga de GitHub Desktop para Windows y Mac es inmediata desde su 🌐 página de descargas, sin embargo para Linux hay que realizar algunas acciones más, aunque hay opciones para un gran número de distribuciones: Debian y derivados como Ubuntu, Red Hat, CentOS, Fedora, OpenSUSE, Arch Linux, … Así, para instalar en un Linux, seguimos las instrucciones de la 🌐 página del fork de Linux de GitHub Desktop.

Una vez instalada y abierta la aplicación, debemos autenticar GitHub Desktop con nuestra cuenta en GitHub or GitHub Enterprise. Para ello, siga la recomendación indicada en la interfaz de la aplicación, sobre iniciar sesión en GitHub.

Clonado del repositorio

Siguiendo las indicaciones en 🌐 el sitio de GitHub Pages, toca clonar el repositorio en nuestro equipo.

En este ejemplo asumiremos el uso de la interfaz gráfica de GitHub Desktop.

Con sesión iniciada en GitHub Desktop, en el apartado Your repositories de la aplicación deberíamos ver todos los repositorios.

1. Seleccionamos el repositorio elegido,
2. Seleccionamos el botón inferior izquierdo Clone .
3. Ajustamos Local path para que apunte al directorio en nuestro equipo en el que guardaremos el proyecto.
4. Clonamos con el botón Clone.

Otra alternativa es el clonado a través del terminal de comandos:

git clone https://github.com/nombre_usuario/nombtre_repositorio.git

La URL exacta del repositorio la encontraremos en la la interfaz web de GitHub, en la página de nuestro repositorio, pulsando el botón Code.

Actualizar cambios en el repositorio desde GitHub Desktop

Una vez hecho un cambio, como editar o añadir un archivo al proyecto, debemos confirmarlo. Podemos hacer esto desde GitHub Desktop.

Vemos el/los cambios desde la pestaña Changes de la interfaz de GitHub Desktop. Los aplicamos con el botón Commit to main.

Tras esto, observe el aviso Push commits to the origin remote. Nos indica que hay cambio/s pendiente/s de sincronizar en remoto con GitHub. Lo solventamos pulsando el botón Push origin.

Creación del archivo index.html

Abra su editor de texto plano, cree el archivo index.html, y guárdelo en la carpeta raíz del proyecto (el directorio que acabamos de definir para el proyecto). Recuerde que, si lo desea, puede también crear el archivo directamente en remoto, desde la página de su repositorio.

Le proponemos un archivo index.html más extenso que el que ofrece la documentación, para que le sirva de ejemplo. Escriba el siguiente texto:

---
layout: default
title: Home
---

<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>{{ page.title }}</title>
</head>
<body>

  <header>
    <h1>{{ site.title }}</h1>
    <p>{{ site.description }}</p>
  </header>

  <nav>
    <ul>
      <li><a href="{{ '/' | relative_url }}">Inicio</a></li>
      <li><a href="{{ '/sobre-nosotros' | relative_url }}">Sobre nosotros</a></li>
      <li><a href="{{ '/contacto' | relative_url }}">Contacto</a></li>
    </ul>
  </nav>

  <main>
    <h2>Bienvenido a {{ site.title }}!</h2>
    <p>Esta es la página home de su sitio web.</p>
    <p>Escriba el contenido que desee entre las etiqueta \<main> y  \</main></p>

    <!-- Listado de artículos recientes -->
    <h3>Artículos recientes</h3>
    <ul>
      {% for post in site.posts %}
        <li>
          <a href="{{ post.url | relative_url }}">{{ post.title }}</a>
          <small>{{ post.date | date: "%B %d, %Y" }}</small>
        </li>
      {% endfor %}
    </ul>
  </main>

  <footer>
    <p>&copy; {{ site.time | date: "%Y" }} {{ site.author }}. Todos los derechos reservados</p>
  </footer>

</body>
</html>

En el Front Matter:

• layout: default. Indica que este archivo usa el layout default. Este layout se define en _layouts/default.html.
• title: Home. Define el título de la página, que puede ser accedido con {{ page.title }}

La sintaxis HTML

• Encabezado (<header>). Muestra el título y la descripción del sitio definidos en _config.yml usando {{ site.title }} y {{ site.description }}.
• Navegación (<nav>). Proporciona enlaces a otras páginas del sitio como «Sobre nosotros» y «Contacto». Los enlaces usan {{ ‘/ruta’ | relative_url }} para asegurar que funcionen correctamente en GitHub Pages.
• Contenido Principal (<main>). Un mensaje de bienvenida y una lista de las publicaciones recientes del blog. Las publicaciones se generan automáticamente usando un bucle Jekyll {% for post in site.posts %}.
• {% for post in site.posts %} … {% endfor %}. Se trata de un bucle. Una instrucción especial que ejecuta una o varias instrucciones repetidamente, un determinado número de veces o hasta que se cumpla una condición. En este caso, la condición es: Tantas veces como artículos haya en el sitio web.
• Pie de página (<footer>). Muestra el copyright y el año actual, que se extrae dinámicamente usando {{ site.time | date: "%Y" }} y {{ site.author }}.

Observe y recuerde:

• El archivo index.html, también podría ser index.md. Es decir, un archivo Markdown en vez de uno HTML:
  • Sea cual sea de los dos, añada una cabecera YAML; si no sabe como hacerla, copie la del ejemplo anterior
  • Si crea un archivo HTML, escriba con código y sintaxis HTML, y si es un Markdown (extensión .md), escriba en Markdown.
• Los navegadores web no interpretan Markdown directamente, sin embargo puede usarlo aquí porque Jekyll se encarga de compilarlo a HTML.

Envío de Commits desde GitHub Desktop a GitHub Pages

Un commit es una especie de instantánea de un proyecto en un determinado momento. Cuando realiza cambios en los archivos del proyecto, debe hacer un commit para que estos queden guardados. Puede hacer esto desde GitHub Desktop, con el botón Commit to nombre_del_branch.

Después de realizar uno o muchos commits, debe enviar estos cambios desde el equipo local al repositorio remoto en GitHub Pages, o hacer un push. Este puede hacerse también a través de GitHub Desktop. En la interfaz de este último, tras detectar los cambios, aparecerá el botón Push origin. Al pulsarlo, se enviarán los commits al servidor de GitHub.

Finalmente, GitHub Pages actualizará automáticamente su sitio web con los cambios enviados.

GitHub Actions

| Documentación de GitHub Actions |

GitHub Actions es una plataforma de integración y entrega continuas (CI/CD) integrada en GitHub Pages, que nos permite automatizar los procesos de compilación, prueba e implementación.

Compilación del sitio desde GitHub Actions

[docs.github.com#jekyll] GitHub Pages permite utilizar como origen de la compilación:

• Una rama (opción Deploy from a branch). Es la opción fácil y clásica, o bien…
• GitHub Actions. Más avanzado. Mejor para controlar y personalizar el proceso de compilación.

Aunque las dos opciones son completamente viables, este artículo se enfoca únicamente en la configuración con GitHub Actions para tratar crear un sitio que nos permita más posibilidades. Tendremos mucho más poder de personalización y control sobre la compilación. Así que modificamos este valor en:

Página de nuestro repositorio en GitHub > pestaña Settings > opción de menú Pages > apartado Build and deployment > lista desplegable Source > seleccionar GitHub Actions

A continuación aparecen dos opciones:

• GitHub Pages Jekyll. Crear un sitio Jekyll, o bien…
• Deploy static files in a repository without a build. Simplemente desplegar archivos estáticos en un repositorio sin una compilación.

Para el propósito de este artículo, elegimos la opción GitHub Pages Jekyll, y esta caja pulsamos Configurar.

A continuación, GHP propone la creación el directorio .github/workflows/ y dentro, el archivo jekyll-gh-pages.yml. Pulse el botón Commit changes para crearlos.

Algunas verificaciones y posibles errores

Llegados a este punto, debería tener listo y publicado un pequeño sitio web, que verá accediendo a https://nombre_usuario.github.io/nombre_del_repositorio.

Recuerde que si utiliza la cuenta gratuita de GitHub Pages, el respositorio debe ser público para que su sitio web también lo sea. En caso de que haya creado un sitio privado, resuélvalo en GitHub.com > pestaña Settings > Opción del sidebar General > apartado Danger Zone > Change repository visibility > botón Change visibility > cambiar a público.

Con la sesión iniciada en GitHub, entre en su repositorio, y después en la pestaña Settings. Aquí, dentro del apartado General, podrá ver el nombre del repositorio.

Entre ahora en la opción del menú Pages en la columna izquierda. En la parte central podrá ver la URL pública del sitio, en la línea de texto Your site is live at…

Sin moverse de Pages, en el apartado Source, en caso de que esté seleccionada la opción ‘Deploy from a Branch’, verifique que la rama seleccionada es main, y que toma los archivos desde el directorio raíz / (root).

Configurar un dominio personalizado

[docs.github.com#dominios] A continuación enlazaremos nuestro propio dominio al sitio web, el cual pasará de ser «https://nombre_usuario.github.io/nombre_del_repositorio» a simplemente «https://midominio.com», donde .com es solo una posible extensión.

El dominio lo podemos comprar en cualquier registrador de dominio. Por lo general, todas las empresas que ofrecen alojamiento web (hosting) ofrecen también el servicio de registro de dominio, y sus propios servidores DNS. Vea aquí un artículo sobre diferentes sitios que ofrecen servicios de hosting de calidad.

Es evidente que este es un paso opcional, aunque importantísimo para dar la imagen de sitio con identidad propia y crear imagen de marca.

Es importante configurar tanto el dominio apex/raíz (dominio-ejemplo.com), como el dominio con el subdominio ‘www’ (www.dominio-ejemplo.com).

Si los configuramos correctamente, GitHub Pages creará las redirecciones automáticas oportunas, entre la versión con y sin ‘www’.

[docs.github.com#configurar-subdominio] Los pasos para configurar un dominio propio, son básicamente tres:

1. Añadir el dominio en los ajustes del repositorio.
2. Crear un archivo llamado CNAME, con una sola línea que contenga el dominio personalizado.
3. Añadir, en nuestro proveedor DNS o registrador de dominios, los siguientes registros DNS: A, ALIAS o ANAME, y un registro CNAME. Tras la creación de los registros, los cambios no serán inmediatos Habremos de esperar a que los registros DNS se propaguen, lo cual podría tardar hasta 48 horas.

Los tres puntos se exponen con más detalles en los próximos títulos.

Añadir el dominio en los ajustes del repositorio

Configuramos el dominio personalizado en los ajustes del repositorio:

Página web de nuestro repositorio en GitHub > pestaña Settings > opción de menú Pages > en el apartado Custom domain, introducir nuestro dominio propio > guardar con Save

Tras la inserción del nombre de dominio, la verificación DNS en Settings > Pages > Custom domain, nos arrojará el error DNS check unsuccessful. Este error es normal y permanecerá hasta que añadamos los registros DNS adecuados.

Crear el archivo CNAME

• Este archivo no tiene extensión, así que su nombre es simplemente CNAME.
• Debe estar alojado en el directorio raíz del repositorio.
• Puede crearlo con cualquier editor de texto plano, como Vim, Atom o Zettlr, …
• Solo debe contener una línea de texto, donde esté el nombre del dominio, p. ej. dominio-ejemplo.com.
• Recuerde sincronizar los cambios a GitHub Pages si lo ha creado en su equipo local, o viceversa. Puede hacer esto enviando un commit desde GitHub Desktop, pestaña Changes (cambios).

Añadir los registros DNS en nuestro proveedor de nombres de dominio

Este paso es diferente para cada registrador de dominio, ya que cada uno dispone de su propia interfaz web. Sin embargo, la operación es similar en todos.

Registros A. Apunte su domino apex/raíz a las direcciones IP de GitHub Pages. Para ello, cree 4 registros A:

• Nombre de host: mi_dominio.com. Apunta a: 185.199.108.153
• Nombre de host: mi_dominio.com. Apunta a: 185.199.109.153
• Nombre de host: mi_dominio.com. Apunta a 185.199.110.153
• Nombre de host: mi_dominio.com. Apunta a: 185.199.111.153

Consultar Configuring an apex domain de la documentación para crear otro tipo de registros.

Registro CNAME. Configure el subdominio www:

• Nombre de host: www . Apunta a: usuario_GitHub.github.io (no incluya el nombre del repositorio).

Sustituya ‘mi_dominio.com’ y ‘usuario_GitHub’ con los valores adecuados a su proyecto.

Verificar en GitHub Pages la configuración DNS

Una vez concluidos todos los pasos y vuelta a comprobar con el botón Check again, deberíamos ver que la advertencia cambia a un mensaje de éxito DNS check successful.

Recordemos nuevamente que antes configuramos el sitio para publicar con un flujo personalizado de GitHub Actions. Si desea cambiar esta configuración, revise la descripción anterior.

Advertencia sobre la propagación de DNS

Cada vez que crea registros DNS, los cambios no se aplican instantáneamente, sino que debe esperar a que concluya la propagación de DNS. Esta puede tardar hasta 48 horas, por lo que es esencial tener esto en cuenta para no volverse loco buscando errores inexistentes, antes de que concluya la propagación.

Puede utilizar DNS Checker para verificar en tiempo real la propagación DNS.

Habilitar HTTPS en GitHub Pages: Configuración de un certificado SSL de Let’s Encrypt

Muchas veces nuestro proveedor, al que le hemos comprado el dominio, nos incluye con la compra un certificado SSL. Sin embargo GitHub Pages ofrece integración automática con los certificados de Let’s Encrypt, por lo que instalar estos será mucho más sencillo.

Una vez configurado el dominio personalizado, y los registros DNS se hayan propagado, podremos volver a la configuración en GitHub:

Visitar la página de nuestro repositorio > pestaña Settings > Pages > Custom domain > habilitamos la casilla Enforce HTTPS

Y esto es todo. GitHub Pages se encargará del resto, incluyendo la generación y renovación automática del certificado SSL a través de Let’s Encrypt.

Flujos de trabajo (Workflows)

Un Workflow es un conjunto de instrucciones definidas en un archivo YAML que especifica cómo y cuándo ejecutar ciertas tareas en nuestro repositorio. Cada workflow está compuesto por uno o más trabajos (jobs), y cada trabajo contiene uno o varios pasos (steps), que se ejecutan secuencialmente.

Los workflows de GitHub Pages se escriben en YAML y son parte de GitHub Actions.

Cada workflow es un archivo YAML dentro del directorio .github/workflows/ de nuestro repositorio. Por ejemplo, .github/workflows/deploy.yml

Los workflows se desencadenan a través de eventos específicos.

Observe: en Linux, los directorios que empiezan con un punto son directorios ocultos. Podemos hacerlos alternar entre visibles y ocultos de nuevo con la combinación de teclas Ctrl + H.

El siguiente es un archivo Workflow predeterminado que GitHub descarga automáticamente dentro del directorio .github/workflows/ de nuestro equipo, al realizar la primera configuración Jekyll. Como podrá ver contiene, entre otras, la acción actions/checkout@v4.

# Sample workflow for building and deploying a Jekyll site to GitHub Pages
name: Deploy Jekyll with GitHub Pages dependencies preinstalled

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["main"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Pages
        uses: actions/configure-pages@v5
      - name: Build with Jekyll
        uses: actions/jekyll-build-pages@v1
        with:
          source: ./
          destination: ./_site
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

…donde:

• ‘name: Deploy GitHub Pages’, es el nombre del repositorio
• ‘on:’ Define los eventos que desencadenan el workflow
• ‘jobs:’ define los trabajos a ejecutar

Ampliar información: 🌐 About workflows

Acciones (Actions)

Las acciones se pueden combinar y reutilizar para formar un trabajo (job). Pueden ser acciones predefinidas por GitHub o acciones personalizadas escritas por nosotros mismos.

Ampliar información: 🌐 Directorio de acciones predefinidas de GitHub

Para poder utilizar una acción, como por ejemplo actions/checkout dentro de nuestro proyecto, debemos incluir esta en un Workflow.

Es muy posible que dentro del directorio raíz de su proyecto ya exista el directorio .github/workflows/, ya que en al definir GitHub Actions como fuente, GitHub nos da la oportunidad de configurar Jekyll. Al hacerlo, GItHub crea el directorio mencionado. En caso contrario, puede crearlo usted mismo, así como crear también sus propios archivos YAML.

actions/checkout

La acción actions/checkout clona el contenido del repositorio en el entorno de ejecución de GitHub Actions. Por ello, es esencial en la mayoría de los workflows, ya que prepara el entorno de trabajo al traer el contenido del repositorio.

Ampliar información: 🌐 Documentación de GitHub Actions

El archivo _config.yml

[docs.github.com#config-yaml] Crearemos a continuación, con un editor de texto plano, el archivo _config.yml, en el directorio raíz del proyecto. En este, podemos definir temas y plugins que usará nuestro sitio, y muchas otras opciones de configuración. A continuación tiene un texto de ejemplo para _config.yaml. Adapte los datos a los de su proyecto.

# Ajustes del sitio. Archivo _config.yml
title: "QE2computing"
description: "Tecnología, programación, Linux y software libre"
baseurl: "" # Si el sitio web está en un subdirectorio, como p. ej. "/blog"
url: "https://QE2computing.com.github.io" # La URL de su sitio sin el subdirectorio
author: "Javier R"

# Configuración
markdown: kramdown
theme: minima # Cambie el tema si desea usar uno diferente

# Permalinks
permalink: /:categories/:title.html

# Plugins
plugins:
  - jekyll-feed
  - jekyll-sitemap
  - jekyll-seo-tag
  - jekyll-paginate
  - jekyll-archives
  - jekyll-admin
# Optional settings
timezone: "Europe/Madrid" # Ajuste según su zona horaria
language: "es"

# Exclude from processing
exclude:
  - Gemfile
  - Gemfile.lock
  - node_modules
  - vendor/bundle
  - vendor/cache
  - vendor/gems
  - vendor/ruby

Añadir un tema Jekyll al sitio

| Listado de temas soportados |

1. Crear, si no existe aún, el archivo _config.yml, en el directorio raíz del proyecto.
2. Añadir a _config.yml la línea theme: nombre_del_tema donde nombre_del_tema debe ser un tema de entre los soportados. Su nombre debe escribirse tal como aparece en el archivo _config.yml del tema

Observe: no es necesario clonar el theme (tema) a nuestro repositorio, sino solo indicar el nombre de este, en _config.yml.

Creación del archivo _includes/head.html

Si en su proyecto no existen ni el archivo _layouts/default.html, ni _includes/head.html , cree este último en la raíz del proyecto, e inserte en este el siguiente texto:

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>{{ page.title }} - {{ site.title }}</title>
  <link rel="stylesheet" href="{{ '/assets/css/style.css' | relative_url }}">
</head>

Este archivo normalmente contiene la sección del HTML, donde se incluyen enlaces a archivos CSS, meta etiquetas, scripts, etc.

Personalizar el CSS del sitio web

Cree un nuevo archivo /assets/css/style.scss, a partir del directorio raíz del repositorio.

Insertar el siguiente texto en style.scss:

---
---

@import "{{ site.theme }}";
/* CSS personalizado */

…donde:

• site.theme es literal. Es decir, son variables que debe escribir literalmente, tal cual se exponen.
• La cabecera vacía YAML (delimitada por —) no debe omitirse. Esta producirá que Jekyll procese correctamente el archivo.

Agregue todo el CSS personalizado que necesite después de la línea @import "{{ site.theme }}";

Observe lo siguiente:

• La línea indicada en el punto anterior, en el archivo _includes/head.html: <link rel="stylesheet" href="{{ '/assets/css/style.css' | relative_url }}"> sirve para enlazar al proyecto el archivo CSS creado en este punto.
• A pesar de que hemos creado creado un archivo SCSS, se indica en esta línea como un CSS, debido a que un preprocesador convertirá el código SCSS en CSS.
• En Jekyll, las rutas relativas se resuelven desde la raíz del sitio, no desde el directorio donde se encuentra el archivo que enlaza. En otras palabras, la ruta relativa ‘/assets/css/style.css’ es correcta tal cual está, dondequiera que esté el archivo que enlaza la ruta.
• Por lo expuesto en los dos puntos anteriores, la instrucción <link rel="stylesheet" href="{{ '/assets/css/style.css' | relative_url }}"> es correcta.

Referencias

🌐 [docs.github.com#config] Acerca de las Páginas de GitHub y Jekyll
[docs.github.com#config-yaml] Configuring Jekyll in your GitHub Pages site
🌐 [docs.github.com#dominios] Configurar un dominio personalizado
🌐 [docs.github.com#dominio-apex] Configuring an apex domain
🌐 [docs.github.com#configurar-subdominio] Configurar subdominio. GitHub se refiere a la cadena ‘www’ que antecede al nombre del dominio, como a otro subdominio más, como p. ej. en blog.dominio-ejemplo.com
🌐 [docs.github.com#tema-jekyll] Agregar un tema a tu sitio de Páginas de GitHub con Jekyll
🌐 [docs.github.com#config-fuente-publicacion] Configurar una fuente de publicación para tu sitio de Páginas de GitHub
🌐 [docs.github.com#docu-github-actions] Documentación de GitHub Actions
🌐 [jekyllrb.com#configuracion] Configuration. Sobre el archivo _config.yml

Recursos

🌐 Información general sobre productos, planes y precios de GitHub
🌐 [github.com#precios] Productos, planes y precios de GitHub
🌐 Fork de Linux de GitHub Desktop. Instalación de GitHub Desktop en un equipo Linux. Hay muchas distribuciones soportadas.
🌐 Getting started with GitHub Desktop. Tutorial de introducción a GitHub Desktop
🌐 Directorio de acciones predefinidas de GitHub
🌐 [pages.github.com#temas] Listado de temas soportados por GitHub Pages
🌐 [jekyllthemes.io]. jekyllthemes.io. Amplio catálogo de temas Jekyll, gratuitos y de pago
🌐 [docs.github.com#plugins] Plugins
🌐 [es.whatsmydns.me] Whats My DNS. Verificador de Propagación DNS