what is git and how its work?

  • Git is the most commonly used version control system.
  • Git tracks the changes you make to files, so you have a record of what has been done, and you can revert to specific versions should you ever need to.
  • Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source.

Feature of git

  • Control System: This basically means that Git is a content tracker. So Git can be used to store content — it is mostly used to store code due to the other features it provides.
  • Version Control System: The code which is stored in Git keeps changing as more code is added. Also, many developers can add code in parallel. So Version Control System helps in handling this by maintaining a history of what changes have happened. Also, Git provides features like branches and merges, which I will be covering later.
  • Distributed Version Control System: Git has a remote repository which is stored in a server and a local repository which is stored in the computer of each developer. This means that the code is not just stored in a central server, but the full copy of the code is present in all the developers’ computers. Git is a Distributed Version Control System since the code is present in every developer’s computer.

lets see the basic git commands that we need for our day to day life :

Configuration — Setting your Git username for every repository on your computer

  • git config -global user.name “Firstname lastname”
  • git config -global user.email “valid email id”
  • git config -global color.ui auto

Git basics commands

  • git init -turns a directory into an empty git repository
  • git add -adds file to the staging area ( Before a file is available to commit to a repo the file
    needs to be added to the git index i.e. staging area)
  • git commit -m “<commit message” — records the changes made to the files in a local repository
    (each commit has a unique ref id i.e. the commit hash(SHA1))
  • git status — returns the current state of the repository
  • git diff — difference of what is changed but not staged
  • git diff — staged — diff of what is staged but not yet commited.

Branching commands

Branch is created to work on a new feature. Every branch is pointed to the latest commit
Branch is referenced by HEAD

  • git branch <branch name> — creates a new branch
  • git checkout <branch name> — switches to another branch
  • git checkout -b <branch name> — ceates a branch and switches to it
  • git branch — Lists branches
  • git branch -d <branch name> — deletes a branch
  • git branch -a — lists local branches as well as remote
  • git branch -r — lists all remote branches
  • git branch -vv — lists tracking branches
  • git merge <branch> -merge the specified branch to the current one


  • git log — lists all commits in current branch’s history
  • git ls-files -s — lists all the files in staging area
  • ls -ltr — lists all file in a directory
  • ls -lart -lists all files in a directory including hidden
  • git show — display the recent commit

Tags — Git Tags are static text pointers to specific commit

  • git tag v1.0.0 — creates a lightweight tag v1.0.0
  • git tag -a v1.0.0 -m “Tag message” — creates an annotated tag v1.0.0
  • git tag — lists tags


  • git remote add origin URL — connects remote repo to local repo
  • git clone URL — creates a local working copy of an existing remote repository
  • git remote — list of remote git servers
  • git remote -v — it also displays the fetch and push URL
  • git remote show origin — detail information about local repository and remote repository
  • git fetch — fetch all the branches from the Git Remote Repo
    (doesn’t update your local working directory)
  • git merge — merge the specified branch to the current branch
    (merges the changes of your local git repo toyou local working directory)
  • git pull — fetch and merge commits from the tracking remote branch
  • git push — transmit local branch commits to the remote repository branch
  • git push origin -u <new branch> — pushing a branch to the remote repo

Rewrite history

  • git reset — hard <commit> — clear staging area, rewrite working tree from specified commit
  • git rebase — merges two or more branches together and rewrites history

Temporary Commits

git stash — save modified and staged changes
git stash list — list stashed files
git stash pop — brings changes back to staging area
git stash drop — discard changes from stash stack

Git log options

  • git log — displays complete information about all commits on the branch
  • git log — oneline — one line view of git log
  • git lg — one line view of git log with date and author name
  • git log — graph — graph of the commits with detail information of commits
  • git log — stat — additional information about changed files
  • git log -p — displays the actual changes of the commits
  • git log -4 — displays latest 4 commits
  • git shortlog -displays list of commits performed by the a particular author in a sorted way
  • git shortlog -n -sort quantity of commits by author
  • git shortlog -n -s -list of authors and number of commits
  • git shortlog -n -s -e list of authors and number of commits and email

Rebasing (git rebase)

Used for merging two or more branches. Do not use it on public branches like master/release as it may be destructive as it rewrites history

Rebasing is a 2 step process

  1. Rebasing of feature branch on master branch
  2. Merging of feature branch on master branch (using fast forward merge and no commit will be created)

Pros : History becomes linear as it doesn’t keep history of all commits

Cons : Rewrites history

Reset (git reset)

It is destructive and it rewrites history. By default it performs reset with mixed options.

Revert (git revert)


It reverts specific commit and creates changes in that and creates a brand new commit.

Git reset Vs Git revert

Git Merge

Git merge will combine multiple sequences of commits into one unified history. In simple word git merge is used to combine two branches.

There are two main ways Git will merge:

Fast Forward

3-way merge

Fast Forward Merge

A fast-forward merge can occur when there is a linear path from the current branch tip to the target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast forward”) the current branch tip up to the target branch tip. This effectively combines the histories, since all of the commits reachable from the target branch are now available through the current one. For example, a fast forward merge of some-feature into master would look something like the following:

example of fast Forword merge ,

3-way merge

However, a fast-forward merge is not possible if the branches have diverged. When there is not a linear path to the target branch, Git has no choice but to combine them via a 3-way merge. 3-way merges use a dedicated commit to tie together the two histories.

example of 3-way merge ,

Merge conflict

If the two branches you’re trying to merge both changed the same part of the same file, Git won’t be able to figure out which version to use. When such a situation occurs, it stops right before the merge commit so that you can resolve the conflicts manually.

Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run git status:


After seeing a conflict, you can do two things:

  • Decide not to merge. The only clean-ups you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abort can be used for this.
  • Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit or git merge — continue to seal the deal. The latter command checks whether there is a (interrupted) merge in progress before calling git commit.

You can work through the conflict with a number of tools:

  • Use a mergetool. git mergetool to launch a graphical mergetool which will work you through the merge.
  • Look at the diffs. git diff will show a three-way diff, highlighting changes from both the HEAD and MERGE_HEAD versions.
  • Look at the diffs from each branch. git log --merge -p <path> will show diffs first for the HEAD version and then the MERGE_HEAD version.
  • Look at the originals. git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.

Github linkhttps://github.com/snehalhingane

Follow me on LinkedIn https://www.linkedin.com/in/snehal-b-hingane-a4b14217b/

Thanks for Reading!!!!!!!

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