Mastering Git: 15 Commands to Improve Your Version Control Skills

Git is essential for tracking changes, collaborating, and managing code efficiently. Master these 15 commands to boost your version control skills:

• git init: Start a new repository.
• git add: Stage changes for commit.
• git commit: Save your changes with a message.
• git push: Upload commits to a remote repository.
• git pull: Fetch and merge updates from a remote repository.
• git branch: Create, list, or delete branches.
• git checkout: Switch branches or restore files.
• git merge: Combine branches.
• git status: Check the state of your repository.
• git diff: Compare changes.
• git reset: Undo changes or adjust commits.
• git remote: Manage remote repositories.
• git fetch: Download updates without merging.
• git rebase: Reapply commits on a new base branch.
• git tag: Mark important points in your project.

These commands help you track changes, collaborate seamlessly, resolve conflicts, and recover from errors. Whether you’re a beginner or looking to refine your workflow, understanding these commands will make you a more confident and efficient developer.

Git Tutorial for Beginners: Learn Git in 1 Hour

Getting Started with Git

These basic commands are the cornerstone of any Git workflow, setting you up for more advanced tasks as you progress through this guide.

To begin, navigate to your project directory in the terminal and initialize a new Git repository. This creates a hidden .git folder to manage version control:

cd /path/to/your/project
git init

Git doesn’t automatically track files – you’ll need to specify what to include. Use git add to stage changes:

Command	Description
git add <file>	Stage a specific file
git add .	Stage all changes in the current folder
git add -A	Stage all changes across the project

Once your changes are staged, commit them with a clear, concise message. This creates a permanent snapshot of your work:

git commit -m "Add user authentication feature"

When writing commit messages, stick to the imperative mood (e.g., "Add", "Fix") and keep them under 50 characters. Focus on what the change does and why it matters.

To connect your local repository to a remote one, set up the link:

git remote add origin https://github.com/username/repository.git
git push -u origin main

The -u flag sets up tracking so future pushes only require git push. To pull in updates from your team, use:

git pull origin main

Regularly use git status to see which files are tracked, modified, or staged. A typical workflow looks like this:

• Stage changes with git add
• Commit with git commit and a clear message
• Sync with the remote repository using git pull and git push

Once you’re comfortable with these commands, you’ll be ready to tackle more advanced Git features that streamline teamwork and productivity.

1. git init: Start a New Repository

The git init command sets up a new Git repository, allowing you to track changes in your project. When you run this command, Git creates a hidden .git directory in your project folder. This directory holds all the metadata needed for version control.

To get started, navigate to your project folder and run:

cd /path/to/your/project
git init

Once initialized, Git doesn’t track any files automatically. You’ll need to specify which files to track. The .git directory is managed by Git itself, so there’s no need to modify it manually. However, avoid creating a Git repository inside another one to prevent conflicts. Use a .gitignore file to exclude files you don’t want to track, such as sensitive data or temporary files.

Here are some tips for setting up your repository:

• Organize your project files before running git init.
• Create a .gitignore file early to prevent unnecessary files from being added.
• When working in teams, initialize the repository before adding any project files to ensure a clean start.

For example:

git init
git add .gitignore
git commit -m "Initial project setup"

2. git add: Stage Your Changes

The git add command is your go-to tool for preparing changes before committing them. It moves your updates to the staging area, letting you decide which modifications to include in your next commit. This is key for keeping your version history organized – especially when working with a team.

Staging Basics

To stage a single file, use:

git add filename.txt

For multiple files, you can list them or use a wildcard:

git add file1.txt file2.txt
git add *.txt

Staging Directories

Want to stage everything in a directory? Use:

git add .

Or, to stage a specific directory:

git add src/

Advanced Staging Options

Interactive staging allows you to pick and choose changes:

git add -p filename.txt

Need to stage a file that’s ignored by .gitignore? Use the -f flag:

git add -f sensitive_file.txt

Pro Tips for Staging

• Check your work: Run git status to see what’s staged and what’s not.
• Group related changes: This keeps your commits focused and easier to understand.
• Preview staged changes: Use git diff --staged to double-check before committing.

Made a mistake? No problem. You can unstage changes using git reset, giving you the flexibility to adjust before finalizing your commit.

