Week 1: Project Management

Planted January 23, 2026

This week I set up my development environment and created my documentation website for Fab Academy using Hugo and GitLab Pages. I configured Git with SSH key authentication, initialized a Hugo site with the Digital Garden theme as a git submodule, managed theme switching through submodule workflows, and deployed using the existing GitLab CI/CD pipeline. I also evaluated static site generators and compared Hugo theme options.

Notes

Here are my notes from classes and recitations related to this week

class of week 1 and introduction

rectiation of week 1

Learning Git Fundamentals

Before diving into the project setup, I spent time working through Git tutorials to understand version control properly. I used the official Git documentation directly, which was incredibly comprehensive and well-structured.

Working through these sections gave me a solid foundation in Git. The official documentation was clear and included practical examples that helped me understand not just what each command does, but when and why to use them. This knowledge proved essential when setting up my project repository and working with the Hugo theme as a submodule.

My Git Aliases

During the class this week Neil mentioned Git Aliases as a way to simplify terminal comments thus I decided to experiment with creating some to helpmake my life easier. Below are the aliases I added for commands generally used by me in my workflow.

System Specifications

I’m working on a ThinkPad running Ubuntu 22.04 LTS. Here’s what I have set up:

• Device: ThinkPad
• OS: Ubuntu 22.04 LTS
• Git Version: 2.40.0
• Hugo Version: 0.152.2 (extended)

Initial Setup

Installing Git on my machine

First, I needed to make sure Git was installed on my system. I opened a terminal and ran:

sudo apt update
sudo apt install git

To verify the installation worked:

git --version

The output showed: git version 2.40.0 - perfect!

Configuring Git

Next, I set up my global Git configuration with my name and email:

git config --global user.name "emre-dayangac"
git config --global user.email "your.email@example.com"
git config --global core.editor "nvim"  # I prefer nvim as my editor

I checked my configuration with:

git config --list

Understanding SSH

SSH (Secure Shell) is a cryptographic network protocol for secure communication. It uses public-key cryptography with two keys: a public key and a private key. The public key is placed on the server (GitLab) and the private key is kept locally. When connecting, the server verifies that your private key matches the public key without ever transmitting the private key itself. This eliminates the need to send passwords over the network.

The key pair works through asymmetric encryption: data encrypted with the public key can only be decrypted by the private key, and vice versa. This allows the server to verify your identity without storing or transmitting passwords. SSH keys are also safer than passwords because they use 2048-bit (or longer) encryption, making them resistant to brute-force attacks.

SSH Key Setup

Setting up SSH keys was important so I wouldn’t have to enter my password every time I push to GitLab. This was new to me, but it turned out to be straightforward.

Generate SSH Key:

ssh-keygen -t rsa -C "your.email@example.com" -f ~/.ssh/id_rsa_gitlab

When prompted, I pressed Enter to use the default location and added a passphrase for security (highly recommended!).

Copy Public Key:

cat ~/.ssh/id_rsa_gitlab.pub

I selected and copied the entire output (it starts with ssh-rsa).

Adding Key to GitLab:

1. Went to gitlab.com and logged in
2. Clicked my profile picture → Settings
3. Selected SSH Keys from the left menu
4. Pasted my public key and clicked Add key place to add your ssh key on gitlab

Register SSH Key Locally:

ssh-add ~/.ssh/id_rsa_gitlab

Test SSH Connection:

ssh -T git@gitlab.com

I got the expected output confirming the SSH connection was successful!

Project Repository Setup

I created a project directory and cloned my repository:

mkdir -p ~/CS/emre-dayangac
cd ~/CS/emre-dayangac
git clone git@gitlab.fabcloud.org:academany/fabacademy/2026/labs/hisar/students/emre-dayangac.git
cd emre-dayangac

My Research

There are a lot of great options to create a site, hence I decided to explore those different way of displaying my documentation on the web to find the one which would be the easiest to use and suit me the most. Below are my findings:

• Hugo (Static Site Generator) Offers a high level of customization through themes and templates while still keeping content writing simple. scales well for larger and more structured documentation websites.

• Markdown + MkDocs Allows quick and clean writing, and MkDocs automatically converts it into a static website. While very efficient for weekly documentation, theming and layout customization are limited.

• Bootstrap CSS and JavaScript framework that enables responsive web design using prebuilt components. Offers more visual control than static site generators but more direct work with HTML, CSS, and JavaScript needed.

• Pure HTML Provides full control over structure and features though maintaining a large documentation website this way can be time-consuming, especially when dynamic content is required.

After comparing these options, I chose Hugo over MkDocs because it provides the same efficient Markdown-based documentation workflow while offering greater flexibility in layout, theming, and site structure as the project grows.

Hello Hugo

Now it was time to install the site since I had the gitlab repo locally. Since I was familiar with web development due to previous experiences I decided to go for an approach which would allow me to directly create pages using markdown (md). After some research I settled on Hugo as it look liked the one which would provide me with the most frictionless experience, as mentioned in my research section above.Thus it was time to install Hugo. On Ubuntu, an easu method of installation is using Snap:

sudo apt install snapd
sudo snap install hugo --channel=extended

