Basic Git Commands to Get You Started

The essential Git commands every beginner needs are git init, git add, git commit, git status, git log, git branch, git checkout, and git merge. With these eight commands, you can create a repository, track changes, record snapshots, and collaborate on a project. This article explains each command, how they fit together, and the common pitfalls to avoid.

What Is Git and Why Use It?

Git is a distributed version control system created by Linus Torvalds in 2005 to manage the Linux kernel development. Unlike older centralized systems, every developer has a full copy of the repository history on their own machine. This makes Git fast, offline-friendly, and resilient to server failures.

Version control lets you:

• Track every change to your files over time.
• Revert to a previous state if something breaks.
• Work on multiple features in parallel using branches.
• Collaborate with others without overwriting each other’s work.

Git is the most widely used version control system today, powering platforms like GitHub, GitLab, and Bitbucket. Learning the basic commands is the first step to using any of these services effectively.

Setting Up Git

Before you start, install Git from the official website or your package manager. On Windows, the installer includes Git Bash, a terminal that emulates Unix commands. On macOS, Git comes with Xcode Command Line Tools, and on Linux you can use apt, dnf, or pacman.

After installation, configure your identity. Git attaches your name and email to every commit, and this information is required for commits to work:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

You can check your configuration with git config --list. The --global flag applies the setting to all repositories on your machine. If you work on different projects with different identities, omit --global and set them per repository.

Creating a Repository and Making Your First Commit

A repository (or “repo”) is the folder where Git tracks your files. To turn an existing directory into a Git repository, navigate into it and run:

git init

This creates a hidden .git folder that stores all the version history. Now you can start tracking files.

The typical workflow for saving a snapshot is:

1. Check the status: git status shows which files are untracked, modified, or staged.
2. Stage changes: git add <file> adds a specific file to the staging area. Use git add . to stage all changes in the current directory.
3. Commit the snapshot: git commit -m "Your message" records the staged changes with a descriptive message.

For example, if you create a file called hello.txt, you would run:

git add hello.txt
git commit -m "Add hello.txt"

The commit message should explain why you made the change, not just what changed. A good message helps your future self and your teammates understand the history.

Inspecting History and Differences

To see the list of commits in reverse chronological order, use:

git log

This shows the commit hash (a long hexadecimal string), author, date, and message. Add --oneline for a compact view: git log --oneline.

To see what changed in a specific commit, use git show <hash>. To compare the working directory to the last commit, use git diff. To compare two commits, use git diff <hash1> <hash2>.

These commands are essential for reviewing your own work and for understanding what your teammates have done before merging their changes.

Working with Branches

Branches allow you to develop features or fix bugs in isolation. The default branch is usually called main (or master in older repositories). To list all branches, run:

git branch

To create a new branch and switch to it in one step:

git checkout -b new-feature

Alternatively, you can separate the steps: git branch new-feature creates the branch, and git checkout new-feature switches to it. Newer versions of Git also support git switch for switching branches.

Once you’re on a branch, any commits you make will only affect that branch. This lets you experiment without breaking the stable main branch. When your feature is complete, you can merge it back:

git checkout main
git merge new-feature

Merging integrates the changes from new-feature into main. If both branches modified the same lines of code, you may get a merge conflict, which you’ll need to resolve manually.

Common Mistakes and How to Fix Them

Beginners often run into a few predictable issues:

• Committing without staging: If you forget git add, the commit won’t include your changes. Check git status to see what’s staged.
• Accidentally committing the wrong file: Use git reset HEAD <file> to unstage a file, then re-add the correct one.
• Writing a vague commit message: “fix stuff” is not helpful. Describe the change and the reason.
• Merging too early: Always test your branch before merging into main. Use a pull request or code review if you’re collaborating.
• Forgetting to pull before pushing: When collaborating, run git pull before git push to avoid rejected pushes.

If you make a commit and realize you forgot a file, you can amend the last commit with git commit --amend. This rewrites the commit message and includes any staged changes. Be careful: amending changes the commit hash, so it’s safe only if you haven’t pushed that commit yet.

Connecting to Remote Repositories

To collaborate with others, you need a remote repository hosted on a service like GitHub. To connect your local repo to a remote, use:

git remote add origin https://github.com/username/repo.git

Then push your local branch to the remote:

git push -u origin main

The -u flag sets the upstream, so future pushes can be done with just git push. To get changes from the remote, use git pull (which fetches and merges) or git fetch (which only downloads, without merging).

To clone an existing repository, use git clone <url>. This creates a local copy with the full history and sets up the remote automatically.

Frequently Asked Questions

What is the difference between git pull and git fetch?

git fetch downloads the latest changes from the remote to your local repository but does not modify your working files. git pull does a fetch followed by a merge (or rebase, depending on your configuration), so it updates your working directory immediately. Use git fetch when you want to review changes before integrating them.

How do I undo a commit?

If you haven’t pushed the commit, you can reset your branch to the previous commit with git reset --soft HEAD~1 (keeps changes staged) or git reset --hard HEAD~1 (discards changes). If you already pushed, avoid rewriting history; instead, create a new commit that reverts the changes using git revert <hash>.

What is a merge conflict and how do I resolve it?

A merge conflict occurs when two branches modify the same line of a file differently. Git marks the file with conflict markers (<<<<<<<, =======, >>>>>>>). You must edit the file to choose the correct content, remove the markers, then git add the file and commit the merge.

Do I need to use a GUI or can I stick with the terminal?

Both are valid. The terminal gives you full control and works on any system, while GUIs like GitHub Desktop or Visual Studio Code’s integrated tools can be more approachable for visual learners. Regardless of the interface, understanding the underlying commands helps you troubleshoot and use advanced features.

How do I ignore files like .env or build artifacts?

Create a file named .gitignore in the repository root. Each line specifies a pattern to exclude, for example .env or node_modules/. Commit the .gitignore file so the rules apply to everyone.

What is the difference between git commit and git push?

git commit records a snapshot locally on your machine. git push uploads those local commits to a remote repository. You can commit many times without pushing, and you can push only when you’re ready to share your work.

Related

• Upload Blueprints to a Satisfactory Dedicated Server
• Stop Zoom Bombers: Prevent Jerks From Ruining Calls
• Recover Hard Disk Partition: Full Guide