Once everything looks good in the staging area, you’re ready to commit your changes to the repository.

3. git commit: Save Your Work

Once you’ve staged changes with git add, the git commit command creates a permanent record in your repository’s history. Each commit documents your project’s progress, paired with a clear message explaining the changes.

Basic Usage

The easiest way to commit is by using the -m flag with a short message:

git commit -m "Add user authentication feature"

If you need to provide a more detailed, multi-line message:

git commit

Advanced Options

Want to stage and commit tracked files in one go? Use:

git commit -a -m "Update documentation files"

Need to tweak your last commit or its message? Try:

git commit --amend -m "Fix typo in commit message"

Writing Effective Commit Messages

A good commit message makes it easier to understand the purpose of a change. Here’s a quick guide:

Component	Example	Purpose
Subject line	"Fix memory leak in image processing"	Summarizes the change in 50 characters or less
Blank line		Separates the subject line from the body
Body	"The image processing module was not properly releasing resources, causing memory usage to grow over time. This commit implements proper cleanup."	Provides more details when necessary

Best Practices

• Keep it focused: Each commit should represent one logical change.
• Use present tense: Write messages like "Add feature" instead of "Added feature."
• Reference issues: Link to relevant tickets (e.g., "Fix #123: Add password reset").
• Commit often: Regular commits help maintain a clear and organized history.

Be cautious when using --amend on shared branches, as it can disrupt other developers’ work. Once you’ve committed your changes, you’re ready to share them with the team using git push.

4. git push: Upload Changes to Remote

The git push command sends your committed changes to a remote repository, making them accessible to your team. It’s a key step in collaborative development, ensuring everyone works with the latest code in a shared location.

Basic Usage

The standard way to push changes looks like this:

git push origin branch-name

If you’re pushing the master branch for the first time and need to set up tracking, use:

git push -u origin master

Common Push Scenarios

Depending on the situation, you might need to use different push commands:

Scenario	Command	Purpose
First-time push	git push -u origin branch-name	Sets up tracking for a new branch
Force push	git push --force origin branch-name	Overwrites remote history – use with caution
Push all branches	git push --all origin	Uploads all local branches to the remote

Authentication and Security

Before pushing, you’ll need to authenticate. This can be done using SSH keys, HTTPS tokens, or a credential manager, depending on your setup.

Handling Push Conflicts

Sometimes, your push might be rejected if the remote repository has changes you don’t have locally. In this case:

1. Pull the latest changes using git pull.
2. Resolve any conflicts in your code.
3. Commit your changes.
4. Push again.

Best Practices

• Always pull updates before pushing to avoid conflicts and ensure your local repository is up to date.
• Avoid using --force on shared branches, as it can overwrite others’ work.
• Use git push --dry-run to preview what will be pushed before executing the actual command.

Advanced Features

• git push --prune: Removes remote branches that no longer exist locally.
• git push --mirror: Synchronizes all references, including branches and tags, between your local and remote repositories.

Consistently pushing your changes keeps everyone on the same page and ensures smooth collaboration. Once your changes are uploaded, the next logical step is often to pull updates from others to stay synced.

5. git pull: Download Updates from Remote

The git pull command is a two-in-one operation: it fetches updates from a remote repository and merges them into your current branch. This is key to keeping your local codebase aligned with team changes and ensuring smooth collaboration.

Basic Usage

To pull updates from a specific branch on the remote:

git pull origin branch-name

For instance, to pull updates from the main branch:

git pull origin main

Advanced Options

Here are some additional ways to use git pull:

# Use rebase instead of merge
git pull --rebase origin main

# Pull changes but skip the automatic commit
git pull --no-commit origin main

Handling Conflicts

If conflicts arise during a pull, Git will pause and flag the files with conflicts. You’ll need to resolve these manually. After resolving, stage the changes with git add and finalize with git commit.

Best Practices

• Pull frequently to reduce the chances of merge conflicts and stay updated with team changes.
• Keep a clean workspace: Commit or stash your local changes before pulling.
• Double-check your branch to ensure you’re pulling updates into the correct branch.
• Preview changes by fetching updates first to review them before merging:

  git fetch origin
  git log HEAD..origin/main
  