To verify:

hugo version

This showed: hugo v0.152.2-6abdacad3f3fe944ea42177844469139e81feda6+extended - great!

I also installed some build tools that might be needed:

sudo apt install -y git nodejs npm

This was what I had at hand Now it was time to make the site look a bit better and easier to read through Hugo.

Setting Up My Hugo Site

Selecting themes

After setting up Hugo it was now time to choose the theme for the website! Using the Hugo themes page I started searching for an appropriate theme.

I initially started with the Blowfish theme for Hugo, but after working with it for a bit, I decided I didn’t like how it looked and wanted to try something different. The main reason I decided to migrate away from blowfish was because it initially showed many bugs on my system so I had to dive into the theme’s documentation to resolve those issues which were present at startup thus deciding it wasn’t worth the trouble since it didn’t have any stylistic or functionality aspects which particulary stood out, to sum it up it was bloated and a bit broken for me. Alongside the site having unnecessary pre-installed features in the context of this course, such as a button to switch between languages. This is where Git submodules really showed their value!

From Blowfish to Digital Garden

Since I had added the Blowfish theme as a git submodule, switching to a different theme was straightforward. I simply removed the Blowfish submodule and added the Digital Garden theme as a new submodule:

# Remove the Blowfish theme submodule
git submodule deinit -f themes/blowfish
git rm -f themes/blowfish
rm -rf .git/modules/themes/blowfish

# Add the Digital Garden theme as a new submodule
git submodule add https://github.com/apvarun/digital-garden-hugo-theme.git themes/digitalgarden

Then I updated my hugo.toml to use the new theme name. The beauty of using submodules is that I didn’t have to manually copy theme files or worry about mixing theme code with my own - everything stayed clean and organized. If I want to switch themes again in the future, I can do it just as easily.

I chose the Digital Garden theme because I liked its clean, modern design and the way it organizes content. Here’s how I set it up:

Create My Hugo Site

cd ~/CS/emre-dayangac
hugo new site . --force

The --force flag was needed because I already had some files in the directory.

Add Digital Garden Theme as Submodule

I added the theme as a git submodule, which makes it easier to update later:

git submodule add https://github.com/apvarun/digital-garden-hugo-theme.git themes/digitalgarden

Configuring Hugo

I edited hugo.toml with my site configuration:

baseURL = 'https://fabacademy.org/2026/labs/hisar/students/emre-dayangac/'
languageCode = 'en-us'
title = 'Personal Digital Garden'
theme = 'digitalgarden'

[Params]
  description = "My Digital Garden on the Internet"
  enableSearch = true

[menu]
[[menu.main]]
  name = 'Home'
  url = '/'
  weight = 1
[[menu.main]]
  name = 'Assignments'
  url = '/assignments'
  weight = 2

I set the baseURL to match my Fab Academy site URL. For local development, I can temporarily change this to '/' when running hugo server.

Create Content Structure

I created the basic content directories:

mkdir -p content/assignments data

Then I created a homepage and section index pages to get started.

Run Locally

To see my site locally:

hugo server

I opened my browser to http://localhost:1313 and could see my site! The theme looked great right out of the box

below is what I had at hand now it’s time to move onto documenting week-1 .

Creating My Week 1 Page

I created my first assignment page using Hugo’s content generator:

hugo new assignments/week-1-project-management.md

This created a new file in content/assignments/ with front matter already set up. I edited it to add my content and set draft = false so it would be published.

Creating a Cheatsheets Section

After setting up my assignments section, I realized I wanted a separate area to keep quick reference guides and command cheatsheets - stuff I’d need to look up frequently while working on my projects. So I decided to create a dedicated cheatsheets section on my site.

Setting Up the Content Structure

First, I created the directory structure for cheatsheets, similar to how assignments was organized:

mkdir -p content/cheatsheets/bw-terminal-cheatsheet

Then I created an index page for the cheatsheets section at content/cheatsheets/_index.md:

---
title: Cheatsheets
---

# Cheatsheets

Welcome to my cheatsheets section. Here you'll find quick reference guides and command collections.

And my first cheatsheet post at content/cheatsheets/terminal-cheatsheet/index.md with all the terminal commands I was using constantly for Git, Hugo, and basic navigation.

Understanding Hugo Layouts

Here’s where things got interesting. When I tried to view the cheatsheets page locally, it showed up blank - just an empty page! I was confused at first because the content files were definitely there.

After some digging, I learned that Hugo uses a template hierarchy. The Digital Garden theme has default layouts, but some sections need custom layouts to display properly. I noticed that my assignments section had custom layout files in layouts/assignments/, which is why it worked perfectly.

Creating the Custom Layouts

I needed to create matching layout files for my cheatsheets section. Hugo uses two main layout types for content sections:

1. list.html - Displays the section index page with a list of all posts
2. single.html - Displays individual posts within that section

I created these files in layouts/cheatsheets/:

mkdir -p layouts/cheatsheets

For layouts/cheatsheets/list.html, I copied the structure from the assignments layout. This template shows:

• A sidebar with all cheatsheet posts
• A search bar for filtering
• The main content area that displays “Select a post to read” when nothing is selected

