Git is a version control system used by over 100 million developers. It tracks every change to your code, lets you undo mistakes, and makes it possible for teams to work on the same project without overwriting each other's work. GitHub and GitLab are websites that host your Git projects online — think of Git as the engine and GitHub/GitLab as the garage where you park and share your car. This guide takes you from zero to confidently using Git in your daily workflow.
What Is Version Control and Why Do You Need It?
Imagine saving files as essay-final.doc, essay-final-v2.doc, essay-ACTUALLY-final.doc. Version control replaces that chaos with a single folder that keeps a complete history of every change. You can go back to any version, see what changed and when, and collaborate without stepping on toes. Git is free, fast, and works offline.
How Git Is Structured
Before learning any commands, it helps to know where your code lives at each stage. Git organizes things into three layers. Your working directory is the folder with the files you actually open and edit. When you're happy with a change, you commit it — that saves a snapshot into your local repository (a hidden .git folder on your machine). Finally, when you want to share your work or back it up, you push those commits to the remote repository on GitHub or GitLab, where your teammates can see them. Going the other way, you pull to download their latest commits to your computer.
The diagram below shows how these three layers connect — every Git command you'll learn moves code between them:
Key Concepts
Repository (repo)
Your project folder tracked by Git — files plus full change history.
Clone
Download a remote repo to your computer. Like a zip, but with full history.
Commit
A snapshot of your changes. Like a video game save point.
Branch
A parallel version of your code to work on without affecting main.
Main branch
The default branch — the official, stable version of your project.
Feature branch
A branch for one specific task — a feature, a bug fix, etc.
Remote
The online copy on GitHub/GitLab. Your local repo syncs with it.
Push / Pull
Push uploads your commits. Pull downloads others' commits.
Pull Request (PR)
A request to merge your branch into main. Others review before merging.
Conflict
Two people changed the same line. Git asks you to pick a version.
How Branches Work
A branch is like making a copy of your project at a specific point in time. The main branch is the "official" version — the one that's considered stable and complete. You never work directly on it. Instead, you create a feature branch — a separate line of development where you can experiment, add code, and break things without affecting anyone else. When your work is ready, it gets merged back into main through a pull request.
In the diagram below, commits A and B happen on main. A feature branch splits off from B, gets two commits (X and Y), and eventually merges back. Meanwhile, someone else added commit C to main — Git handles combining everything:
Installing Git
Download from git-scm.com (macOS: brew install git, Linux: usually pre-installed). After installing, you need to tell Git who you are. Every commit you make is stamped with your name and email, so your teammates can see who made each change:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"The --global flag means this applies to all your projects on this computer — you only need to do this once. Then create a free account on GitHub or GitLab.
The Everyday Workflow
This is the cycle you'll repeat for every piece of work — a new feature, a bug fix, a text change. It might look like a lot of steps, but it becomes second nature fast. Every step below explains what's happening conceptually, then shows you how to do it in the terminal and in VS Code side by side.
Step 1: Clone the repository
What this means: Cloning creates a full copy of a remote repository on your computer — all files, all branches, the complete history. It's a one-time action per project. After cloning, you have your own local copy that you can work on offline.
Go to the project page on GitHub/GitLab, click the green Code button, and copy the URL. Then:
git clone https://github.com/user/project.git
cd projectThe cd project part just moves your terminal into the new folder that Git created.
Step 2: Get the latest main
What this means: Before starting new work, you want to make sure your local main branch matches what's on GitHub/GitLab. Other people may have merged changes since you last checked. Pulling downloads those new commits and applies them to your local copy.
git checkout main
git pullgit checkout main switches you to the main branch. git pull fetches the latest commits from the remote and merges them into your local main. Always do this before creating a new branch — it prevents conflicts later.
Step 3: Create a feature branch
What this means: You're creating your own private workspace branching off from main. Any changes you make here won't affect main or anyone else's work until you explicitly merge them back. Think of it as making a photocopy of the project to scribble on.
git checkout -b add-login-pageThe -b flag means "create a new branch and switch to it in one step." Without -b, checkout only switches to an existing branch. Name your branch after what you're working on — add-login-page, fix-header-bug, etc. Your teammates should be able to tell what you're doing from the branch name alone.
Step 4: Edit files, stage, and commit
What this means: Now you do your actual work — edit files, add new ones, delete old ones. When you reach a natural save point (you finished a function, fixed a bug, completed a piece of UI), you create a commit. But committing in Git is a two-step process:
- Stage — tell Git which specific files (or changes) you want to include in this commit. Not every changed file needs to go in — maybe you edited three files but only two are ready.
- Commit — save those staged changes as a permanent snapshot with a message describing what you did. This message is important — it shows up in the project history and helps your team understand what changed and why.
git add src/login.tsx src/styles.css
git commit -m "add login page layout"git add stages specific files. You list the files you want separated by spaces. The -m flag on git commit lets you write the commit message inline. Without -m, Git opens a text editor for you to type the message — which can be confusing the first time. Keep messages short and descriptive: "fix header alignment on mobile" is better than "stuff". You can (and should) make multiple commits as you work — small, frequent commits are much easier to review and undo than one giant commit at the end.
Step 5: Push your branch
What this means: So far, all your commits only exist on your computer. Pushing uploads your branch and its commits to GitHub/GitLab so others can see your work and so you have a backup. Until you push, no one else can see what you've done.
git push -u origin add-login-pageLet's break down that command: origin is the default name Git gives to the remote server you cloned from (GitHub/GitLab). add-login-page is the branch name you're pushing. The -u flag (short for --set-upstream) links your local branch to the remote one, so next time you can just type git push without specifying the branch name. You only need -u on the first push of a new branch.
Step 6: Open a Pull Request
What this means: A pull request (PR) is a formal way of saying "I'm done with this work — please review it and merge it into main." It's not a Git feature — it's a GitHub/GitLab feature built on top of Git. PRs are where collaboration happens: teammates can see exactly what you changed, leave comments on specific lines, suggest improvements, and approve the changes. On GitLab, these are called merge requests (MRs) — same concept, different name.
After you push, visit GitHub/GitLab in your browser. You'll usually see a yellow banner saying your branch was recently pushed, with a button to create a PR. Click it, write a title and description explaining what your changes do and why, then submit. Your teammates will get notified and can start reviewing.
Step 7: Merge, then update local main
What this means: Once your PR is approved, clicking Merge on the GitHub/GitLab page takes all your commits from the feature branch and applies them to main. Your work is now part of the official project. But your local main branch doesn't know about this yet — it still looks the way it did before the merge happened on the server. You need to pull those changes down.
git checkout main
git pullNow your local main matches the remote. You're ready to start the cycle again: create a new branch for the next piece of work.
Handling Conflicts
Conflicts are the one part of Git that scares beginners, but they're completely normal and usually easy to fix. A conflict happens when two people change the exact same lines in the same file. Git is smart enough to automatically merge changes in different files, or even different parts of the same file. It only asks for your help when it literally can't decide which version of a specific line to keep.
When this happens, Git inserts special markers into the affected file so you can see both versions:
<<<<<<< HEAD (your changes)
const title = "Welcome Back";
=======
const title = "Hello World";
>>>>>>> main (their changes)Resolving in VS Code
VS Code highlights conflicts and shows clickable buttons above each one:
- Accept Current Change — keep yours
- Accept Incoming Change — keep theirs
- Accept Both Changes — include both
After resolving all conflicts in a file, you need to tell Git "I've fixed this" by staging and committing. This is the same add-commit-push flow you already know:
git add src/login.tsx
git commit -m "resolve merge conflict in login page"
git pushThe escape hatch
If a conflict feels too complex or you're worried about making a mistake — don't panic. Nothing is ever truly lost in Git. A safe fallback: copy your changed files somewhere else (your Desktop, another folder), switch to main and pull the latest, create a fresh branch, then paste your changes back in and commit. Your original branch still exists on GitHub/GitLab as a backup.
What Is Rebase?
Imagine you created your feature branch from main on Monday. By Thursday, your teammates have merged several PRs into main — so main has moved forward while you were working. Your branch is now based on an outdated version of main. This can cause two problems: your code might conflict with the new changes, and you can't be sure your feature actually works with the latest code.
Rebasing solves this. It takes all the commits on your feature branch and replays them on top of the latest main — as if you had just created your branch from today's main instead of Monday's. After rebasing, your branch includes all the recent changes plus your own work on top. If there are conflicts, Git will ask you to resolve them during the rebase (one commit at a time), so you can fix everything locally before you push.
The most common use case is updating your feature branch before pushing or creating a PR. This makes sure your changes work with the latest main and that your PR won't have conflicts:
# While on your feature branch:
git fetch origin
git rebase origin/maingit fetch origin downloads the latest state of the remote without changing your files. git rebase origin/main then replays your commits on top of the freshly fetched main. If there are no conflicts, it completes silently and you can push. If there are conflicts, Git pauses and asks you to resolve them (the same way as merge conflicts), then you run git rebase --continue to keep going.
As a beginner, rebasing is completely optional. The merge workflow works fine without it. But it's a good habit to pick up once you're comfortable: rebase your branch onto the latest main before pushing, so your PR is always clean and conflict-free. If you ever get confused during a rebase, git rebase --abort cancels the whole thing and puts your branch back exactly as it was — no harm done.
GitHub vs GitLab
Both host Git repos online. The Git commands are identical — only the web interface differs.
| Feature | GitHub | GitLab |
|---|---|---|
| Code review | Pull Requests | Merge Requests |
| CI/CD | GitHub Actions | GitLab CI/CD (built-in) |
| Free private repos | Yes | Yes |
| Self-hosting | Enterprise (paid) | CE (free) |
| Best for | Open source, community | Enterprise, DevOps |
Starting out? Go with GitHub — largest community and most learning resources.
Helpful Tools
VS Code (built-in)
Full Git support in the Source Control panel. Install the GitLens extension for blame annotations.
GitHub Desktop
Free visual Git client. Clone, branch, commit, push — no terminal needed. Works with GitHub and GitLab.
GitHub CLI (gh)
Create PRs, review code, and manage issues from the terminal. Great once you're comfortable with Git basics.
Quick Reference
| Action | Terminal | VS Code |
|---|---|---|
| Clone a repo | git clone <url> | Ctrl+Shift+P → Git: Clone |
| Pull latest | git pull | Sync icon ↻ |
| Create branch | git checkout -b <name> | Branch name → Create new branch |
| Switch branch | git checkout <name> | Click branch name → select |
| Stage files | git add <files> | Click + next to file |
| Commit | git commit -m "msg" | Type message → ✓ Commit |
| Push | git push | Sync Changes / Publish Branch |
| See changes | git diff | Click changed file in Source Control |
| View history | git log --oneline | GitLens extension or Timeline view |
Common Mistakes
- Committing to main directly — always create a feature branch first
- Huge commits with vague messages — keep commits small with descriptive messages
- Forgetting to pull before branching — always
git pullon main first - Committing secrets — add
.envto.gitignore - Panicking during a conflict — read the markers, pick a version, commit. Use the escape hatch if stuck.
Frequently Asked Questions
What is the difference between Git and GitHub?
Git is the version control tool on your computer. GitHub is a website that hosts Git repos online for sharing and collaboration. GitLab is an alternative to GitHub. You use Git locally and push to GitHub/GitLab to share.
Do I need to use the terminal for Git?
No. VS Code has full built-in Git support — clone, branch, commit, push, pull, and resolve conflicts without a terminal. GitHub Desktop is another visual option. Learning terminal commands is still valuable since they work everywhere.
How often should I commit?
Commit when you complete a small, logical unit of work. If you can describe the change in one sentence, it's a good commit. Frequent small commits are easier to review and revert.
What is the difference between git pull and git fetch?
git fetch downloads changes but doesn't apply them. git pull fetches AND merges into your branch. For beginners, git pull is what you want.
How do I undo my last commit?
If not pushed yet: "git reset --soft HEAD~1" undoes the commit but keeps changes staged. If already pushed: "git revert HEAD" creates a new commit that reverses it. Never rewrite history others have pulled.
What happens if I accidentally commit to main?
If not pushed: "git branch my-feature" then "git reset HEAD~1" on main. If pushed: ask your team — most teams protect main so direct pushes are blocked.
References
- Pro Git Book (free) — the official, comprehensive Git book by Scott Chacon and Ben Straub
- Official Git Tutorial — beginner tutorial from the Git documentation
- VS Code: Introduction to Git — official guide to using Git within VS Code
- GitHub: About Pull Requests — official documentation on pull requests
- GitHub Desktop — free visual Git client for macOS and Windows
- GitLab: What Is a Git Workflow? — overview of Git workflows and branching strategies