Git, GitHub, and GitLab: A Complete Guide on Version Control System in 2025

Git, GitHub, and GitLab: A Complete Guide of Version Control System

Whether you’re just starting your coding journey or you’re a seasoned engineer brushing up on fundamentals, this comprehensive guide will help you master Git, GitHub, and GitLab — the backbone of modern software development.

Why You Need to Learn Git, GitHub, and GitLab

In today’s world of collaborative software development, version control isn’t optional — it’s essential. Whether you’re working solo on a personal project or part of a 100-member engineering team, tracking changes, managing code versions, and collaborating efficiently are non-negotiable.

Enter Git, GitHub, and GitLab — the holy trinity of modern version control. But what exactly are they? How do they differ? And how can you use them effectively?

This guide breaks it all down — from the basics to advanced workflows — so both beginners and experienced developers can walk away with a deeper understanding and practical skills.

What Is Git? The Foundation of Version Control

Git: The Version Control System Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005 to help manage the development of the Linux kernel. It allows developers to:

  • Track changes in source code over time
  • Revert to previous versions
  • Work on features in isolation (branches)
  • Collaborate with others without overwriting each other’s work

Unlike older centralized systems (like SVN), Git is distributed, meaning every developer has a full copy of the project history on their local machine. This makes operations faster and enables offline work.

Key Concepts in Git

Let’s cover the core building blocks of Git:

1. Repository (Repo) A repository is a directory (folder) that contains your project files and the entire version history tracked by Git.

  • Local Repository: On your computer.
  • Remote Repository: Hosted on a server (e.g., GitHub, GitLab).

2. Commit A commit is a snapshot of your code at a specific point in time. Each commit has:

  • A unique hash (e.g., a1b2c3d)
  • Author and timestamp
  • Commit message (e.g., “Fix login bug”)

3. Branch A branch is an independent line of development. The default branch is usually main (formerly master). You create branches to work on features, fixes, or experiments without affecting the main code.

4. Merge Merging combines changes from one branch into another (e.g., merging a feature branch into main).

5. Remote A remote is a version of your repository hosted on the internet or network (e.g., on GitHub). The most common remote is named origin.

Installing and Setting Up Git

Before you can use Git, you need to install it.

Install Git

  • Windows: Download from git-scm.com
  • macOS: Use Homebrew: brew install git
  • Linux (Ubuntu/Debian): sudo apt install git

Configure Git After installation, set your identity:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

You can verify settings:

git config --list

💡 Pro Tip: Use the same email you use for GitHub/GitLab to ensure your commits are linked to your account.

Basic Git Workflow: The 5 Essential Commands

Here’s a minimal workflow to get started:

1. Initialize a Repository

git init

Creates a new local Git repository in the current directory.

2. Clone an Existing Repository

git clone https://github.com/username/project.git

Downloads a remote repository to your local machine.

3. Check Status

git status

Shows which files are modified, staged, or untracked.

4. Stage Changes

git add filename.txt

Stages a specific file.

git add .

Stages all changes in the current directory.

5. Commit Changes

git commit -m "Add user authentication feature"

Saves the staged changes with a descriptive message.

6. Push to Remote

git push origin main

Uploads your local commits to the remote repository (e.g., GitHub).

🔁 Pull Before You Push: Always git pull origin main before pushing to avoid conflicts.

Branching and Merging: Mastering Collaboration

Branching is Git’s superpower. Let’s dive in.

Create a New Branch

git branch feature/login-ui

Creates a branch but doesn’t switch to it.

git checkout feature/login-ui

Switches to the branch.

Or do both at once:

git checkout -b feature/login-ui

List All Branches

git branch

Current branch is marked with *.

Switch Between Branches

git checkout main

Merge a Branch

git checkout main
git merge feature/login-ui

Merges feature/login-ui into main.

Delete a Branch

git branch -d feature/login-ui

Deletes the local branch.

⚠️ Warning: Only delete a branch after merging or if it’s no longer needed.

Resolving Merge Conflicts

Sometimes, two people edit the same part of a file. Git can’t decide which change to keep — this is a merge conflict.

Example conflict in app.js:

<<<<<<< HEAD
const version = "2.0";
=======
const version = "2.1";
>>>>>>> feature/new-ui

