The Startup
Published in

The Startup

Let’s Git Familiar — Part 2: Git Fundamentals 2

This story is the second part of a series on Git Version Control System Fundamentals. You can access to Part 1 of the series here.

In the last part, I tried to answer the questions “what is git version control ?” and “what it is for ?”. Besides those, I introduced basic and most commonly used git commands. In this part, I wanted to talk about more advance git commands and how to utilize them. Let’s begin.

We can start with the command that helps us getting the latest changes from the remote repository. We went over “git pull” command in the last part but I did not mention “git fetch” command. You can examine the changes on the remote repository with the fetch command before writing them onto your local repository with the pull command.

git fetch <remote_name> // gets all the branches from the remote git    // repositorygit fetch <remote_name> <branch_name> // gets the specific branch  // from the remote git repository

Example usage:

git fetch test_remote test_branch // gets the test_branch

We mentioned branches before but we did not talk about how to create or manage them. What is branches?

Let’s go to Atlassian website and see how they described branches.

Branching is a feature available in most modern version control systems. Branching in other VCS’s can be an expensive operation in both time and disk space. In Git, branches are a part of your everyday development process. Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug — no matter how big or how small — you spawn a new branch to encapsulate your changes. This makes it harder for unstable code to get merged into the main code base, and it gives you the chance to clean up your future’s history before merging it into the main branch.

You can access the full branching page here:

You can create branches using either of the two commands below.

git branch <branch_name> // Creates a new branch at local repository //with a specific name

After creating the branch with the git branch command, you need to manually switch the new branch with git checkout command to given branch name.

git checkout <branch_name> // Switches the specific branch

The second way to create a branch and switching to it can be done with a combination of those two commands.

git checkout -b <branch_name> // Creates a new branch at local repository with a specific name and switches to it.

Afterwards, you need to push the branch to the remote repository using git push.

You can list all the branches in your repository using;

git branch // Lists all the branchesgit branch -a // Lists all the remote branches

Let’s say you are done with a branch. You can delete the branch adding -d or -D at the and.

git branch -d <branch_name> // deletes the specific branchgit branch -D <branch_name> // force delete the specified branch, // // even if it has unmerged changes.

You can also rename the current branch.

git branch -m <new_branch_name> // Renames the current branch to the // specific branch name

Assume that you created a branch, made some changes and you want to persist those changes to the Master branch. There is an operation called branch merging. In order to show you its fancy explanation let me quote from Atlassian website. (You can find further information here:

Merging is Git’s way of putting a forked history back together again. The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.

Note that all of the commands presented below merge into the current branch. The current branch will be updated to reflect the merge, but the target branch will be completely unaffected. Again, this means that git merge is often used in conjunction with git checkout for selecting the current branch and git branch -d for deleting the obsolete target branch

Okay, we understand that merging branches means we integrate two separate branches into one, but how does it work? Let me show you with some basic examples.

Let’s assume that your team published an application to web. After some time, there have been some complaints that your web app has some bugs and the issue is assigned to you. What you need to do is to code a hotfix immediately. So, you should create a branch. Let’s say you name the branch with a tag, new-fix (git command: git checkout -b new-fix master) You worked on the bugs and write the code that fixes them. After some thrill testing, you commit your changes and your code is ready to be published to the production. Your production code is on the “Master” branch, and your hotfix is on “new-fix” branch and they are needed to be merged.

git checkout master // Switches the current branch to Master branchgit merge new-fix // Merges new-fix branch onto Master branch

And it is done. You successfully merged “new-fix” branch onto “Master” branch. Of course sometimes merging does not go as smooth as this one. There can be some changes on Master branch that your new branch does not have. These situations raise conflicts. When a conflict happens, you need to apply a Merge Conflict Resolution operation, meaning you need to select which changes to keep and which ones to discard with merge commit command.

Since we discussed branches, we ought to mention rebase command too. You can find detailed explanation here: In short terms, git rebase helps you change the base commit of the remote repository to a specific commit with the command below. (It sets the start point of the branching history)

git checkout feature // Switches the current branch to “feature” // 
// branch
git rebase master // Aligns the history of the Master branch with // // “feature” branch

There are three more commands that I want to mention that can manipulate the flow of commit sequences: Checkout, Reset and Revert commands. Let’s first begin with Checkout and Reset.

Let’s imagine a situation that you made some changes on Master branch and commit the changes. Both HEAD ref and Master ref pointers point on that commit, meaning that both last commit you have made and the last commit of the Master is the same one. (your last change) On the other hand, there is a previous commit that you want to go back to. You have two options. First is to use git checkout command. (Note: Usually checkout command is used to switch between branches as in git checkout <branch_name> but if you want to point the HEAD ref onto a previous commit in the current branch you can use git checkout <commit_name>.) The second option is to use reset command. git reset command points both HEAD and Master ref onto a specific commit. There is an image below to visualize the information.

You can get further information about git reset from

Another useful command is git revert. Let me again first quote the formal explanation of the command from Atlassian web site:

The git revert command can be considered an 'undo' type command, however, it is not a traditional undo operation. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration.

Reverting should be used when you want to apply the inverse of a commit from your project history. This can be useful, for example, if you’re tracking down a bug and find that it was introduced by a single commit. Instead of manually going in, fixing it, and committing a new snapshot, you can use git revert command to automatically do all of this for you.

Unlike git checkout (with a commit_Id not with a branch name)and git reset the undo action been made with git revert does not change the location of the ref pointers. The revert operation takes a commit and inverses the changes that commit brings. That operation creates a new inversed commit (reverted commit) and like a regular commit creation, the HEAD ref points to the newly created commit.

git revert HEAD // inverses the changes from the last commit

A figure of branches is shown below to describe the states before and after git revert command.

Before I end my article, I wanted to mention one last git command. Git or any other version control system is used for keeping the changes of your records and one useful thing is to get the logs about those changes. You can use git log command to see the history of your repository. For example; after the revert commit if you use git log command to see the changes have been made onto the branch, you will notice the line: <commit_id> revert “commit description”.

There are still many git commands like git show, git reflow etc. but I wanted to mention commonly used ones since the article is too long as it is. So if you want to learn more about git commands, I encourage you to check them out.

I will introduce git workflows to you and give some real world examples to best utilize the Git Version Control. Stay healthy.




Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +756K followers.

Recommended from Medium

LDAP ขั้นตอนการติดตั้ง

Sage Franch: January STEM Star

Django and its default values

Picture of the book “Two scoops of Django 1.11”

GUI Container on Docker

O.J. Gillom hey you!!! I added you as editor too and changed it to we so see if you like it!!!

My First Ruby on Rails Project

Is ruby Arab? {Happy new year}

Java Lambda Expressions

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
İsmail GÖK

İsmail GÖK

Software Engineer

More from Medium

Share with those who care

Weather Observation Station 6 Solution

Contributing to a GitHub Repository

How to host your own WakaTime Server with CapRover and Wakapi