10 Git Commands Every Developer Should Know

Git is the de facto standard for version control today. As a full-stack developer, you likely use Git every day to track changes, collaborate with teammates, and manage releases. A solid understanding of core Git concepts and commands is an essential skill for any professional programmer.

Consider these statistics:

• 77% of software professionals use Git as their primary version control system (VCS). The next most popular VCS, Subversion, lags far behind at 16%.[^1]
• There are over 200 million repositories on GitHub, the leading Git hosting service.[^2] Many of the world‘s most important open source projects are hosted there.
• 73% of professional developers use Git for work on their main project.[^3] Among full-stack developers specifically, that figure rises to 86%.[^4]

In other words, Git is ubiquitous in the software world. If you plan to collaborate with other developers, contribute to open source, or work on a team, you need to know your way around Git.

Fortunately, you can accomplish the vast majority of everyday version control tasks with just a handful of Git commands. Here are the top 10 commands every developer should know, along with examples and pro tips based on my experience as a full-stack developer.

1. git clone

Every new project starts with the git clone command. clone allows you to copy an existing Git repository to your local machine, creating an identical working copy:

git clone <repository-url>

Where <repository-url> is the URL of the repo you want to copy. This is typically a remote URL pointing to a central repo hosted on a service like GitHub, GitLab, or Bitbucket. But it could also be a file path pointing to another local repository.

For example, to clone the official React repository from GitHub:

git clone https://github.com/facebook/react.git

This will create a new directory called react containing the entire history of the React codebase, ready for you to start working with.

Pro tip: Use the --depth flag to do a shallow clone, which only retrieves the most recent commits instead of the entire project history. This can significantly speed up cloning large repositories:

git clone --depth 1 https://github.com/facebook/react.git

2. git branch

Git repos use branches to manage simultaneous streams of development. Branches allow teams to work on multiple features concurrently without stepping on each other‘s toes. The git branch command is your interface for creating and managing branches.

To create a new branch:

git branch <branch-name>

To list your local branches:

git branch

The current branch is marked with an asterisk (*).

To delete a branch:

git branch -d <branch-name>

Note: You cannot delete a branch that you currently have checked out.

Pro tip: Use a consistent naming convention for your branches. I recommend <issue-number>-<short-description>, e.g. 147-fix-login-bug. This makes it easy to identify what each branch is for.

3. git checkout

To actually start working on a branch, you need to "check out" that branch using git checkout. This makes the target branch your current working branch:

git checkout <branch-name>

You can also use checkout to create a new branch and switch to it in one step:

git checkout -b <new-branch-name>

This is a convenient shortcut for:

git branch <new-branch-name>
git checkout <new-branch-name>

Warning: git checkout replaces the files in your working directory with the versions from the target branch. Any uncommitted changes will be lost. Always commit or stash your changes before switching branches!

4. git status

As you work, it‘s helpful to see a summary of your repository status. git status shows you:

• The current branch
• Whether the branch is up to date with its remote counterpart
• Which files have changed since the last commit
• Which files are staged for the next commit
• Any files Git isn‘t tracking

Get in the habit of running git status before and after doing other Git operations to verify the results are what you expect.

Pro tip: Use the -s flag for a more concise output. This is handy when you have a lot of changes and just want the highlights:

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

5. git add

git add moves files from your working directory to the Git staging area. This allows you to selectively choose which files to include in your next commit.

To stage a specific file:

git add <file-path>

To stage multiple files:

git add <file-1> <file-2> <file-3>

To stage all changed files:

git add .

Pro tip: Use the -p flag to interactively stage portions of changed files, known as "hunks". This is useful when you‘ve made multiple unrelated changes to a file but only want to commit some of them:

$ git add -p
diff --git a/README b/README
index 9dacfe9..0adc581 100644
--- a/README
+++ b/README
@@ -1 +1,2 @@
-# test
\ No newline at end of file
+# test
+This is a test.
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? y

6. git commit

After staging your changes, use git commit to permanently record them in your repository. Each commit represents a snapshot of your codebase at a particular point in time.

Always include a short but descriptive message with each commit summarizing the changes. Aim to complete the sentence, "This commit will…":

git commit -m "Fix login error due to expired auth token"

Pro tip: For complex commits, open a full-screen editor to write a longer commit message using the git commit command without the -m flag. This allows you to provide more context and format the message using Markdown.