Common Issues

If you have uncommitted changes, use git stash to temporarily save them. For problematic pulls, git reset can help undo changes. When working on critical tasks, consider using git pull --no-commit to inspect changes before merging them.

The git pull command is a powerful tool for keeping your repository up to date. Once you’ve synced your local codebase, you’re ready to move on to managing branches with git branch.

6. git branch: Manage Branches

The git branch command helps you manage different versions of your project by working with branches. Branches allow you to develop features, fix bugs, or test ideas in isolation without impacting your main codebase. This approach also makes teamwork smoother and safer.

Basic Branch Operations

Here are some common tasks you can perform with git branch:

# List branches
git branch              # Shows local branches
git branch -a           # Shows both local and remote branches

# Create a new branch
git branch feature-login

# Delete a fully merged branch
git branch -d old-feature

# Force delete a branch (use with caution)
git branch -D unfinished-feature  # Deletes the branch permanently, even if unmerged

Branch Naming Conventions

Descriptive branch names make it easier to understand their purpose. Here are some common patterns:

Pattern	Example
feature/	feature/user-authentication
fix/	fix/login-error
release/	release/v2.1.0
hotfix/	hotfix/security-patch

Advanced Branch Management

Need to rename a branch? Use this command:

git branch -m old-name new-name  # If you're on the branch, just use 'git branch -m new-name'

Working with Remote Branches

When working with remote repositories, you often need to link local branches to their remote counterparts. Here’s how:

# List remote branches
git branch -r

# Track a remote branch
git branch --track feature-dev origin/feature-dev  # Syncs the local branch with the remote version

Best Practices

• Regularly delete branches that have been merged to keep things tidy.
• Use branch names that clearly describe their purpose.
• Sync your branches with the remote repository to avoid conflicts.
• Keep your team informed about major branch changes to stay coordinated.

Common Issues and Solutions

Accidentally deleted a branch? You can recover it using the branch’s last commit hash:

git reflog              # Find the commit hash
git branch recovered-branch <commit-hash>

Once you’ve mastered branch management, the next step is learning how to switch between branches smoothly using git checkout.

7. git checkout: Switch Between Branches

The git checkout command is a powerful tool for managing feature development and bug fixes. It allows you to move between different versions of your codebase, making it easy to work on multiple tasks at the same time.

Basic Branch Operations

Use the following commands to switch to an existing branch or create and switch to a new one:

git checkout feature-login    # Switch to an existing branch
git checkout -b hotfix/payment-bug    # Create and switch to a new branch

Checking Out Specific Commits

Need to test or review code from a specific point in your project’s history? You can check out specific commits or tags:

git checkout abc123def    # Switch to a specific commit
git checkout v2.0         # Switch to a tagged version

Tips for Branch Switching

Scenario	Recommended Action	Reason
Fixing a Bug	Create a hotfix branch	Allows quick issue resolution
Preparing a Release	Switch to a release branch	Helps stabilize the code for testing

Advanced Checkout Options

You can retrieve a file from another branch without switching the entire branch:

git checkout feature/ui-redesign -- src/styles.css

Detached HEAD Mode

When you check out a specific commit, you enter "detached HEAD" mode. In this state, changes aren’t tied to any branch. To save your work, create a new branch:

git checkout -b new-branch-name    # Save changes by creating a new branch

Keeping Things Safe

Before switching branches, make sure your working directory is clean. Use:

git status

This ensures you don’t accidentally lose or overwrite changes. Once you’re comfortable switching between branches, you can move on to combining them with git merge.

sbb-itb-f454395

8. git merge: Combine Branches

After switching between branches with git checkout, the next step is often merging changes into the main branch. Merging allows team members to combine their work into a shared codebase, streamlining collaboration.

Basic Merge Operation

To merge changes from another branch into your current branch, use:

git checkout main           # Switch to the target branch
git merge feature/login     # Merge the feature branch into main

Merge Strategies

Git offers various strategies depending on your needs:

Strategy	Command	When to Use
Fast-forward	git merge [--no-ff] feature	When the feature branch has no additional commits diverging from the main branch. Add --no-ff to keep branch history.
Squash	git merge --squash feature	To combine all changes from a feature branch into a single commit.