How to Resolve

  1. Open the file and decide which version to keep.
  2. Remove the conflict markers (<<<<<<<, =======, >>>>>>>).
  3. Save the file.
  4. Stage and commit:
git add app.js
git commit -m "Resolve merge conflict in app.js"

💡 Tip: Use a merge tool like VS Code’s built-in conflict resolver or git mergetool.

Undoing Mistakes: Git Reset, Revert, and Amend

Everyone makes mistakes. Git helps you fix them.

Amend the Last Commit Accidentally forgot a file or typo in the message?

git add forgotten-file.js
git commit --amend -m "Add login form and validation"

⚠️ Don’t amend commits that have already been pushed — it rewrites history and can cause issues for collaborators.

Unstage a File

git reset HEAD filename.txt

Removes the file from staging but keeps changes.

Discard Local Changes

git checkout -- filename.txt

Reverts the file to the last committed version.

⚠️ This deletes uncommitted changes permanently.

Revert a Commit To undo a commit that’s already been pushed:

git revert <commit-hash>

Creates a new commit that undoes the changes.

Hard Reset (Use with Caution!)

git reset --hard HEAD~2

Removes the last two commits and all changes. Use only on local branches.

🛑 Never –hard reset on shared branches.

Git Reflog: Your Safety Net

The git reflog command records every change to HEAD (the tip of the current branch). It’s incredibly useful for recovering lost commits, branches, or states.

git reflog

This will show a history of where HEAD has been, allowing you to git reset –hard to a previous state if you accidentally deleted commits or branches.

Git Diff: Understanding Changes git diff helps you see changes between various states of your repository.

  • Changes in your working directory not yet staged:
git diff

How to read the difference

  • a/ – the original file (before changes)
  • b/ – the updated file (after changes)
  • — – marks the beginning of the original file
  • +++ – marks the beginning of the updated file
  • @@ – shows the line numbers and position of changes

Git Rebase: similar to merge but changes the base, it replays the commit from branch you are on to the branch you want to rebase

  • Ensure you are on the branch you want to rebase
`git rebase branch-name` 
`git rebase —continue` after resolving any conflict if occur

What Is GitHub? Your Public Code Hub

GitHub: Git Hosting + Collaboration Platform GitHub is a web-based platform that hosts Git repositories and adds powerful collaboration tools:

  • Pull Requests (PRs)
  • Issues & Project Boards
  • CI/CD (GitHub Actions)
  • Code Reviews
  • Wikis & Documentation

Used by millions of developers and open-source projects (including Linux, React, and TensorFlow).

Creating a GitHub Account

  1. Go to github.com
  2. Sign up for a free account
  3. Verify your email

Create a New Repository on GitHub

  1. Click “New” on your dashboard
  2. Name your repo (e.g., my-first-app)
  3. Choose Public or Private
  4. Initialize with a README (recommended)
  5. Click Create Repository

You’ll get a URL like: https://github.com/your-username/my-first-app.git

Push Your Local Project to GitHub

git remote add origin https://github.com/your-username/my-first-app.git
git branch -M main
git push -u origin main

Now your code is live on GitHub!

🔐 Use SSH for Better Security: Replace HTTPS URL with SSH: [email protected]:your-username/my-first-app.git. Set up SSH keys here.

Pull Requests: The Heart of Collaboration

What Is a Pull Request (PR)? A Pull Request is a proposal to merge changes from one branch into another. It allows:

  • Code review
  • Discussion
  • Automated testing
  • Approval workflows

Creating a Pull Request

  1. Push your feature branch:
git push origin feature/new-button
  1. On GitHub, go to your repo → Pull Requests → New Pull Request
  2. Select: base: main ← compare: feature/new-button
  3. Add title and description
  4. Click Create Pull Request

Reviewing and Merging a PR Team members can:

  • Comment on lines of code
  • Request changes
  • Approve the PR

Once approved, click Merge Pull Request → Confirm merge.

💡 Best Practice: Always delete the branch after merging.

GitHub Issues and Project Management

Track Bugs and Features with Issues Click “Issues” → “New Issue”

Use templates for:

  • Bug reports
  • Feature requests
  • Tasks

