To try the hands-on steps you will need Git installed from git-scm.com and a terminal. Everything here is free.
To try the hands-on steps you will need Git installed from git-scm.com and a terminal. Everything here is free.
Git records the full history of your code: every change, who made it, and when. It lets a whole team work on the same files at once without overwriting each other, and it lets you undo mistakes safely. You will run about ten Git commands every day for the rest of your career. Learn what each one does to the history and the rest is detail.
Written for the college passout or career switcher who has emailed a zip of code to a teammate, or kept a folder named final, final2, and final_really. Git is the end of all that.
Picture the folder everyone has made at least once. A file called report.docx, then report_v2.docx, then report_final.docx, then report_final_ACTUAL.docx. You cannot tell what changed between them, you cannot merge two people is edits, and if you delete the wrong one the work is gone. Now imagine that folder is the code that runs a company. That is the problem Git solves, and it solves it so well that no professional software team on the planet works without it.
Part 4 got you comfortable on the Linux command line, and Git runs right there. Every command in this part is something you type into the same terminal. If Linux is the surface DevOps tools sit on, Git is the first tool you put on it, because it is where your code lives before a pipeline ever touches it.
What Git actually stores
Git does not save a pile of copies. It saves a history of snapshots. Each snapshot is called a commit, and a commit records what the files looked like at one moment, plus who made it, when, and a short message saying why. Commits form a chain, each pointing back to the one before it, so the whole story of a project is a line of commits you can walk backward through. When you undo a change in Git, you are not deleting anything. You are stepping back to an earlier snapshot that is still there.
The three areas every change passes through
This is the one mental model that makes Git click. A change moves through three places on your machine before it becomes permanent history, and a fourth if you are sharing with a team. Confusing these is the root of almost every beginner mistake, so learn them once and clearly.
The working directory is your actual folder, where you edit files. The staging area is a holding pen: you use git add to pick exactly which changes go into your next snapshot, which lets you commit related work together and leave unrelated edits for later. The repository is the permanent history, written by git commit. The remote is a shared copy on a server like GitHub or GitLab, updated with git push so your teammates can see your work.
| Command | What it does |
|---|---|
git init | Start tracking a folder |
git clone URL | Copy an existing remote repo to your machine |
git status | Show what changed and what is staged |
git add FILE | Stage a change for the next commit |
git commit -m 'msg' | Save staged changes as a snapshot |
git log --oneline | List the commit history, one line each |
git switch -c NAME | Create a branch and move onto it |
git merge NAME | Bring another branch is work into this one |
git push | Send commits to the remote |
git pull | Fetch and merge the remote is new commits |
Your first repository, commit by commit
Reading about Git teaches you nothing. Running it teaches you everything. Here is a complete first session: start a repo, make a file, and save your first snapshot. The default branch is called main on every current Git install.
$ git init
Initialized empty Git repository in /home/deploy/app/.git/
$ echo 'hello' > readme.txt
$ git status
On branch main
No commits yet
Untracked files:
readme.txt
$ git add readme.txt
$ git commit -m 'first commit'
[main (root-commit) a1b2c3d] first commit
1 file changed, 1 insertion(+)
$ git log --oneline
a1b2c3d first commitThat short string a1b2c3d is the commit is unique id. You now have a permanent snapshot you can always return to, no matter what you do to the files next.
On a fresh machine your very first commit often fails like this:
Author identity unknown*** Please tell me who you are.Git stamps every commit with a name and email and refuses to guess them. The fix is two commands you run once per machine:
$ git config --global user.name 'Your Name'$ git config --global user.email 'you@example.com'Do this the first time you set up Git on any computer and you will never see that error again.
Branching and merging without fear
A branch is a separate line of work that starts from a commit. You make a branch, build a feature on it, and the main line stays untouched and shippable the whole time. When the feature is ready, you merge it back. This is how a team of ten works on ten things at once without stepping on each other. Each person is on their own branch, and merges bring the work together.
Sometimes two branches change the same line of the same file. Git cannot know which one you want, so it stops and asks. That is a merge conflict, and it scares beginners more than anything else in Git. It should not. A conflict is just Git marking both versions in the file and waiting for you to choose.
You merge a branch and Git prints
CONFLICT (content): Merge conflict in style.css. Open the file and you see this:<<<<<<< HEADcolor: blue;=======color: green;>>>>>>> feature-buttonThe top half is what main had, the bottom half is what the branch changed. You delete the markers and the version you do not want, leaving just the line you do want. Then
git add style.css and git commit to finish the merge. That is the entire scary process. You read both, pick one, and commit.Connecting to a team: clone, push, pull
Everything so far lived on your machine. Real teams share their history through a remote, a copy of the repository on a server. You do not usually start a shared project with git init. You copy the existing one with git clone, and from then on you push your commits up and pull your teammates commits down. Here is that full loop in one session.
$ git clone git@github.com:acme/app.git
Cloning into 'app'...
remote: Enumerating objects: 214, done.
Receiving objects: 100% (214/214), done.
$ cd app
$ git switch -c fix-typo
Switched to a new branch 'fix-typo'
$ echo 'fixed' > notes.txt
$ git add notes.txt
$ git commit -m 'fix typo in notes'
[fix-typo e4f5a6b] fix typo in notes
$ git push -u origin fix-typo
Branch 'fix-typo' set up to track 'origin/fix-typo'.The -u on that first push links your local branch to the remote one, so from then on a plain git push and git pull know where to go. On GitHub or GitLab, that pushed branch becomes a pull request, which is where a teammate reviews your work before it joins main. When someone else has pushed since you last looked, git pull brings their commits into your branch. Pull often, so your work never drifts far from everyone else.
One error you will meet early: run a Git command in a folder that is not a repository and you get fatal: not a git repository (or any of the parent directories): .git. It means you are standing in the wrong folder. Run pwd to see where you are, then cd into the project, or clone it first. It is not a broken install. Git simply has nothing to track where you are standing.
It helps to picture a single change moving through named states, from a file Git has never seen to a commit sitting safely on the shared server. Each state has one command that moves it to the next.
| State | What it means | Command to advance |
|---|---|---|
| Untracked | Git is not watching this file yet | git add |
| Modified | Changed but not yet staged | git add |
| Staged | Picked for the next snapshot | git commit |
| Committed | Saved in your local history | git push |
| Pushed | Shared on the remote for the team | teammates git pull |
A simpler branching model wins
Search for Git workflows and you will drown in diagrams of GitFlow, with its develop branch, release branches, hotfix branches, and a page of rules. For most teams in 2026, that is more machinery than the job needs. The approach that has quietly won is simpler: keep one main branch that is always deployable, make short-lived branches for each change, merge them back within a day or two, and delete them. Long-lived branches drift away from main and turn every merge into a fight. The longer a branch lives, the worse the conflict when it comes home.
So as a beginner, do not memorize GitFlow because a blog said it was professional. Learn to branch, commit in small pieces, write a clear message, and merge quickly. If a future job runs a heavier model, you will pick it up in an afternoon. The habit that actually matters is small, frequent commits with messages a teammate can read.
What is the difference between git fetch and git pull? The clean answer:
git fetch downloads the new commits from the remote but does not change your working files, so you can look before you leap. git pull is git fetch followed immediately by a merge into your current branch. Pull is the convenient one, fetch is the careful one. Saying that you sometimes fetch first to see what changed before merging shows real hands-on habit, and that is what the interviewer is listening for.Your first task on almost any team is the same: clone the repo, make a branch, change something small, and open a pull request. If you can do that loop without help, you are productive on your first morning. Managers notice the junior who commits clean, small changes with readable messages, because it makes reviewing their work fast. The one who dumps a giant unexplained commit at the end of the week creates work for everyone. The habit is what gets you trusted, not the tool.
Free, about twenty minutes, all local. Run
git init in a new folder, create a file, and make a commit. Then run git switch -c feature, change the same file, and commit again. Switch back with git switch main and run git merge feature. Watch the branch fold back in. For a bonus, edit the same line on both branches before merging so you trigger a real conflict, then resolve it. How to check you did it right: git log --oneline shows all your commits, and the merged file holds the version you chose.What beginners get wrong about Git
Is Git the same thing as GitHub?
No, and mixing them up is the most common beginner slip. Git is the tool that runs on your machine and tracks history. GitHub is a website that hosts a copy of your repository so a team can share it, with extra features like pull requests and issues. GitLab and Bitbucket do the same job. You can use Git with no GitHub account at all.
What should a commit message say?
What the change does, in plain words, short enough to read at a glance. Add login validation beats update code or asdf. Six months later, that one line is the only thing telling you and your team why the change happened, so spend the five seconds.
I committed something secret, like a password. Now what?
Removing it in a new commit is not enough, because it still lives in the history. You have to rewrite history to purge it and, more importantly, treat that secret as leaked and rotate it immediately. The real lesson is to keep secrets out of Git in the first place with a .gitignore file, which tells Git to never track named files.
Do I need to learn the fancy commands like rebase?
Not on day one. Add, commit, push, pull, branch, switch, and merge cover the vast majority of real work. Rebase and its friends are worth learning once the basics are automatic, not before. Chasing advanced commands early is how beginners tie their history in knots they cannot undo.
Get the three areas and the branch-then-merge loop into your hands and you are ready for the tool that runs them automatically. Next up is Part 7 on CI/CD, where a pipeline takes every push you make and builds, tests, and ships it without you. Before that, Part 6 builds the web mental model that makes deploys make sense.
New here? Start with Part 1 on what DevOps actually means and Part 4 on the Linux command line that Git runs on. If you want the language side, the Python for Beginners series pairs well.
References
Official Git documentation
git switch reference
GitHub: About Git
About The Author
DrJha