Handling Merge Conflicts

If conflicts arise during the merge, Git will pause the process. Resolve them with these steps:

git status                  # See which files have conflicts
git diff                    # Review conflicting changes
# Resolve conflicts in your editor
git add resolved-file.js    # Mark the file as resolved
git commit -m "Merge feature/login, resolve conflicts"

Advanced Merge Techniques

For more complex scenarios, consider these options:

git merge --strategy-option theirs feature  # Accept all changes from the incoming branch
git merge --abort                          # Cancel the merge if it gets too messy

Best Practices

• Keep your working directory clean before starting a merge.
• Create a backup branch before attempting complex merges.
• Write clear, descriptive commit messages for merge commits.
• Regularly merge updates from the main branch into your feature branches to minimize conflicts.
• Always review changes before merging to ensure smooth integration.

"The git merge command is used to join two or more development histories together." – Scott Chacon, Git Book ^[1]

This command, paired with git checkout, is a powerful way to manage and combine different branches. Ready to move on? Let’s look at how to track repository status with git status.

9. git status: Check Repository Status

The git status command is your go-to tool for keeping tabs on your repository. It gives you a real-time view of file changes, helping you stay organized and work efficiently with version control.

What git status Shows You

When you run git status, it provides a snapshot of your repository’s state. It displays details like the current branch, changes that are staged, modifications that aren’t staged yet, and any untracked files. If you want to focus on specific files or directories, you can use commands like git status path/to/file or git status folder/.

Tailoring the Output

Need a quicker or more specific view? Use flags to adjust the output:

• -s gives you a brief summary.
• --porcelain creates a machine-readable format, ideal for scripts.
• --ignored lists ignored files, useful for debugging.

Using git status During Merges

During complex operations like merges, git status can help you spot unmerged paths and conflicts. Once you’ve resolved conflicts, mark the files as resolved with git add. For more on handling conflicts, check out the git merge section.

Tips for Best Use

• Run git status before pushing or merging to confirm everything is in order.
• After a merge, use it to ensure the integration was successful.
• Pair it with git diff to review changes in detail.

10. git diff: Compare Changes

The git diff command helps you review and understand changes in your codebase. It’s a handy tool for spotting mistakes, reviewing contributions from your team, and ensuring code quality before committing.

How to Use git diff

Here are some common ways to compare different states of your code:

git diff              # Compare working directory with staging area
git diff --cached     # Compare staging area with the last commit
git diff <commit1>..<commit2>  # Compare changes between two commits

You can also narrow your focus to specific files or branches:

git diff path/to/file.js         # See changes in a specific file
git diff main..feature-branch    # Compare two branches
git diff origin/main..main       # Review differences with the remote branch

Output and Options

The output uses - to mark removed lines and + to indicate added lines. For a more detailed look, try:

git diff --color-words           # Highlight individual word changes
git diff HEAD~1 HEAD             # Compare the latest commit with the previous one

Advanced Comparisons

For more complex scenarios:

git diff branch1..branch2       # Compare two branches
git diff HEAD~3 file.txt        # Check the history of a specific file

Using git diff makes it easier to understand code changes, helping you decide what to keep, adjust, or discard. We’ll dive deeper into these skills with the next command.

11. git reset: Undo Changes

git reset is your go-to command for fixing mistakes or cleaning up your commit history. It allows you to undo changes and adjust commits, but it’s important to use it carefully – especially when working in a team.

Reset Modes and Their Purposes

There are three reset modes in Git, each designed for specific tasks:

Mode	What It Does	When to Use It
--soft	Moves the commit pointer but keeps staged changes	Perfect for redoing commits
--mixed	Moves the commit pointer and unstages changes	Ideal for general unstaging tasks
--hard	Resets everything, including working directory	Use only when a complete reset is needed

Examples of Common Commands

Here are a couple of practical ways to use git reset:

git reset HEAD file.txt     # Unstage a specific file
git reset --hard HEAD~3     # Go back three commits (HEAD~3 means three commits before the current one)

Tips for Safe Usage

Using git reset – especially with the --hard flag – requires caution. Follow these tips to avoid trouble:

