Why You Must Experience Git At Least Once In Your Lifetime.

Why You Must Experience Git At Least Once In Your Lifetime.

Why You Must Experience Git At Least Once In Your Lifetime.
Learn Git | Git Commands | Merge and Branch Concept | Start Contributing the Github Community

If you are struggling with git branch merge commit and many different git terminologies then you are in the right place.

All you need to spare 10 minutes for reading this article.

After 10 minutes I promise you that you will become an expert in git and start applying git in your personal project as well as in your current organization.

We will learn git by two-phase learning in the first phase we go through the definitions and in the second phase we go through our interesting part .i.e. hands-on part.

Let me know your valuable feedback in the comment section of each blog post.

Join our telegram channel and group :) 
Telegram Group: @randomskoolQnA 
Telegram Channel: @randomskool


1. What is Version Control System?
2. What is git?
3. How git is useful in our daily life?
4. Git Commands
5. Git Scenario
    5.1. Git Cherrypick
    5.2. Git Merge Conflict
6. Git Tools for GUI implementations
7. Additional Resources
8. Conclusion

What is Version Control System?

VCS or Version Control System is a methodology in which we maintain any changes in the files in which we are currently working on.

Suppose if you are working on a final semester project and you changed some part of the code but at some point in time, you are getting error. Now you decide back to the previous state but ctrl + Z ( for undoing ) will not for you at this point. And even you don't remember what are the changes you had done. That's where the versioning comes.

Versioning plays a vital role in simple as a well complex project.

Suppose if you are implementing some versioning tool, maintain the different versions of your code. Then the debugging process will be easier for you and moving between different states of code is a much simpler task. Integrity maintains in code.

What is git?

FounderLinus Torvalds
Git is a very popular distributed version control tool.
The most important git is an open-source tool.
Git includes all the features of the version control system.
It is used for tracking changes between code and working as a team is possible.

Features of Git:
1. We can achieve speed, code integrity using git.
2. Security of code is also taken care of by git.
3. Debugging is much simpler in git using git bisect.
4. Isolation of different features of code is possible using the branch concept in git.
5. Team collaboration is maintained in a remote repository.

Git Lifecycle:

1. Working directory: All the files present in the repository after the initialization of git are known as the working directory.

  • Tracked: Git aware of the changes 
  • Untracked: Git is not aware of the changes
2. Staging Area: Before commit all changes are present in staging area.

How git is useful in our daily life?

As we are aware that git is a distributed version control system in which tracking of changes is possible.
However, we use git in local as well as remote due to its distributed feature.
If we are working on a personal project we can create a local git repo in our personal computer and maintain all the versions in the local computer or we can upload the version in the remote directory.

Git can be useful for web developers, app developers, and anybody with some coding skills or with no coding skills. We can even maintain our writing documents versioned using git.
The usage of git has no limits it opens the wide range of opportunities.

Let me know in the comment section in which areas you guys using git?

Now we will begin the git commands section in which begin gradually by moving from initializing the repo to merge the branch.

git init:
In order to use git, we need to declare or initialize the top-level directory using the git init command. Therefore, it will create a hidden directory named .git which maintains all the states as well as contains the configuration file.

git init randomskool

git status: 
Once initialized using git init to know the status of  the working directory (tracked or untracked file) 

Nothing to commit means - all files are tracked ( git is aware of all the changes )

git status randomskool

Created a new file named as randomskool-file. 
As the file is newly created, git is not aware of the changes so it marked it as untracked.
If this file is useful and you want to make git aware or want to mark as tracked - then we use git add and move the file to the staging area.

git status randomskool

git add: 
If the file is relevant and wants to move the file from working to the staging area we have to use git add. 
However, git add has two variant:-
  • git add <file name>: want to add the specific file to the staging area.
  • git add. : want to add the whole file or folder to the staging area.
git add randomskool

git commit:
Once the file moved to the staging area, after that we need to commit the file to the repository using git commit -m <Message>. 
Using git commit, all the staging files move to the repository with record the author, timestamp which will help in debugging the files. 
Each commit generates a unique hash number for referring other commits.

  • If you want to change the commit message you can use --amend flag with commit.
    • git commit --amend -m " Changing the message " 

git commit randomskool

git ignore:
Sometimes we do not want to add particular types of files to git and to ignore those specific types of files we used git ignore file.
  • Use Case for git ignore file:
    • credentials
    • tmp file
    • logfile
    • and many more
