Note: This post is sponsored by Scrimba. Scrimba offers interactive coding courses that let you learn by writing and editing code directly in the browser. Get 20% off Scrimba Pro (Click Here)
If you watched my CI/CD foundational video, you know i was adamant about one thing, and that is I want everything in this environment versioned from the ground up, especially configurations. If configs are not tracked early, you hit that point where you are changing things fast, testing things fast, and then one day you realize you do not remember what you changed, why you changed it, or how to roll it back. That is not a fun place to be.
Originally, I had planned for the next video to be about the container platform I want to use in this phase. I’m still debating between a couple options for the infrastructure side, but that is for another video. The more I thought about it, the more I realized the repo needs to come first.
If the repo is not up and running early then configs will start living everywhere, and everything that comes after becomes harder and messy in the worst way. So in this blog, I’m bringing the repo for this environment online. Not the central repo yet. Not the “golden repo” yet. Just the foundation. Git first.
To understand what a repo is and how it fits into the build, I break this topic into a few parts.
- First, we need to understand what a distributed version control system is, and what Git is.
- Second, we need to understand what GitLab is and the role it will play later as a central place for our configs and automation.
- Then once both make sense, we connect everything and validate that the workflow fits the environment.
This article covers the Git part and the local workflow, because I want to understand Git before we talk about any other platform.
Quick Note On Learning Resources
Before we go further, I want to start doing something a little different in this series. When I’m learning something new, I like having a few solid reference points I can come back to. These are the resources that helped me dive deeper.
- The Pro Git book. If you want to understand how Git works under the hood, not just commands, this is a solid reference. It can be a dry read, but it is worth it when you want clarity (Click to Buy).
- Another one is Automating DevOps with GitLab CI/CD Pipelines. That one helped me understand GitLab, and more importantly how GitLab fits into CI/CD and the broader DevOps workflow. You do not need these books to use Git or GitLab, but they helped me connect the dots faster (Click to Buy).
- Another great resource is the Scrimba Git & GitHub course. This one is much more hands-on and interactive, which made it easier to actually practice Git and GitHub instead of just reading about them. It’s especially helpful if you learn by doing and want to build confidence with real workflows (Click to Watch).
What is a Distributed Version Control System, And Where Does Git Fit?
A distributed version control system, DVCS, is a system where every developer has a full copy of the project, including the full history, on their own machine. Think of it like this. Instead of everyone working inside one shared Google Doc, everyone has their own full copy of the book with all past edits. You can work locally without asking permission, and when you are ready, you sync your changes back with everyone else. That is what makes it distributed.
Git is the most widely used DVCS. It lets you track changes, work locally, and collaborate safely when you are ready to sync. In simple terms, DVCS is the concept. Git is the tool we use to implement it. And in a build like this, Git is what gives you traceability and control before you automate things and start making changes to configs.
The Core Git Concepts We Need To Understand
Git is deep. You can spend a long time learning every feature. You do not need all of that to start building. For this series, these are the foundations that matter.
- Git stores your project as a series of snapshots over time. Each commit is a recorded snapshot you can reference later.
- There is the working directory, the staging area, and the repository. Your working directory is where you edit files. The staging area is where you select what goes into the next commit. The repository is the history of commits. If you understand that flow, Git stops feeling random.
- A commit is a saved snapshot that links to the commits before it. That chain of commits is your history.
- A branch is a separate line of development that lets you work on changes without affecting the main version of your project. Each commit you make belongs to the branch you are working on. The main branch is the primary reference point that represents the stable or agreed-upon state of the project.
One of the reasons Git feels fast is because most of the work happens locally. You can create commits, create branches, and manage history on your machine. Later, when you use a central platform, you can synchronize those changes. That is the foundation.
Git behaves the same across Windows and Linux once it is installed, but Windows usually requires an installation step first. Linux often has Git available already, depending on the distro.
Command Reference Guide
This section is the practical command reference you can copy and use when you are ready. It stays general on purpose, so you can apply it to your own environment.
Verify Git is installed
- git --version
Set your Git identity
- git config --global user.name "Your Name"
- git config --global user.email "you@example.com"
Verify
- git config --global --list
Create a repo and initialize it
- mkdir git-local-demo
- cd git-local-demo
- git init
Check status
- git status
Create files
- nano README.md
Stage changes
- git add README.md
Commit changes
- git commit -m "Your commit message"
View commit history
- git log
List branches
- git branch
Rename branch
- git branch -M main
Create branch
- git checkout -b demo
Switch branches
- git checkout main
Show files in branch
- git ls-tree -r main
Merge branch
- First, make sure you are on the branch you want to merge into
- git merge demo
Delete a branch
- git branch -d demo
At this point we now have the local Git foundation. We know what a repo is, how staging and commits work, how branches keep work isolated, how merging brings changes back into main, and what a merge conflict looks like when two changes collide.
Now GitLab will make sense because GitLab is not the thing that makes version control happen. Git already does that locally. GitLab becomes the central place where the repo lives, where collaboration happens, and where CI/CD starts to take over the repetitive work That is what we will build next. Stay curious. Stay geeking. I’ll see you in the next one. Peace.