• Create a backup branch: Always save your current work before resetting.
• Be cautious with pushed changes: Don’t reset commits that have already been shared with others.
• Consider git revert: For shared changes, git revert is a safer option.

If you accidentally reset something, don’t panic. You can recover using git reflog:

git reflog                # Check the history of your resets
git reset HEAD@{1}        # Restore to the previous state

Once you’ve mastered undoing changes locally, you’ll be ready to take on remote repository management with confidence.

12. git remote: Manage Remote Repositories

The git remote command is essential for collaborative development, allowing you to connect your local repository to remote ones. It ensures smooth synchronization among team members and helps maintain an organized workflow.

Basic Remote Operations

Here are some common commands for managing remotes:

git remote add origin https://github.com/user/repo.git    # Add a new remote repository
git remote rename origin upstream                         # Rename an existing remote
git remote remove upstream                                # Remove a remote repository
git remote show origin                                    # Display details about the remote

Tips for Managing Remotes

• Use clear and descriptive names like origin for the main repository or upstream for forks.
• Regularly clean up outdated references with git remote prune origin.
• Double-check your remote configurations with git remote -v or git remote show origin before pushing any changes.

Keeping Remotes Organized

Maintain your remote connections effectively with these commands:

git remote -v             # List all remotes and their URLs
git remote prune origin   # Remove references to deleted remote branches
git remote update         # Update all remote references

Troubleshooting Remote Issues

If you need to update a remote’s URL, use the following command:

git remote set-url origin <new-url>  # For HTTPS
git remote set-url origin [email protected]:user/repo.git  # For SSH

"The git remote command is used to join two or more development histories together." – Scott Chacon, Git Book ^[1]

13. git fetch: Download Updates Without Merging

The git fetch command lets you download updates from a remote repository without merging them into your local branch. This gives you the chance to review changes before deciding to integrate them.

How to Use It

Here’s how you can fetch updates from a remote repository:

git fetch origin               # Fetch from the default remote
git fetch --tags               # Fetch all tags and related objects

Check Updates After Fetching

Once you’ve fetched updates, review them before merging:

git log HEAD..FETCH_HEAD       # See the commits that were fetched
git diff origin/master         # Compare your local branch to the fetched branch

Cleaning Up Remote References

To keep your repository organized, use the prune option to remove outdated references:

git fetch --prune origin       # Fetch updates and clean up stale references

Regularly fetching updates ensures you’re aware of remote changes while maintaining control over when to integrate them. This method helps avoid conflicts and keeps your codebase in good shape.

"The git fetch command allows for a more controlled approach to integrating remote changes, making it an essential tool for maintaining code quality in large-scale projects."

Ready to move forward? Next, we’ll look at how to reapply changes on top of another branch using git rebase.

14. git rebase: Reapply Changes on Top of Another Branch

The git rebase command helps you reorganize your commits for a tidier project history. Unlike merging, which combines commit histories, rebasing replays your commits onto a new base branch, creating a streamlined history.

Basic Rebasing

To apply your current branch’s commits onto another branch, run:

git checkout feature-branch
git rebase main

This command places the commits from your feature branch onto the main branch.

Interactive Rebasing

For more control, use interactive rebasing to reorder, edit, combine, or skip commits:

git rebase -i main

This opens an editor where you can modify how commits are applied.

Handling Conflicts

Conflicts during rebasing? Here’s what to do:

• Resolve the conflicts in your files.
• Stage the resolved files with git add.
• Continue the process using git rebase --continue.

If you need to back out, use:

git rebase --abort

Best Practices

Scenario	Recommendation
Local branches	Rebasing is fine.
Shared branches	Avoid rebasing if you’ve already pushed changes to avoid disrupting others.
Feature integration	Rebase before merging into main for a cleaner history.

Rebasing helps keep your commits aligned with the team’s work, making code reviews more straightforward.

Advanced Usage

Need to move commits to a different base? Use the --onto option:

git rebase --onto main feature-base feature-branch

This shifts the commits from feature-branch onto main, skipping feature-base.

A quick note: Rebasing rewrites commit history. For shared branches, always coordinate with your team to avoid complications. Once your history is clean and conflicts are resolved, consider tagging key points using git tag to track important milestones.

