DEV Community

Booranasak Kanthong
Booranasak Kanthong

Posted on

Git | EP01: Basic Git Commands

Concept Introduction

Understanding a few key concepts is essential before diving into Git:

  • Repository (often shortened to “repo”) is like a container where we store our files. Git tracks every change made inside this container — think of it as a folder where version history is always recorded.

  • Branch lets you create a new “branch” or version of your code — kind of like opening a new franchise of your project. It allows you to experiment, add features, or make changes without touching the main branch.

  • Commit is like taking a snapshot of your work at a specific moment in time — similar to pressing “Save” in a game or document.

  • Push: git push sends your local commits to a remote repository (like GitHub or GitLab). It’s like publishing your local work online so others can access it.

  • Pull: git pull fetches and merges changes from a remote repository into your local one — ensuring you’re up to date with the team’s latest work.

  • Merge is the process of combining changes from different branches back together.

Git vs. GitHub vs. GitLab – What’s the Difference?

If you're new to version control, it's easy to confuse Git with GitHub or GitLab. But here's the breakdown:

Git

Git is the core tool — a distributed version control system. It helps you track changes in your code, create branches, and collaborate with others locally on your computer or remotely.

Think of Git as the engine behind version control.

GitHub

GitHub is a cloud-based hosting service for Git repositories. It adds collaboration features on top of Git — like pull requests, issue tracking, and actions for CI/CD.

Think of GitHub as a social platform for developers using Git.

GitLab

GitLab is similar to GitHub but includes built-in DevOps tools — such as CI/CD pipelines, container registries, and project management features. It can be hosted on the cloud or self-hosted on your own server.

Think of GitLab as Git + DevOps in one platform.

Basic Command Line

1.) git version is used to check whether Git is installed on your computer and to see which version is currently being used.

git --version
Enter fullscreen mode Exit fullscreen mode

2.) git init initializes a new Git repository and starts tracking changes in the current folder.

git init
Enter fullscreen mode Exit fullscreen mode

3.) git remote Linking a Local Repository to a Remote
After you run git init, your project is tracked by Git locally, but it’s not yet connected to a remote repository like GitHub. To link your local repository to a remote one, use the git remote command.

git remote add origin <Your remote repository>
Enter fullscreen mode Exit fullscreen mode

For example:

git remote add origin https://github.com/your-username/your-repo.git
Enter fullscreen mode Exit fullscreen mode

This command adds a remote repository named origin (which is the conventional default name) and associates it with the provided URL.

4.) git clone Copy an Existing Repository to Your Local Machine.
Instead of creating a new project from scratch, you can copy (or “clone”) an existing one using:

git clone <Your remote repository>
Enter fullscreen mode Exit fullscreen mode

For example:

git clone https://github.com/username/repository.git
Enter fullscreen mode Exit fullscreen mode

This command will

  • Downloads the entire repository
  • Sets up the remote connection (origin)
  • Automatically creates the project folder and checks out the default branch (usually main or master)

You do not need to run git init or git remote add if you use git clone. Git handles those steps for you.

5.) Check Status Check which files are staged, unstaged, or untracked

git status
Enter fullscreen mode Exit fullscreen mode

Example 1: No changes yet

This message appears when there are no files to commit.

Example 2: Untracked files detected

This message appears when there are untracked files (like main.py) that haven’t been staged yet.

6.) Stage Files Stage a specific file for commit

git add <filename>
Enter fullscreen mode Exit fullscreen mode 
git add main.py
git status
Enter fullscreen mode Exit fullscreen mode

After add file main.py you can check the result by git status, It will show file that have been add in green

Git will display the file status:

  • Files that have been added will appear in green (e.g., main.py)
  • Files not added will appear in red (e.g., odd_even.py)

7.) Commit Changes (with Conventional Commit Best Practices)
A commit in Git is like saving your progress. But rather than just saving for yourself, your commit messages should help your future self and teammates understand what changed and why.

Use this command to save staged changes with a meaningful message:

git commit -m "Your message here"
Enter fullscreen mode Exit fullscreen mode

