What this covers

You have a domain and a brand, but nothing on your computer. This step sets up the local folder, initializes Git, creates SSH keys, and verifies the connection to GitHub.

What I did

I had built sites before, but the setup phase was always a blur of copied commands. This time I wanted to understand each step, because mantus.ai was going to document the process and I could not document something I did not understand.

The first command was mkdir footybeat. That creates a new folder. I named it the same as the domain on purpose, because having your folder, your repo, and your domain all share the same name eliminates an entire category of confusion later. Then cd footybeat to move into the folder. Then git init, which turns a normal folder into a Git repository. Git is version control. It tracks every change you make to every file, so you can go back to any previous version if something breaks.

Three commands. One folder that Git is now watching. No code yet.

The next part was SSH keys, and this is where things went wrong. SSH is a way for your computer to prove its identity to GitHub without typing a password every time. You generate a key pair, one private key that stays on your machine and one public key that you upload to GitHub. I had done this before for another project, so I ran ssh-keygen, added the public key to my GitHub account, and tried to connect.

Permission denied (publickey).

I stared at the terminal for ten minutes. The key existed. It was on GitHub. Everything looked right. The problem was that the key was not loaded into my SSH agent. The agent is the background process that actually presents the key when GitHub asks for it. Generating the key is not enough. You have to tell your computer to use it.

Two commands fixed it. eval "$(ssh-agent -s)" to start the agent, and ssh-add ~/.ssh/id_ed25519 to load the key. Then ssh -T git@github.com returned a welcome message. Connection verified.

I had a local folder with Git initialized and a working SSH connection to GitHub. No code, no files, no README. Just the workspace, properly wired.

Skip the mistakes

Set up SSH keys properly once and you will never think about them again. The fifteen minutes it takes to generate a key, add it to GitHub, and verify the connection saves hours of authentication headaches later. Do not skip this step because HTTPS cloning seems easier. SSH is the correct setup for pushing code regularly.

Test the connection before you try to push anything. Run ssh -T git@github.com and wait for the welcome message. If you get "permission denied," the key is either not generated, not added to GitHub, or not loaded into your SSH agent. Those are the only three possibilities, and you can check them in that order.

Name the folder the same as the domain. It sounds trivial, but when you have three projects open and one folder is called my-site and another is called project-v2, you will lose time navigating. footybeat the folder, footybeat the repo, footybeat.com the domain. Same name everywhere.

Do not skip git init. It is one command and it is easy to forget when you are eager to start writing code. Without it, nothing is tracked, and your first attempt to commit will fail with an error message that does not clearly explain what went wrong. Initialize Git in the empty folder before you add a single file.

What's next

The workspace is wired up and GitHub can hear me, but nobody else can see anything yet.