Organize Work with Projects GitHub Projects (now based on GitHub Issues) lets you create Kanban boards:

  • To Do
  • In Progress
  • Done

Link issues to project cards for better tracking.

Labels and Milestones

  • Labels: Categorize issues (e.g., bug, enhancement, help wanted)
  • Milestones: Group issues by release or deadline

GitHub Actions: Automate Your Workflow

What Is GitHub Actions? GitHub Actions lets you automate tasks like:

  • Running tests
  • Building and deploying apps
  • Linting code
  • Sending notifications

All defined in .github/workflows/ YAML files.

Example: Run Tests on Every Push Create .github/workflows/test.yml:

name: Run Tests
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm install
- run: npm test

Now, every time you push, tests run automatically.

🚀 Use Actions for CI/CD, auto-deploy to Vercel, Netlify, or AWS.

What Is GitLab? The All-in-One DevOps Platform

GitLab vs GitHub: Key Differences

-------------------------------------------------------------------------------
| Feature | GitHub | GitLab |
| --------------------|-----------------------------|-------------------------|
| CI/CD | GitHub Actions | Built-in GitLab CI/CD |
| Self-hosting | GitHub Enterprise (Paid) | Free Community Edition |
| DevOps Integration | Requires Third Party tools | Full DevOps platform |
| Free Private Repos | Yes (unlimited) | Yes (limitated) |
| Issue Boards | Basic | Advanced |
-------------------------------------------------------------------------------

Signing Up for GitLab

  1. Go to gitlab.com
  2. Sign up for free
  3. Verify email

Or self-host GitLab on your own server.

GitLab Projects and Groups

Create a Project

  1. Click “New Project”
  2. Choose: Create blank project
  3. Name: my-api-service
  4. Visibility: Public, Internal, or Private
  5. Initialize with README
  6. Click Create Project

Groups for Team Management Create Groups to organize multiple projects (e.g., frontend-team, backend-services).

Invite team members with roles:

  • Guest
  • Reporter
  • Developer
  • Maintainer
  • Owner

GitLab CI/CD: Built-In Automation

.gitlab-ci.yml: The CI Configuration GitLab uses a .gitlab-ci.yml file in the root of your repo.

Example: Build and test a Node.js app

stages:
- test
- deploy
run-tests:
stage: test
script:
- npm install
- npm test
only:
- main
deploy-prod:
stage: deploy
script:
- echo "Deploying to production..."
# Add your deploy script here
when: manual
only:
- main

View Pipelines Go to CI/CD → Pipelines to see real-time build status.

  • ✅ Success
  • ❌ Failed
  • ⏳ Running

Click on a job to see logs.

💡 GitLab Runners execute your CI jobs. You can use shared runners or set up your own.

Advanced Git Techniques for Experienced Engineers

Rebasing: Clean, Linear History Instead of merging, use rebase to replay your commits on top of the latest main.

git checkout feature/new-api
git rebase main

Then fast-forward merge:

git checkout main
git merge feature/new-api

Result: A clean, linear history.

⚠️ Don’t rebase shared branches — it rewrites history.

Interactive Rebase: Rewrite Commit History

git rebase -i HEAD~3

Lets you:

  • Edit commit messages
  • Squash commits
  • Reorder or drop commits

Useful for cleaning up before a PR.

Stashing: Save Work in Progress Need to switch branches but don’t want to commit incomplete code?

git stash

Later, restore:

git stash pop

Or list stashes:

git stash list

Tagging: Mark Releases

git tag v1.0.0
git push origin v1.0.0

Use semantic versioning: v{major}.{minor}.{patch}

Git Hooks: Automate Local Tasks Git hooks are scripts that run on events like pre-commit, post-merge.

Example: Prevent committing secrets

Create .git/hooks/pre-commit:

#!/bin/sh
if git diff --cached | grep -q "AWS_SECRET"; then
echo "Error: AWS secret detected!"
exit 1
fi

Make it executable: chmod +x .git/hooks/pre-commit

Best Practices for Git, GitHub, and GitLab

1. Write Meaningful Commit Messages Follow this format:

feat: add user profile page
fix: resolve login timeout issue
docs: update API documentation
style: format code with Prettier
refactor: improve error handling
test: add unit tests for auth module
chore: update dependencies

Use the Conventional Commits standard.

