Skip to main contentHomepage

The Git Commands You'll Ever Need

Written by
Published on
The Git Commands You'll Ever Need


Ever feel like you're wrestling with Git more than actually coding? Let's change that.

After contributing to many big open source projects and using git in my daily life I have been using following git commands and these commands have been my go-to tools, streamlining my development process wherever I go. Let’s dive into the Git commands you’ll ever need to boost your productivity and efficiency.

Read this post in dark mode :P


Cloning a repository means downloading a copy of the repository to your local machine. It's like saving a copy of a book to read and edit. But unlike our usual copy and paste actions, all copies can be traced back to the original copy where it was copied from. We usually call the original ones upstream and our forked clones origin.

git clone <repository-url>


Adding means selecting which changes you want to include in your next "snapshot" (commit). It's like putting the photos you want in an album.

  • Add specific file to the staging area
git add <file-path>
  • Add all the changed files to the staging area
git add -A
git add .

The difference between using git add -A and git add . is that the first command stages all changes in the working directory, including new, modified, and deleted files. And the later one stages new and modified files within the current directory and subdirectories but does not stage deletions.


Committing means saving a snapshot of your project at a specific point in time. Think of it as taking a picture of your project. It is used to create a snapshot of the staged changes along a timeline of a Git projects history.

git commit -m "your commit message"

The output will look something like:

[master 3ea2dcf] your commit message
 1 file changed, 1 insertion(+), 1 deletion(-)
  1. To directly stage and make commit use git commit -am "your commit message".

  2. The --amend option allows you to change your last commit. Let’s say you just committed and you made a mistake in your commit log message. You can conveniently modify the most recent commit using git commit --amend -m "your updated commit message".

  3. If you forget to include a file in the commit, then you don't need to change the commit message just use the --no-edit option:

git add <missed-file>
git commit --amend --no-edit


Pushing means sending your commits from your local machine to the remote repository (like GitLab or GitHub). It's like uploading your updated photo album to a cloud service.

git push
  1. If it's a new branch that only exists in your local and not on origin or upstream then use have to use this command once git push --set-upstream origin <new-branch>. Afterwards you can just use git push.

if you don't want to do this everytime and instead just use git push then you have to update your git config with git config --global push.autoSetupRemote true.


Let's say you clone your fork repository and the upstream repository changed and you want to sync your repository on origin as well as locally. How do you that?

It's simple. This is my personal favorite.

In order to pull the changes from the original repository into your forked version, you need to add the original git repo as an upstream repository. For that first we need to undrstand remote. Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. You can read more about it here.

Check remote

git remote -v

you will see output like bwlow and notice that there is no original repository just the origin which is pointing to your fork:

origin[Your UserName]/[Your Fork].git (fetch)
origin[Your UserName]/[Your Fork].git (push)

Add upstream to your remote

git remote add upstream[Original Owner]/[Repository].git

If you run the git remote command again, you will now see both origin and upstream are configured

git remote -v
origin[Your UserName]/[Your Fork].git (fetch)
origin[Your UserName]/[Your Fork].git (push)
upstream[Original Owner]/[Repository].git (fetch)
upstream[Original Owner]/[Repository].git (push)

Fetch original repository

git fetch upstream
remote: Counting objects: 75, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62 (delta 27), reused 44 (delta 9)
Unpacking objects: 100% (62/62), done.
* [new branch]      master     -> upstream/master

Note that commits to the original repository will be stored in a local branch called, upstream/master

Merge original repository to your fork

a. make sure that you are on your fork’s master branch.

git checkout master

b. merge the changes from the upstream/master into your local master branch. This will synchronize your fork's master branch with the upstream repository without losing your local changes. If there are any conflicts due to your changes, you'll need to resolve them before completing the merge.

git merge upstream/master
Updating a422352..5fdff0f

Push your changes

git push origin master


With the following 5 commands you can sync your forked repository with the original repository and push the changes.

git remote add upstream[Original Owner]/[Repository].git
git fetch upstream
git checkout master
git merge upstream/master
git push


Git rebase is a command that allows you to integrate changes from one branch into another. It works by moving or combining a sequence of commits to a new base commit. This is especially useful for keeping a clean project history.

  1. Imagine you’re working on a new feature in a branch called feature-branch, and while you’re working, the main branch gets updated with new commits. You want to incorporate these updates into your feature-branch.
git checkout feature-branch
git rebase master
  1. If you have n number of commits on your branch and you want to squash those commits into single for keeping git history clean, you can do rebase interactive:
git rebase -i HEAD~n

Rebasing interactively means editing your commit history to make it cleaner. It's like rearranging the pages of your photo album.


let's say your branch has total of 5 commits and you want to squash into 1. How would you do it?

Well for that we have to use rebase -i and select the commits we want to squash.

git rebase -i HEAD~5

you will see output like this:

pick cdd4b77 commit-message 1
pick 21429ec commit-message 2
pick 785ef0b commit-message 3
pick 794ea82 commit-message 4
pick acd4d61 commit-message 5

# Rebase 5f1fe21..acd4d61 onto 5f1fe21 (5 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the

now the top commit is the first commit and we want to squash all of them into one, to do that change pick to s except the first one, like this:

pick cdd4b77 commit-message 1
s 21429ec commit-message 2
s 785ef0b commit-message 3
s 794ea82 commit-message 4
s acd4d61 commit-message 5

# Rebase 5f1fe21..acd4d61 onto 5f1fe21 (5 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the

save it and then a new popup window will open with commit messages where you can simply delete the commit messages and just keep one.

finally run:

git push --force-with-lease


Git will not let you delete the branch you are currently on so you must make sure to checkout a branch that you are NOT deleting.

git branch -d <branch-name>

The -D flag, with a capital D (which is an alias for -- delete --force), forcefully deletes the local branch, regradless of its merged status.

git branch -D <branch-name>
  • you can also delete remote branch by using git push origin -d remote_branch_name


Resetting means undoing changes in your project. Soft reset keeps your changes, while hard reset removes them. It's like using an eraser to either lightly or completely remove writing.

git reset --soft HEAD~n
git reset --hard HEAD~n
  • git reset --soft: The --soft aims to change the HEAD (where the last commit is in your local machine) reference to a specific commit.
  • git reset --hard: This option has the potential of being dangerous. So, be cautious when using it. Basically, when using the hard reset on a specific commit, it forces the HEAD to get back to that commit and deletes everything else after that.

Use git reset soft if you want to purge your commit history but keep your index and filesystem unchanged.

Use git reset hard if you want to clear the index and revert all tracked files to their state at the reset commit.

If you have any questions or need further guidance on using Git, feel free to ask in the comments below. And don't forget to subscribe to my newsletter for more tips and tricks on becoming a better software engineer. Happy coding!

Edit on GitHub
Last updated: --/--/----