The GitHub Workflow Explained in Plain English

Last night, I asked Gemini to explain Git and Github workflow in simple language. I am sharing the conversation here including my prompts and Gemini’s response.

This is for the non-techies like me, who are still somewhat scared of coding. But the good news is you can actually control and manage a workflow involving extensive coding without knowing much of it.

I am a communication professional for over two decades. Video production, print designs, even technical blogging on Avid, After Effects, 3ds Max are the territory I am always feel being home at.

Why I looked for a Git & GitHub Workflow explained in plain English?

Over the years, while I have been using WordPress since 2013 perhaps for my sites, blogs. But I increasingly felt that the page speed is not something WordPress can marvel at.

It was not not so evident back in the days when network speed was not super fast. But now we’re all using 5G and often talking about 6G.

For quite some time I have been looking for a solution other than WordPress that can help me build a static site.

Then I found quite some solutions for creating a static sites like this one. Before we proceed further, it’s important to understand what are the static sites.

What are the static sites?

It’s easy to understand. This one, which you’re now reading a page of, is a static site. In plain English, the sites that serves pages identically to every visitor is a static site. It doesn’t have a user account or log in feature and no user data storage.

Unlike dynamic websites (like WordPress, Facebook, or e-commerce stores), static sites do not require a database or real-time server-side processing to generate the page content when a visitor arrives.

So, every single visitor sees the exact same content until the source files are manually updated and republished. Then the next question comes if the user data are stored inside a dynamic site server and static sites do not, what would be their workflows?

Dynamic site workflow

Here is how it goes.

A user requests a page > The server runs language code (like PHP or Python) > The server queries a database (like MySQL) to fetch content > The server assembles everything into an HTML file on the fly > The HTML is sent to the user.

Static site workflow

A user requests a page > The server immediately hands over the pre-built HTML, CSS, and image files directly to the browser. No databases, no waiting for code to execute.

The Core Building Blocks

Static websites rely entirely on client-side languages (technologies that run directly inside the visitor’s web browser):

• HTML (HyperText Markup Language): Provides the raw structure and text content of the page.
• CSS (Cascading Style Sheets): Controls the visual design, layouts, colors, and fonts.
• JavaScript: Adds client-side interactivity. Note: Static sites can have JavaScript! It allows for things like drop-down menus, animations, dark-mode toggles, or even fetching external API data (like a search bar or a live weather widget) directly from the browser.

Now, why I just shared some information on these two types of sites! Because, like me, most professionals and small business owners deal with static sites an it’s important to know basic workflows.

Let’s get back on the track of our discussion on the GitHub workflow.

Here is the prompt I gave to Gemini last night, followed by its response.

Explain GitHub structure and functioning to me. 

Gemini

Think of GitHub as a massive, cloud-based filing cabinet and social network designed specifically for code. It is built on top of Git, an open-source version control system that tracks changes to files over time. While Git handles the tracking on your local computer, GitHub provides a centralized, collaborative space on the internet where teams can work together.

Here is a breakdown of how GitHub is structured and how it functions. This GitHub workflow explained in plain English is likely apt for the content creators like us.

1. The Core Structure of GitHub

GitHub’s architecture is hierarchical, moving from the macro level (organizations and users) down to the micro level (individual lines of code).

• Accounts (Users & Organizations): * User Accounts: Your personal profile where your projects live.
  • Organizations: Shared accounts for companies or open-source teams to manage multiple projects and team permissions.
• Repositories (“Repos”): The fundamental unit of GitHub. A repository is essentially a project folder. It contains all the project files, documentation, and—most importantly—the entire history of every change ever made to those files.
• Branches: Timelines of your project.
  • The main (or master) branch is the definitive, production-ready version of the code.
  • Feature branches are isolated copies of the main branch where developers can safely build new features or fix bugs without messing up the working project.
• Commits: Individual snapshots of your code at a specific point in time. Every time you save your progress and write a “commit message” (e.g., “Fixed login button bug”), Git takes a permanent picture of what the files look like.

Your Free PDF at the end of this Blog

2. How Git and GitHub Function: The Workflow

The typical GitHub workflow revolves around collaboration and keeping code stable. Here is how a team or an individual actually uses it:

[Main Branch] ───► [Create Feature Branch] ───► [Make Commits] ───► [Open Pull Request] ───► [Code Review & Merge] ───► [Back to Main]

Step 1: Cloning and Forking (Getting the Code)

• Clone: Downloading a copy of a GitHub repository onto your local computer so you can work on it using your own code editor.
• Fork: Creating a personal copy of someone else’s repository under your own GitHub account. This is heavily used in open-source projects so you can experiment without changing the original project.

Step 2: Branching and Committing (Making Changes)