A good commit message looks like:

Summarize changes in 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72 
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here‘s the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too
 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

7. git push

To share your commits with your team, you need to push your local branch to the central repository:

git push <remote> <branch>

Where:

• <remote> is an alias pointing to the remote repository URL. By default this is called origin.
• <branch> is the name of the branch to push. If omitted, it defaults to the current branch.

For example, to push the main branch to the origin remote:

git push origin main

Note: If the branch has never been pushed before, you‘ll need to set the "upstream" branch that your local branch will track:

git push -u origin <branch>

Future pushes will only require git push.

Pro tip: To avoid accidentally pushing sensitive files like config files or build artifacts, add a .gitignore file to your repo specifying files and directories that Git should ignore:

# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so

# Packages #
############
# it‘s better to unpack these files and commit the raw source
# git has its own built in compression methods
*.7z
*.dmg
*.gz
*.iso
*.jar
*.rar
*.tar
*.zip

8. git pull

To incorporate changes made by other team members into your local working copy, use git pull:

git pull <remote> <branch>

This fetches the latest changes from the specified remote branch and merges them into your current working branch.

Warning: If you have any uncommitted changes that conflict with incoming changes, Git will refuse to merge until you resolve the conflicts.

Pro tip: Use git pull --rebase to rebase your local changes on top of the remote changes instead of creating a merge commit. This keeps a cleaner, more linear history:

git config --global pull.rebase true  # make --rebase the default
git pull

9. git merge

When a feature branch is complete and has passed code review, it‘s time to integrate it into the main branch. This is done using git merge.

First, check out the branch you want to merge into (e.g. main):

git checkout main

Then merge the feature branch:

git merge <feature-branch>

Git will combine the changes from both branches intelligently. If there are no conflicts, it will create a new merge commit on the main branch.

Pro tip: For important merges like a release or merging to main, use the --no-ff flag to force a merge commit even if Git could do a "fast-forward" merge. This documents that a feature branch was merged in:

git merge --no-ff <feature-branch>

10. git stash

Sometimes you need to quickly switch contexts without committing half-done work. This is where git stash comes in handy.

To save your current changes to a new stash:

git stash push -m "Implement new header design"

This resets your working directory to the last commit, but safely stores your changes for later.

To view a list of stashed changes:

git stash list  

stash@{0}: On main: Implement new header design
stash@{1}: WIP on main: 5002d47 Merge branch ‘add-widget‘
stash@{2}: On main: Fix tests

To re-apply your most recently stashed changes:

git stash pop

This applies the stash and removes it from the stack.

To apply a specific stash (e.g. stash@{2}):

git stash apply stash@{2}

Pro tip: By default, git stash only stashes changes to tracked files. To also stash untracked and ignored files:

git stash push --include-untracked

If you take away nothing else from this guide, remember:

1. Commit early and often. Frequent commits make it easier to understand changes and roll back if needed.
2. Write descriptive commit messages. Your teammates (and your future self) will thank you.
3. Embrace branches. Branches are lightweight and let you experiment without fear of breaking things.
4. Contribute code via pull requests. This enables your code to be reviewed before merging into main.
5. Communicate with your team. Good commit messages, comments on pull requests, and discussions on Slack or Teams complement your code. Never assume your code is self-explanatory.

Mastering these 10 commands will enable you to handle the vast majority of situations you encounter as a developer. They lay the foundation for collaborating effectively with your team and contributing to open source projects.

That said, we‘ve barely scratched the surface of what Git can do. Other powerful commands worth exploring include rebase, cherry-pick, bisect, reflog, and worktree. Learning the ins-and-outs of Git is a lifelong journey for any developer.

For more in-depth tutorials and workflows with Git, check out these resources:

• Pro Git Book – The definitive reference by Scott Chacon and Ben Straub
• Flight rules for Git – A guide for what to do when things go wrong
• Atlassian Git Tutorials – A collection of Git tips, tricks, and best practices

Here‘s to clean commits and successful merges! Let me know your favorite Git commands in the comments.

[^1]: Source: Stack Overflow Developer Survey 2018
[^2]: Source: GitHub About Page
[^3]: Source: JetBrains Developer Ecosystem 2020
[^4]: Source: State of Frontend 2020