Why Use Conventional Commits?
To keep commit history clean and understandable, developers often use the Conventional Commits format. It’s a standard that makes it easier to:

  • Scan change history
  • Automate release notes
  • Trigger CI/CD workflows

Commit Message Format

<type>(optional-scope): <short description>
Enter fullscreen mode Exit fullscreen mode
  • type — the kind of change you're making
  • scope — the part of the codebase affected (optional)
  • description — a short summary of the change

Common Commit Types

  • feat Adds a new feature
  • fix Fixes a bug
  • docs Documentation changes
  • style Code style changes (formatting, spacing)
  • refactor Code restructuring that doesn’t change behavior
  • test Add/update tests
  • chore Maintenance tasks (e.g., configs, builds)

Real-World Commit Examples
Here are new examples tailored for practical situations:

feat(auth): enable two-factor authentication for users
Enter fullscreen mode Exit fullscreen mode

Adds a new security feature to the authentication module.

fix(cart): resolve NaN price issue on quantity update
Enter fullscreen mode Exit fullscreen mode

Fixes a bug in the cart that caused price to display incorrectly.

docs(readme): add instructions for local setup
Enter fullscreen mode Exit fullscreen mode

Updates the README with setup instructions for contributors.

refactor(payment): simplify payment handler logic
Enter fullscreen mode Exit fullscreen mode

Refactors the payment module for readability, without changing functionality.

style(ui): apply consistent spacing in form layout
Enter fullscreen mode Exit fullscreen mode

Makes CSS/layout changes for visual consistency.

test(api): add tests for GET /products endpoint
Enter fullscreen mode Exit fullscreen mode

Adds automated tests for the product listing API.

chore(deps): upgrade dependencies to latest minor versions
Enter fullscreen mode Exit fullscreen mode

Maintains project health by updating third-party libraries

In our case in file main I have this code
print("Hello, World!")

git commit -m "feat(main): add initial Hello World script"
Enter fullscreen mode Exit fullscreen mode

6.) git push Upload commits to a remote repository
Syntax

git push -u <remote> <branch>
Enter fullscreen mode Exit fullscreen mode

We’ve just made a few commits to our main branch. To push them to GitHub:

git push -u origin main
Enter fullscreen mode Exit fullscreen mode

This command tells Git: “Take the commits I’ve made locally on the main branch and upload them to the origin remote repository.”

7.) git merge Combine Changes from Another Branch.
When you're working on a feature or bugfix in a separate branch (e.g., feature/login), you eventually want to merge that work back into the main branch.
This is done using:

git merge <branch-name>
Enter fullscreen mode Exit fullscreen mode

Example Workflow:

# Switch to main branch
git checkout main

# Merge changes from feature branch
git merge feature/login
Enter fullscreen mode Exit fullscreen mode

What this does:

  • Combines the commit history from feature/login into main
  • If there are no conflicts, the changes are merged automatically
  • If there are conflicts, you must resolve them manually before committing the merge

Merge Request – Team Review Before Merging
When using platforms like GitHub or GitLab, you typically don’t run git merge manually to merge into the main branch. Instead, you:

  • Push your changes to a feature branch
  • Open a Pull Request (PR) on GitHub — or Merge Request on GitLab
  • Request review/approval from your teammates
  • Merge via the web interface (once approved)

This process allows code to be reviewed, tested, and discussed before it's merged into the main branch.

Example Flow (Team Collaboration)

# Start a new feature branch
git checkout -b feature/navbar

# Make changes and commit
git add .
git commit -m "feat(navbar): implement responsive header"

# Push the branch to GitHub
git push -u origin feature/navbar
Enter fullscreen mode Exit fullscreen mode

Then you go to GitHub:

  • Open a Pull Request from feature/navbar into main
  • Assign reviewers or let teammates comment
  • Once approved, click “Merge” on GitHub

This is safer, more transparent, and often required in professional environments.

This has been featured in our blog. Feel free to check it out!

Coming up next:
• Git Basic Usage – expands on what we've covered so far
• Git-Merge – a deeper look into branching and collaboration

Top comments (0)