Instead of editing the live project directly, you create a new branch. You write your code locally, save your progress via commits, and then push those changes from your computer up to GitHub.

Step 3: The Pull Request (PR)

This is GitHub’s crown jewel. A Pull Request is an official notice to the project managers that says: “Hey, I finished fixing that bug on my branch. Please review my code and pull it into the main project.”

Step 4: Code Review and Merging

Inside the PR, teammates can comment on specific lines of code, suggest edits, and run automated tests to ensure the new code doesn’t break the existing software. Once everything looks good, the branch is merged into the main branch, and the new code becomes part of the live project.

3. Beyond Code: Project Management Tools

GitHub isn’t just for storing code; it also includes a suite of tools to help teams manage their workflow:

• Issues: A built-in tracking system where users can report bugs, suggest new features, or ask questions.
• GitHub Actions (CI/CD): An automation tool. For example, you can set it up so that every time someone merges new code, GitHub automatically tests the code and deploys it to a website.
• Projects/Projects Boards: Kanban-style boards (similar to Trello) where you can drag and drop “Issues” or “Pull Requests” across columns like To Do, In Progress, and Done.

Actually, my goal has been to test a different pipeline for hosting a static site other than WordPress. And there I found quite a few solutions. One of them is to use GitHub pages for hosting your site for free.

Let’s see how to exploit GitHub Pages for this. Following a trail, this time I prompted Gemini the following.

Yes, please explain how to host a static site for free using GitHub Pages.

Gemini

Hosting a static site on GitHub Pages is incredibly popular because it’s 100% free, includes automated HTTPS security, and updates your website automatically every time you push new changes to your repository.

Here is a step-by-step guide to deploying your first static site.

Prerequisites: What You Need First

Before starting, ensure you have:

1. A free GitHub account.
2. A basic static website on your computer consisting of at least an index.html file (this must be named exactly index.html in lowercase, as it acts as your website’s homepage). You can also include standard CSS and JavaScript files.

The Step-by-Step Deployment Guide

Step 1: Create a New Repository

1. Log into GitHub and click the “+” icon in the top right corner, then select New repository.
2. Repository name: You have two options here:
   • Option A (Project Site): Name it anything you like (e.g., my-portfolio). Your website URL will look like username.github.io/my-portfolio.
   • Option B (User Site): Name it exactly yourusername.github.io (replace yourusername with your actual GitHub username). Your website URL will simply be https://yourusername.github.io.
3. Set the visibility to Public (GitHub Pages is only free for public repositories).
4. Check the box that says Add a README file.
5. Click Create repository.

Step 2: Upload Your Website Files

If you are comfortable using Git in your terminal, you can clone the repository, add your files, commit, and push. However, if you want the quickest route using the GitHub website:

1. Inside your new repository, click the Add file dropdown button and choose Upload files.
2. Drag and drop your website files (your index.html, style.css, image folders, etc.) into the box.
3. Scroll down, write a brief commit message (like “Initial website upload”), and click Commit changes.

Step 3: Enable GitHub Pages

1. Go to the Settings tab located at the top menu bar of your repository.
2. On the left-hand sidebar, scroll down to the “Code and automation” section and click on Pages.
3. Under the Build and deployment section, look for Source. Ensure it is set to Deploy from a branch.
4. Under Branch, change it from None to main (or master, depending on your default branch name). Leave the folder dropdown set to / (root).
5. Click the Save button.

Finding Your Live Website

Once you click save, GitHub Actions starts building your site in the background.

1. Wait about 1 to 2 minutes.
2. Refresh the Pages settings screen.
3. At the top of the page, you will see a success message saying: “Your site is live at…” followed by a clickable URL.

Every single time you edit your HTML/CSS files and push those updates to GitHub, GitHub Pages will automatically rebuild and update your live website within seconds.

Pro-Tips for GitHub Pages

• Custom Domains: If you don’t want the .github.io extension, you can buy a custom domain name (like myname.com) from a registrar and link it directly in the GitHub Pages settings menu for free.
• Case Sensitivity: Unlike local computers, GitHub Pages servers are strictly case-sensitive. If an image file is named Photo.JPG but your HTML code says <img src="photo.jpg">, the image will break on the live site. Always double-check your file naming conventions!

Conclusion

As a content creator, we’re kind of resistant to adopting such coding environments and postpone our update with changing technologies.

Thing is, these days, you can control a workflow involving java script without knowing how to code in Java script.

Having different solutions to navigate different situations is always better. Git and Github, GitHub pages – these are just some tools that we can with a little effort can manage the pipeline.

The purpose of this piece is to create a documentation on the GitHub workflow explained in plain English, so that content creators like me can take up such process.

Keep a close watch to this blog as it will get updated with me navigating through different testing environment.

Download Your Free PDF