For layouts/cheatsheets/single.html, I again followed the assignments pattern. This displays:

• The post title and date metadata
• The full content with proper markdown rendering
• Responsive styling that matches the rest of the site

The cool thing about this approach is that both sections (assignments and cheatsheets) now have consistent styling and behavior, but they’re completely separate content types in my site structure.

Adding to Navigation

Finally, I updated hugo.toml to add the cheatsheets link to my main navigation menu:

[[menu.main]]
  name = 'Cheatsheets'
  url = '/cheatsheets'
  weight = 3

The weight parameter controls the order - I put it at weight 3 so it appears between Assignments (2) and About Me (4) in the navigation bar.

After saving these changes and refreshing my browser, the cheatsheets section worked perfectly! I could now keep all my quick reference guides organized in one place, separate from my weekly assignments.

Deploying to GitLab Pages

Updating my .gitlab-ci.yml for Hugo

I adjusted my .gitlab-ci.yml file so that I could properly deploy a Hugo site:

image: registry.gitlab.com/pages/hugo:latest

variables:
  GIT_SUBMODULE_STRATEGY: recursive

pages:
  stage: deploy
  script:
    - hugo --minify
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

This tells GitLab CI to:

• Use the Hugo Docker image
• Handle git submodules (for the theme)
• Build the site with minification
• Deploy the public directory to Pages

Push to GitLab

I committed and pushed my changes:

git add .
git commit -m "Initial Hugo Digital Garden setup with Week 1 documentation"
git push -u origin main

I checked my GitLab project’s CI/CD → Pipelines page to monitor the build. Once the pipeline succeeded, my site was live!

Compression Made Easy

During this week, Neil talked about the importance of compression in optimizing file sizes and improving workflow efficiency. This sparked an idea: what if we could make compression part of the natural development workflow instead of an afterthought?

I started thinking about the typical documentation update cycle and realized there were friction points. When you take screenshots, record videos, or add media to your documentation, they often take up unnecessary space. You have to remember to compress them, optimize them, and then deploy. It’s easy to forget a step or end up with bloated files in your repository.

The ideation process led me to create term-clip, a neovim plugin that integrates compression directly into your editor workflow. Instead of treating compression as a separate step, it becomes part of your natural editing experience.

The workflow follows a simple three-step process:

1. Capture Media → 2. Drag and drop or paste into neo vim → 3. add proper compressed images path with appropriate syntax in md

A simple video displaying how the plugin works

You can view the full source code and documentation in the term-clip.nvim repository.

What I Learned

1. Git and Version Control: Git tracks project history through commits and manages branches for parallel development. SSH key authentication uses public-key cryptography to verify identity without transmitting passwords, eliminating the need for password entry during each push operation. Git submodules track external repositories as dependencies without including them in the main repository - I used git submodule deinit and git submodule add to switch themes (Blowfish to Digital Garden) while keeping the main repository clean. The git config command sets global user information and editor preferences that apply across all repositories. Understanding branch workflows, commit messages, and the staging area (git add) is essential for managing code changes and repository history.

2. Hugo Static Site Generator: Hugo compiles markdown source files and templates into static HTML at build time rather than serving dynamic content. The site structure uses content/ for markdown files with YAML front matter metadata, themes/ for template files and styling, and static/ for assets served unchanged. Hugo’s build process generates a complete website with CSS, JavaScript, and HTML assets in the public/ directory ready for deployment. The hugo server command provides local development with hot-reload, allowing real-time preview of changes without rebuilding. Theme configuration in hugo.toml controls site metadata, menu structure, and theme-specific parameters that affect the entire site appearance.

3. Markdown: Markdown uses plain text syntax with simple characters to format content - asterisks for emphasis, hash symbols for headers, dashes for lists - that remains readable as source. Markdown processors convert this plain text into HTML for web display, making the same source usable across different platforms and tools. Extended markdown dialects add table syntax with pipe characters, fenced code blocks with triple backticks, and blockquote syntax for structured content beyond basic formatting. I created a Gantt chart using markdown table syntax with plain characters to represent timeline visualization without requiring external tools or plugins. Markdown’s simplicity and portability make it ideal for documentation since the source files are version-controllable, human-readable, and can be processed by any markdown parser.

Challenges I Faced

1. BaseURL Configuration: Initially, I had baseURL = 'https://example.org/' which caused CSS and JavaScript not to load properly. I learned that the baseURL needs to match the actual deployment URL. For local development, I can temporarily change it to '/' when running hugo server, but for production builds, it must be set to the full site URL.

2. Theme Setup: Understanding how Hugo themes work and how to configure them took some time. I had to read the theme’s documentation and example configuration.

3. Git Submodules: This was my first time working with git submodules. I learned they’re useful for including external themes while keeping them separate from my main repository.

Terminal Cheatsheet

I decided to create a cheatsheet for this week to remember the core commans I learned.

Resources

• Hugo Documentation
• Digital Garden Theme
• GitLab Pages Documentation
• Git Documentation

Overall, this was a productive week! I now have a working documentation website that I can update throughout the Fab Academy program. The setup process taught me a lot about modern web development workflows and version control.