You can check the source code of the editing content post to see how I moved from the standard syntax for images using ![alt text](image path) to use HTML to allow to set up a custom width using a CSS style.

<div style="text-align:right; margin: 20px 0">
  <p>
    Another example could be to 
    <span style="color:red">change text color</span>.
  </p>
</div>

Easy right? 😀

A different approach is to use a Jekyll feature called Liquid tags. From the documentation:

Jekyll uses the Liquid templating language to process templates.

Generally in Liquid you output content using two curly braces e.g. {{ variable }} and perform logic statements by surrounding them in a curly brace percentage sign e.g. {% if statement %}. To learn more about Liquid, check out the official Liquid Documentation.

There is a Liquid tag to link to files, getting as a result the corresponding url for the resource. So for our archive we would use:

[archive]({{ site.base_url }}{% link _pages/archive.md %})

and this would be automatically converted into

[archive](/gh-pages-minima-starter/archive)

For a blog post this:

[first post]({{ site.base_url }}{% link _posts/2020-03-18-my-first-post.md %})

transforms into:

[first post](/gh-pages-minima-starter/2020/03/18/my-first-post.html)

Apart from the benefit of being resilient to changes in the permalinks of your articles, this also has a very important effect: Jekyll will fail to process your site if you use a wrong link. This means that Jekyll checks your internal links on every built, and if for any reason you change the name of your file in the future, Jekyll will error with details on where the offending link lives.

An important final note is that if you paid attention, the links are relative to the root of your domain. If you deploy this site in your personal GitHub space that’s OK but if you publish it in a project so your URL is like https://yourusername.github.io/project then the URLs will fail. You’d need to put {{ site.base_url }} before the link tag, for absolute URLs that point to the correct resource.

More details on this nice article.

Just install Docker and Docker Compose, visit the repo folder and run docker compose build. Then, every time you wan to spin up the local environment just run docker compose up and visit http://localhost:8080/gh-pages-minima-starter.

Alternatively, if you prefer to install all the software locally please follow the docs.

The compose file is super simple, it just refers to a local Dockerfile image definition setting up the current folder as the container /srv/jekyll directory and starts the server with convenient options like livereload.

version: '3'

services:
  jekyll:
    build:
      context: .
    command: jekyll serve --watch --force_polling --incremental --port 8080 -H 0.0.0.0 --livereload --livereload-port 35729 --baseurl /gh-pages-minima-starter
    volumes:
      - .:/srv/jekyll
    ports:
      - '8080:8080'
      - '35729:35729'
    environment: 
      RUBYOPT: '-W0'
      JEKYLL_ENV: production 

If you are using Github interface, you can use the top right buttons to create new files or upload them.

Find more details on how to write Jekyll posts on the docs.

If your site grows you may want to set up a local environment to make things easier to you. We cover that in the local environment post.

First thing to know is that Github Pages by default accepts rendering content in HTML and Markdown. I strongly recommend using Markdown because it’s very simple and out of your way when you write, since the formatting rules are very simple. If you are going to write a long piece, you may want to use an external editor and then upload or paste your content into github. There are many text editors that support Markdown but if I have to suggest one that works well for writing I’d go for typora because it’s supporting Linux, Windows, and also MacOS (in beta).

Typora

After creating the project, the first thing I would do is to change the project name at the Settings tab. The name of the project will became part of the website main address. So if for example you name your repo as myblog, your website will be available at https://yourusername.github.io/myblog. There is a special case, if you name your repo as yourusername.github.io then the website will be published at https://yourusername.github.io which may be a good idea for a personal website!

Next thing to do is to customize the main settings on the _config.yml file: website title, description, base URL (remove this setting it if you are deploying to your GitHub user website), and your details. If you don’t want to show excerpts of your posts in the front page you can disable that checking removing that entry on adding a # at the beginning of that line. You don’t need to change anything else.

After the configuration is ready you can enable the website publishing on the same Settings page a bit further down. Remember to set up the master branch as the source of your documents. Once you save your settings wait for a few minutes and your site is ready!!

Any time you change anything in your repository you do an operation called pushing a commit. On every push the website is rebuilt. You can see the details of that process in the Environment section that is accessible from the repository front-page.

• unnumbered
• fancy
• lists

But also

1. numbered
2. ones
3. easily

Images

And so on…