2. Use Feature Branches Never commit directly to main. Use branches:

  • feature/user-auth
  • bugfix/login-error
  • hotfix/critical-security

3. Keep Pull/Merge Requests Small Smaller PRs are easier to review and less error-prone.

4. Review Code Thoroughly As a reviewer:

  • Check logic
  • Suggest improvements
  • Ensure tests pass
  • Verify documentation

5. Protect Main Branch On GitHub/GitLab, enable branch protection:

  • Require PR reviews
  • Require status checks (CI passes)
  • Prevent force pushes

6. Document Your Workflow Define team rules in a CONTRIBUTING.md file:

## Contributing
1. Fork the repo
2. Create a feature branch
3. Commit with Conventional Commits
4. Push and open a PR
5. Wait for review

Real-World Workflow: From Idea to Deployment

Let’s walk through a full cycle using Git, GitHub, and GitLab.

Scenario: Add Dark Mode to a Web App

Step 1: Create a Branch

git checkout -b feature/dark-mode

Step 2: Code the Feature Edit CSS and JS files.

Step 3: Commit and Push

git add .
git commit -m "feat: implement dark mode toggle"
git push origin feature/dark-mode

Step 4: Open a Pull/Merge Request

  • GitHub: Pull Request
  • GitLab: Merge Request

Add screenshots and description.

Step 5: Code Review Team reviews, suggests changes.

You update:

git add .
git commit -m "fix: adjust dark mode contrast"
git push origin feature/dark-mode

PR updates automatically.

Step 6: CI/CD Runs

  • GitHub Actions or GitLab CI runs tests
  • Coverage, linting, builds

Step 7: Merge and Deploy Once approved:

  • Merge into main
  • CI/CD deploys to production

Step 8: Delete Branch Clean up:

git branch -d feature/dark-mode
git push origin --delete feature/dark-mode

Troubleshooting Common Git Issues

1. “Everything up to date” but changes not pushed You forgot to commit:

git add .
git commit -m "Your message"
git push origin main

2. Merge Conflict After Pull

git pull origin main
# Resolve conflicts
git add .
git commit
git push origin main

3. Accidentally Committed to Main Create a branch from current state:

git checkout -b feature/accidental-changes
git checkout main
git reset --hard HEAD~1 # Only if not pushed!

4. Remote Repository Not Found Check remote URL:

git remote -v
git remote set-url origin https://github.com/user/repo.git

Conclusion: Master Version Control, Master Your Career

Git, GitHub, and GitLab aren’t just tools — they’re the foundation of modern software engineering. Whether you’re a beginner learning your first git commit, or a senior engineer designing CI/CD pipelines, mastering these tools will:

  • Boost your productivity
  • Improve collaboration
  • Make you a better engineer

Start small. Practice daily. Use branches. Write good commits. Embrace pull requests.

And remember: every expert was once a beginner who didn’t give up.

Further Learning Resources

FAQ

Is Git the same as GitHub? No. Git is the version control system. GitHub is a platform that hosts Git repositories.

Can I use Git without GitHub or GitLab? Yes! Git works locally. Hosting platforms are optional but recommended for backup and collaboration.

Which is better: GitHub or GitLab? It depends. GitHub is better for open-source and integrations. GitLab excels in DevOps and self-hosting.

How do I contribute to open-source projects?

  1. Fork the repo
  2. Clone your fork
  3. Create a feature branch
  4. Make changes
  5. Push and open a PR

Final Thoughts

Version control is no longer a “nice-to-have.” It’s a must-have skill for any developer.

By mastering Git, GitHub, and GitLab, you’re not just learning tools — you’re adopting a mindset of collaboration, automation, and continuous improvement.

So go ahead. Initialize a repo. Make your first commit. Push to GitHub. Open your first PR.

💬 Let’s Connect

If you found this article insightful, follow me for more deep-dive content on Java, backend development, and modern engineering practices.

📩 Have a topic in mind you’d like me to explore next?
Leave a comment or reach out directly.

👨‍💻Published by Sam Khera
Java Developer | Enthusiastic for India’s Tech Future

📬Connect: [email protected]


Git, GitHub, and GitLab: A Complete Guide on Version Control System in 2025 was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post first appeared on Read More