Today, we build the most important foundation of your professional career.
We've all been here:
This is chaos. This is unprofessional. Today, we end this chaos forever.
Before we can begin, we must acquire and configure our primary tool: Git. This is a one-time setup for your machine. We will also introduce ourselves to Git so it knows who is writing the history.
Linux makes this incredibly simple using its built-in package manager, apt
apt (Advanced Package Tool) is Ubuntu's built-in package manager. sudo stands for "Super User Do," which temporarily gives you administrative privileges to install software.
First, update the package list. This command downloads the latest catalog of available software, ensuring you get a recent version of Git.
sudo apt update
Now, install Git. This command finds the "git" package in the catalog and installs it.
sudo apt install git
This step confirms the installation and sets up your identity. It is mandatory.
Verify: Close ALL open terminal windows and open a brand new one. This ensures your system's PATH has been updated. Type this command and press Enter:
git --version
You must see a version number (e.g., git version 2.41.0). If you do, it worked. Else, something went wrong with the installation.
Configure: We must tell Git who we are. This information is baked into every commit (snapshot) you create. It's how you get credit for your work.
# Use your actual name, in quotes
git config --global user.name "Your Name"
# Use the email you signed up to GitHub with, in quotes
git config --global user.email "you@example.com"
What is --global? This flag tells Git to write this configuration to a special file in your user's home directory (e.g., ~/.gitconfig). This setting will apply to every single Git project on your computer. You only need to do this once.
report_final.doc
report_final_v2_USE_THIS_ONE.doc
report_final_v3_Emeka_edits.doc
This is a system based on hope and file names. It is prone to error, confusion, and data loss. As professionals, we need an engineered solution. That solution is a Version Control System (VCS).
Imagine your project folder is a magic notebook.
Git is this magic notebook.
For now, forget the internet. Forget collaboration. Git is a tool that works 100% on your local machine. It is your private time machine for your project. Everything we do in this module happens only on your computer.
We will master the local universe first. This includes:
To master Git, you must internalize its three distinct areas.
This four-command sequence will become muscle memory.
git add <filename> or git add . - Prepare the ingredients.
git commit -m "Your message" - Take the snapshot.
Your commit history tells a story. Make it a good one.
We use a format
called Conventional Commits.
Format: <type>(<scope>): <subject>
| Type | Purpose | Example |
|---|---|---|
| feat | A new feature for the user. | feat(auth): Add password reset endpoint |
| fix | A bug fix for the user. | fix(api): Correctly handle null values in user response |
| docs | Changes to documentation only. | docs(readme): Update installation instructions |
| style | Formatting changes, white-space, etc. No code logic change. | style(core): Format code according to prettier rules |
| refactor | A code change that neither fixes a bug nor adds a feature. | refactor(user): Simplify user creation logic |
| test | Adding or correcting tests. | test(auth): Add unit tests for login service |
| chore | Changes to the build process or auxiliary tools. | chore(deps): Upgrade NestJS to version 9.1 |
Opening the Magic Notebook: git log
You have made your first commit. You have saved the first page in your project's history. How do you look at it?
The git log command is your window into the past. When you run it, you will see a chronological list of every commit, starting with the most recent.
Let's break down the output of git log piece by piece:
$ git log
commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name
Date: Mon Aug 25 01:45:00 2025 +0100
feat: Create initial recipe file
The default git log can be very verbose.
Here are some
incredibly useful flags to customize
the view:
git log --oneline: This is the best way to get a quick overview of your project's history. It condenses each commit to a single line.
$ git log --oneline
a1b2c3d (HEAD -> main) feat: Create initial recipe file
git log --graph: This will draw a little ASCII art graph in the terminal showing how the branches diverge and merge. It's not useful now, but it will become invaluable when we start branching.
git log --stat: This shows the list of files that were changed in each commit, as well as how many lines were added or removed.
You can even combine them! A common and powerful alias many developers use is git log --oneline --graph --all
The Sacred Timeline: The main Branch
Think of the main branch as the "Sacred Timeline" in a sci-fi movie. This timeline represents the official, stable, working, and deployed version of your code. You must protect it at all costs. You never, ever work directly on the main branch.
Directly committing to main is like performing surgery on a live patient without knowing if your new technique will work. It's reckless and unprofessional.
Creating a Parallel Universe: Branching
So how do we do work? We create a branch.
A branch is a separate, isolated, parallel timeline. It's a "What If...?" universe where you can safely work on a new feature or experiment with an idea.
Commands:
The Portal Gun: git checkout -b
You will almost never use git branch and git checkout separately. There is a far more convenient command that does both at once.
git checkout -b <branch-name>
Let's see it in action:
# We are on the main timeline
$ git status
On branch main
# Let's create a new feature branch
# to add a user login system
$ git checkout -b feat/user-login
Switched to a new branch 'feat/user-login'
# The portal gun worked!
$ git status
On branch feat/user-login
Now, if you create a file called login.js, add it, and commit it, that commit will exist only in the feat/user-login timeline. If you were to git checkout main, login.js would instantly disappear from your file system, because it does not exist in the main timeline's history. This is the magic of branches in action.
Your new feature is complete and tested on its branch. It's time to bring that work into the "Sacred Timeline" (main). This process is called merging.
The simplest case is a "fast-forward" merge. This happens when the main branch has had no new commits since you created your feature branch.
Analogy: You wrote a few new pages for your cookbook in a separate notebook. The main cookbook hasn't been touched. To merge, you simply tape your new pages onto the end of the main cookbook. The history is a single, straight line.
The Two-Step Merge Dance:
Return to the timeline you want to update. This is the branch that will receive the changes.
git checkout main
Return to the timeline you want to update. This is the branch that will receive the changes.
git merge feat/user-login
The main branch pointer will simply "fast-forward" to the same commit as your feature branch tip.
What if, while you were working on your feature, someone else merged their own feature into main? Now the timelines have truly diverged.
You can't just fast-forward main anymore. Git needs to perform a three-way merge.
How it works: Git looks at three commits:
It then combines the work from both branches and creates a special new merge commit on the main branch. This merge commit has two parents, tying the two divergent histories back together.
The commands are exactly the same: git checkout main, then git merge <branch-name>. Git is smart enough to know which type of merge to perform.
This section covers the guided tour of the GitHub platform: what it is, the anatomy of a repository page, the Issue tracker, and the concept of "remotes," as detailed previously.
It's time to go online. If Git is your private notebook, GitHub is the world's largest library, coffee shop, and town square for developers.
Let's take a guided tour. When you go to a repository on GitHub (e.g., github.com/nestjs/nest), you'll see this:
Your local Git repository doesn't know GitHub exists. You have to create a connection.
A remote is a named pointer to another repository somewhere else (usually on the internet). It's a bookmark.
You can view your remotes with the command git remote -v.
We need to talk to GitHub securely. SSH (Secure Shell) uses a system called Public-Key Cryptography.
Imagine your computer has a unique, custom-made padlock and the only key that can open it.
When you want to push code, GitHub takes your public padlock, locks your code in a box, and sends it to you. The only way you can prove you are who you say you are is if you can unlock the box with your private key.
This system allows for secure communication without ever sending a password over the internet. This is the professional standard.
Generate a Key Pair: We will use a modern, secure algorithm called ed25519. Open your terminal and run this, using your GitHub email:
ssh-keygen -t ed25519 -C "your_email@example.com"
Press Enter three times to accept the default file location and to skip setting a passphrase for now.
Copy Your PUBLIC Key: We need to copy the contents of the "padlock" file.
cat ~/.ssh/id_ed25519.pub
This command will print a long string starting with ssh-ed25519.... Highlight this entire string and copy it to your clipboard.
ssh -T git@github.com
You may see a message asking to verify the host's authenticity. Type yes and press Enter. If you see a welcome message with your username, it worked. You are now set up for secure, passwordless Git operations.
clone, pull, push
You NEVER push directly to the main branch of a collaborative project. Instead, you propose your changes via a Pull Request (PR).
A Pull Request is a formal request to the project maintainers: "I have made some changes on my branch, and I would like you to please pull them into the main branch."
The Professional Workflow:
When you open a PR, you'll see a new screen.
This is where Code Review happens. Your teammates will:
This is the moment of celebration.
Scenario: You're in the middle of working on a complex feature on your branch. You have a dozen changed files, but you're not ready to commit. Suddenly, your boss runs over. "There's a critical bug on the live website! You need to fix it right now!"
You can't commit your half-finished work. You can't switch branches because Git will complain about your uncommitted changes. What do you do?
You use git stash.
When you're done with the emergency:
A merge conflict is not an error. It is a natural, expected part of collaborative development. It is Git's way of saying: "I have encountered an ambiguity that I cannot solve. I am pausing to prevent data loss and am now asking you, the intelligent human, to make the final decision."
When does it happen? When two branches have made different changes to the exact same lines in the exact same file.
Your terminal will stop and show you this:
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Git has paused the merge and marked the file with conflict markers. Open index.html in your code editor. You will see something like this:
<<<<<<< HEAD
<header>
<a href="/">Logo</a>
<nav>
<a href="/home">Home</a>
</nav>
</header>
=======
<h1>
<a href="/">Logo</a>
<nav>
<a href="/home">Home</a>
<a href="/about">About Us</a>
</nav>
</h1>
>>>>>>> origin/main
Here's how to read this:
You can resolve this with any text editor. Your job is to be the final arbiter.
The final, correct code should be:
<header>
<a href="/">Logo</a>
<nav>
<a href="/home">Home</a>
<a href="/about">About Us</a>
</nav>
</header>
Finalizing the Merge:
Modern code editors like VS Code make this process much easier and safer.
When you open the conflicted file in VS Code:
This section covers the careful introduction to git rebase, explaining what it is, its use cases for cleaning local history, and the golden rule of never rebasing shared branches, as detailed previously.