Below is the screenshot for reference .gitignore in which we are ignoring credentials and logs file by mentioning those entries in the .gitignore file

git ignore randomskool

git ignore randomskool

Now if we checked again using git status those files will not be displayed in the untracked section only .gitignore file will be available.

git ignore randomskool

git diff:
  • At times when we want to compare the contents of different versions --- then at that time we can use git diff.
  • git diff is useful for comparison between the working area and head.
  • However, in order to use different difftool apart from the default one, we can use git difftool and configure global settings.
git diff randomskool

    •  git diff --staged: In order to compare the contents of the staging area and previous commit we can use git diff --staged

git log:
I must say git log is a far useful and important command in git because it allows viewing the history of all the previous commits in the chronological order ( the most recent commit appears first )

There are many variants of git log we can use as per our requirements:
  • git log --all ( to view all commit )
  • git log -<n> ( "n" denotes the number -- it helps to view the recent number of commits )
  • git log --author=<name> and git log --committer=<name> ( able to filter the log as per author name or committer name) 
  • git log --before <date> and git log --after <date> ( able to filter commit as per date not date range )
  • git log --before <date> --after <date> (able to filter commit as per date range)
  • git log -p ( it help to see the log of different diff between commits )
  • git log --stat ( it help to view the summary of commits )
  • git log --oneline ( it helps to view the log in oneline )
  • git log --graph ( it helps to view log in the graph) 
  • git log --pretty=format:"<options>" ( it helps to prettify the logs )
git show:
The basic difference between git log and git show is git log will display the history of commits by displaying their author name who committed the change and whereas git show will display the change of specific commit if no commit is specified it will show the changes of the HEAD commit.

git show <hash value of commit >
git show ( by default take the HEAD hash )
git remote:
If we are working as a team or going to work in a group school project, then at that time remote repository is more useful and sounds more technical.
As we all are aware git is based on the distributed version control system,  where either we can work locally or remotely.
In case we work remotely, then we can share our code with all the commit history deployed in a remote repository with others.
Remote Repository is like a shared folder where others can contribute (if you marked as public).

There are multiple websites which offering git or remote repository:

  • Github
  • GitLab
  • bitbucket
  • source-forge 
  • and many more...
Setup of the remote repository: 
  • Need to setup ssh keys 
Go to settings > Add SSH Key > Copy and Paste the generate keys
          Note: How to generate ssh key for GitHub (Read this)

  • After keys set-up, creates a new remote directory using below commands
git remote add origin git@github.com:talk2div/ZeroByteFileAutomation

    • git remote add denotes that we are about to create a new remote repository with name origin having URL specified after the remote name (origin)            
  • git remote -v  ( is used for URL listings in the local repo. )      

git clone:
git clone as a name implies of the command is used for replicating the contents of the remote repository.
Note: In git clone (origin remote is already set-up at the time of cloning the repository)

git clone https://github.com/talk2div/ZeroByteFileAutomation

git push:
git push is used to transfer local commits to the remote repository.
git push -u origin master
1. Push all the branches at one go -
git push origin --all 
 2. Forcefully push all the branches at one go -
git push origin master --force
git fetch:

  • Maintains the separate local branch in which all the updates of the remote repository are present.
  • Not affecting the current working branch
  • Useful for reviewing purpose ( by checkout into a separate branch if all seems good then merge into a working branch )

git merge: 

  • Combining multiple branches into a single branch
  • Fast-forward Merge ( linear by default in nature ) 
    • git merge 
  • No Fast-forward Merge ( not linear but with additional commit message )
    • git merge -no-ff

git pull:

  • git pull is used to maintain the syncing between local repo and remote repo.
  • combination of git fetch and git merge
  • git pull origin master 
git checkout: 
  • In case of replacing the contents of the working directory to the last committed version, we can use git checkout.
  • (.) is used to replace all the contents of the working directory. 
  • git checkout . 

  • Switch to another branch, we can use git checkout <branch name >
  • Switch and Create to another branch, we can use git checkout -b <branch name>
  • Used in the case where changes are not committed
git revert:
  • Used in cases where changes are committed.
  • Rollback the files present in the working area.
  • Not overwriting the committed history instead created a new commit of rollback.
  • git revert HEAD~2 ( created a new commit by default with back to previous two commits )
  • git revert -n ( it will not automatically commit the changes to move the changes to the staging area where we have to commit manually )
