I want to tell you about the 45 minutes I spent trying to push one file to GitHub from a Linux terminal.
Not because it went smoothly. Because it absolutely did not — and if you are learning Linux and Git at the same time, this post will save you from every mistake I made in sequence.
The Setup
I am building a Linux administration portfolio as part of my cloud engineering journey. I had already created a repo on GitHub using the browser. Now I wanted to push files directly from my Rocky Linux VM like an actual engineer — not drag-and-drop in a browser.
Simple enough, right?
Step 1: Does Git Even Exist On This Machine?
Before doing anything I needed to confirm Git was installed. I tried four different ways:
which git
dnf list installed | grep git
rpm -qa | grep git
rpm -q git
git --version
The cleanest answer came from rpm -q git — returned the package name and version instantly. Then git --version confirmed it was ready to use.
Lesson: git --version is always the fastest confirmation. The rpm commands are useful when you suspect something is broken at the package level and need to dig deeper.
Step 2: Running git init In The Wrong Place
First move was running git init without thinking about where I actually was in the filesystem. This initialises a Git repository right where you run it — creating a hidden .git folder in that directory.
I ran git add . and git status immediately after and got confused about why the files showing up were not my project files. A quick ls told me I had initialised in completely the wrong directory.
Always confirm your location with pwd before running git init. One second check saves five minutes of confusion.
Step 3: Renaming a Directory With mv
I had a folder with a messy name I wanted to clean up before doing anything else:
mv pratice-nov-26/ linux_admin
mv in Linux does double duty — it moves files and renames them. Passing a new name instead of a destination path renames in place. Useful to know since there is no dedicated rename command in Linux.
Step 4: Cloning Instead of Linking
Rather than trying to link my local folder to the remote repo manually, I cloned directly:
cd linux_admin/
git clone https://github.com/username/repo-name.git
cd repo-name/
ls -l
cat README.md
Cloning pulls everything GitHub already has and automatically sets up the connection between local and remote. For a repo that already exists on GitHub, this is the cleanest starting point — no manual remote linking needed.
Seeing the README I had written in the browser appear in my terminal was a good moment. Browser work and terminal work meeting for the first time.
Step 5: Staging a File
Created a test file and staged it:
touch 03_linux
git add 03_linux
git status
git status showed the file in green under Changes to be committed. This is your checkpoint before committing — always run it here so you know exactly what is about to go into the commit history.
Step 6: The Commit That Would Not Commit
git commit
Git opened a text editor and waited for a commit message. I did not know what I was looking at, closed it, and the commit was aborted. Git requires a message — it will not commit without one.
I had also not configured my Git identity yet:
git config --global user.email "youremail@example.com"
git config --global user.name "Your Name"
This is a one-time setup per machine. Git needs to know who is making commits so the history is attributed correctly. The --global flag writes to a config file that applies to every repo on that machine.
I also made this mistake:
Omit --global
omit
Omit
All three: command not found. I had misread something in the error output and tried to type it as a command. The terminal is literal — it only runs what it knows.
The commit that finally worked:
git commit -m "test"
The -m flag lets you write the message inline without opening an editor. In real projects keep messages descriptive — “Add Module 3 filesystem lab files” tells the story, “test” does not.
Step 7: The Push That Needed a Token
git push origin main
Rejected. GitHub stopped accepting passwords for command-line operations in 2021. You need a Personal Access Token instead. Generate one in GitHub Settings under Developer Settings, give it repo scope, then use it in place of a password when prompted — or set it directly in the remote URL:
git remote set-url origin https://TOKEN@github.com/username/repo-name.git
git push origin main
That worked. File on GitHub.
The Clean Workflow
Once you understand what each step does, pushing from a Linux terminal looks like this:
# One-time machine setup
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
# Clone existing GitHub repo
git clone https://github.com/username/repo-name.git
cd repo-name/
# Stage, commit, push
git add filename
git status
git commit -m "Describe what you changed"
git push origin main
Everything else in my command history was me figuring out what those lines actually mean by running them and seeing what happened.
What I Took Away
Git does not hold your hand. It opens unexpected editors, rejects pushes without tokens, and happily lets you initialise a repo in the wrong directory. None of that is failure — it is the actual learning. Every error in that history is a concept that now sticks because I hit it on a real machine.
Run the commands. Read the errors. Fix them. That is the workflow.
This is part of an ongoing series documenting hands-on Linux and cloud engineering practice.