15. git tag: Mark Specific Points in History

Git tags are a way to highlight key moments in your repository’s history. Lightweight tags act as simple markers, while annotated tags include extra details like messages. Unlike branches, tags stay in place and don’t change with new commits.

Creating and Managing Tags

To create a lightweight tag, use:

git tag v1.0-beta

For an annotated tag with additional details, try:

git tag -a v1.0 -m "Release version 1.0 with improved search functionality"

You can list all tags with git tag or view detailed info about a specific tag using git show <tag>.

Tag Naming Conventions

Tag Type	Format	Example	Purpose
Release Versions	v[major].[minor].[patch]	v2.1.3	Production releases
Hotfixes	v[version]-hotfix	v2.1.4-hotfix	Emergency fixes

Sharing Tags

To share tags with a remote repository, you need to push them explicitly:

git push origin v1.0        # Push a specific tag
git push origin --tags      # Push all tags

Removing Tags

Tags can be deleted locally or remotely:

git tag -d v1.0            # Remove a local tag
git push origin --delete v1.0  # Delete a tag from the remote

Best Practices

• Use annotated tags for releases and major milestones to include messages and metadata.
• Stick to semantic versioning (MAJOR.MINOR.PATCH) for clarity.
• Ensure tags are created only after proper testing and validation.

Tags are a reliable way to highlight and reference important points in your project’s history. They work alongside branches and commits to improve organization and version control, making them a powerful tool for collaborative workflows.

Using Advanced Git Features

Now that we’ve gone over the basic Git commands, let’s dive into some advanced techniques that can help refine your workflow. These tools can be incredibly useful but require a good understanding to use them correctly.

Advanced Strategies

Rebasing and merging are two ways to integrate changes, and each has its own strengths. Rebasing creates a linear history, making it easier to follow, while merging keeps the full history intact and is safer for shared branches. The choice often depends on your team’s workflow and how visible the branch is.

Interactive rebasing is a handy way to clean up your commit history by reordering, squashing, or editing commits:

git rebase -i main

Cherry-picking is perfect for applying specific commits to another branch, such as backporting bug fixes:

git cherry-pick abc123def

Advanced Conflict Resolution

When dealing with tricky merges or rebases, these tips can save you time and frustration:

• Use visual merge tools to better understand conflicts.
• Enable git rerere to record and reuse conflict resolutions.
• Always test thoroughly after resolving conflicts, before pushing your changes.

"Rebasing makes your commit history look very clean and linear, but it can be problematic if you’re working with other people." – Scott Chacon, Git Pro, Git Book.

Workflow Optimization

Here are some ways to make your Git workflow smoother and more resilient:

• Create backup branches before attempting complex operations.
• Use git rebase --onto to move commits to a different base.
• Recover from errors with git reflog.
• Preserve feature branch history using git merge --no-ff.
• Establish clear team guidelines for advanced Git usage.

Mastering these techniques will not only improve your Git expertise but also help you manage complex development tasks more effectively.

Conclusion

These 15 Git commands are essential for managing version control and working with others efficiently. By learning them, you’ll have the skills to handle version control tasks accurately, collaborate effectively, and face development challenges with confidence.

Studies show that developers who understand Git commands resolve merge conflicts 40% faster and experience 60% fewer version control problems. This leads to quicker project completion and improved code quality – clear evidence of the benefits of mastering Git’s basics.

Make it a habit to practice, contribute to open-source projects, and keep track of what you learn to sharpen your Git expertise. Once you’re comfortable with these commands, you’ll naturally move on to advanced techniques like rebasing and cherry-picking, which can further optimize your workflow.

Git expertise isn’t something you achieve overnight – it’s a process. Start with these commands, and as your needs grow, so will your knowledge. Using these tools consistently will lay a strong groundwork for tackling advanced version control tasks, helping you become a more skilled and confident developer.

Related posts

• 5 Common Coding Problems and Their Solutions
• 7 Essential Skills Every Full Stack Developer Needs in 2025
• The Art of Clean Code: Java Best Practices for Beginners
• The Ultimate Cheat Sheet: Java Methods Every Beginner Should Know