git reset:
  • Used in cases where changes are committed
  • Rollback the files present in the working area
  • Reset the commit history as well -- Completly removes the commit history
  • Powerful and destructive as well 
  • Three types of git reset:
    • Hard Reset: Reset everything till the commit the specified commit hash
    • Soft Reset: Moves the files to unstage area
    • Mixed Reset: Moves the file to unstage area 
  • Syntax:
    • git reset --hard <Commit Hash>
    • git reset --soft <Commit Hash>
    • git reset --mixed <Commit Hash>

git reflog: 

  • Acts like a safety vault when we are dealing with destructive commands such as deleting, resetting, and many more.  
  • Stores hash value of upto 90 days.
  • Local reference logs not for pushing into the remote repository.
  • If not able to find the commit hash in git log, try to look into git reflog.

git rebase:

  • Similar to merge, but rebase takes place to merge one at a time in case of a merge conflict happens it will display an error, and once the error fixes it will continue the merging.
    • git rebase --continue  
  • flattens the history it as merge complete branch from one to another.
  • Various options are present in git rebase if we run in interactive mode mentioned below:
    • git rebase --i HEAD~3 ( "i" denotes interactive mode )
# Rebase 
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.

git branch:

  • Branching is useful when we are dealing with daily code enhancements
  • It is good practice to isolate the features between different branches
  • Creations of Branch
    • git branch < branch name >
  • List Branch
    • git branch -va ( "v" display HEAD commit message and "a" display the branch name)
  • Switching to another branch
    • git checkout < new branch name >
    • git checkout -b < new branch name > ( this will create a branch and switch to newly create branch as well )
  • Delete branch
    • git branch -d < my branch name >
git bisect: 

  • Useful in case of regression testing and finding error by divide and conquer type of testing.
  • The three-step process of using git bisect -
    • git bisect start ( Entering in bisect mode )
    • git bisect bad ( Initially marks the bisect as bad as we are getting errors )
    • git bisect good HEAD~2 ( move to good known commits )
    • git bisect bad ( checked the last know commit and still getting the error then marked as bad )
    • git bisect good ( after moving found the working commit and marked as good )
git blame:

  • Useful in a situation when certain files modified by various users and to know who modified which sections of the file.
    • git blame <file name>
    • git blame -L 10,20 <file name>


What is Cherry-pick in git?

At times when we are dealing with multiple numbers of branches, but required to merge certain commits from either of the branches. 
Sounds complex right?
Recall the concept of a merge -- it will combine all the branches into a single branch.
Then how to achieve this requirement? Cherry-pick is best suitable for the use cases. 

Cherry-pick as the name implies will pick the individual commit from the branch and merge into the master branch without affecting the underlying structure of the code.

How to use Cherry-pick?

git cherry-pick < commit hash> 

At times due to cherry-pick we might get an error. And to handle this kind of situation we need to stop the cherry-pick first and fix the issue then continue the cherry-pick.

Stop\Abort cherry-pick

git cherry-pick --abort

Continue the cherry-pick
git cherry-pick --continue

What are the merge conflicts?

There are many ways to deal with a merge conflict, here we can discuss two-way resolve merge conflicts:

1. Manual: Edit the file decide which one you have to pick either the remote one or the local one.

2. Automatic: Use the their and ours merge conflict strategy to resolve the conflict. By choosing either remote or local changes
        • git checkout --ours <file path>
        • git checkout --theirs <file path>


In this git complete tutorial, we cover almost every powerful git commands.
Not only discuss we also perform hands-on to deep dive into the git.

Now a billion-dollar question - How do we implement git concepts in our daily life?
  • Install git on your pc\laptop (if you are on Linux\Mac - Git is preinstalled or for windows - download git for windows)
  • Create a GitHub account
  • Clone any project from https://github.com/talk2div
  • Create a Capstone project - Visit here
  • Start implementing the above concepts

Let me know your valuable feedback in the comment section of each blog post.

Join our telegram channel and group :) 
Telegram Group: @randomskoolQnA 
Telegram Channel: @randomskool

Till then happy coding !!! 

0 Response to "Why You Must Experience Git At Least Once In Your Lifetime."

Post a Comment

Hey Random,

Please let me know if you have any query :)