Day 7 of My DevOps Journey: Getting Started with Git & GitHub

Day 7 - moved on from shell scripting and started Git and GitHub. This is where version control comes in, and it's one of the most fundamental skills in the DevOps roadmap since almost every workflow (CI/CD, collaboration, deployments) builds on top of it.

Git vs GitHub - clearing up the confusion

These two names get used interchangeably a lot, but they're different things:

Git is a global information tracker - a tool that runs locally on your machine and tracks changes to your files/code over time. It has nothing to do with the internet by itself.
GitHub is a web-based platform that hosts Git repositories in the cloud. It adds collaboration features (pull requests, issues, forks) on top of what Git already does locally.

So, Git is the tool, GitHub is one place (among several - GitLab, Bitbucket also exist) where you can host and share what Git tracks.

The three areas a file moves through

Understanding Git really comes down to understanding this flow:

Untracked → Staged → Tracked

A new file starts out untracked - Git knows it exists but isn't watching it.
Once added, it moves to the staged area - marked as ready to be included in the next commit.
Once committed, it becomes tracked - part of Git's permanent history.

Core commands, in order

git init Initializes a new, empty Git repository in the current folder. Any new file created here starts off in the untracked area.

git add file_name Moves a file from untracked to the staging area. You can also do git add . to stage everything at once.

git rm --cached file_name The reverse of add - moves a file back from staged to untracked, without deleting the file itself from your disk.

git commit -m "message" Takes everything in the staging area and moves it into the tracked area - this is what actually saves a snapshot into Git's history, along with a message describing the change.

git restore file_name Restores a file - useful for undoing local changes or recovering a deleted file back to its last committed state.

Branching

A branch is essentially a separate workspace, or more precisely, a pointer to a specific sequence of commits. Branches let you work on new features or experiments without touching the main line of code until you're ready to merge it back in.

git branch - lists all branches in the current repository.
git checkout -b name - creates a new branch and switches to it in one step.
git checkout name or git switch name - switches to an already-existing branch.
git merge name - merges the commits from the specified branch into whatever branch you're currently on.

Working with a remote (GitHub)

git remote add origin url - connects your local repository to a remote one (typically on GitHub), and names that connection "origin."
git remote -v - shows the URL(s) currently configured for your remote(s).
git remote set-url origin https://token@github.com/url - updates the remote URL to authenticate using a GitHub personal access token instead of a password (GitHub no longer accepts plain passwords for this).
git push origin main - pushes your local commits on the main branch up to the remote.
git pull origin main - pulls the latest changes from the remote's main branch down into your local repository.
git clone url - downloads a complete copy of a remote repository, including its full history, onto your local machine.

Other essentials

git diff - shows exactly what's changed (line by line) between your working files and the last commit, or between any two commits/branches.
.gitignore - a special file where you list file/folder patterns you want Git to ignore entirely (like build artifacts, .env files, or node_modules) so they never get tracked or committed by accident.
Fork - a GitHub-specific concept: it creates your own personal copy of someone else's repository under your account, so you can make changes independently and later propose them back via a pull request.