When starting this blog, I find it irresistable to walk through a great learning process I went through actually building this website. Back in the day, one would learn HTML, CSS, a good deal of JavaScript, and hand code their websites. There were great software programs to run that would build a lot of things in template forms for you, but it would be up to you to change it all yourself using an intimate knowledge of multiple languages.

Then a bunch of online website builders cameout including Wordpress, Blogger, and even Tripod before those two. Wix and SquareSpace are two popular iterations of those ideas. However, I am doing none of these things. So how am I doing it?

Jekyll. Jekyll is a static webpage generator. In plain words, it takes simple text files (in this case formatted with Markdown) and then uses that text to generate the necessary HTML code to display that on a webserver. There are template styles available that Jekyll will use to cause your text to confirm to the template. Again, you don’t actually have to learn a lot of coding. You can just get right to writing….. err. kinda.

So it turns out there’s a lot of other things to learn. Git, GitLab Pages, Jekyll, Ruby, and CloudFlare are technologies I have had to learn how to get to work together. I learned none of this sequentially, by the way. I learned everything as I went along.

Learning Git

This will not be a tutorial on Git, but rather things I learned about Git while building this blog.

Git repos operate in a distributed manner. On GitLab, there is a repo that serves as the production repo. On my local workstation, I use the git program to clone that production repo which copies all files in their directory structure. To make changes to files in the prod repo, you have to make chages to your local repo, commit the changes, and then push the changes up to prod.

This was a new experience for me as I had to learn about pushes, pulls, and aliases. First was to clone. Then to set an alias for the production repo. git remote add origin https://myusername.gitlab.com/project

This sets the URL for the repo as the remote repo. (Remote in this case is in relation to your local workstation, not GitLab) From there pushing to git is as simple as

git push origin master

This command pushes your committed changes to gitlab. Another possibility is to create a branch in Gitlab for testing and use master for production. Then I would just replace master in that command with the branch name.

Here’s a cheat sheet that really helped me understand git commands.

So that satisfies making changes and updating the repo, but who is the site’s code generated? I’m no HTML master and definitely not CSS.

This will take longer to write than I previously suspected. So I will end here and pickup with helpful things that helped me learn Jekyll.