If you need your system to keep track of the changes done to your folders, files, or any digital sources, then the Version Control System is exactly your lookout.

Git is a Version Control system that wraps up the change in the entire file system rather than mere data changes.

The category of software tools helps to keep track of changes to files by monitoring the modifications done to the code. A Version Control System is used as a repository since it maintains the snapshots of the project; and a copy of work that acts as a personal work copy of the files in the project.
Popularly used Version Control Systems include: Centralised Version Control Systems and Distributed Version Control Systems. Git falls under the category of Distributed Version Control Systems.

Before even understanding what DVCS is, let's figure out the one-liner of a Centralized Version Control System. The CVCS works on the changes directly committed to the central copy of your project. The issue of collaboration is effectively solved by DVCS, which has the server to maintain version control, hence multiple collaboration through commits on the same project is made much easier.

The benefits of Version Control Systems is that it helps in managing the changes in the source code over time. Although, if the mistakes are made, you can modify the code and minimize the disruptions being made.

Kick start your Git learning!

Before we start learning the git commands there are few essential terms that must be kept in mind.

Repository:

• Nicknamed as 'repos', the Repositories are the encyclopedia of the commits which represents the working tree up to date, irrespective of the machine on which the project is running.
• Apart from being the store-house of branches and tags, a repo also defines the HEAD from the current working tree.
• A Repo can either be a local folder on your computer or storage space on your online host. Your files can be of your choice - text, image, code, etc.
• Based on the servers, repositories can be divided into two types:

a) Bare repository: These repos share the changes done by different developers, but the modification of the creation of a new version for this repo is not allowed.

b) Non-bare Repository: These repos allow you to create any modifications to files or create a new version of the repo, similar to cloning isn't it?

• git init: When you're planning to start on your new project, you ought to let Git know of your plan, which is exactly what the .git file does when you run the git init command. It initializes a new Git repo that stores all the objects and references.

USAGE:

git init

• git fetch: It downloads all the latest commits from every branch and stores it in the local repo. git fetch never changes your working state though worked out multiple times. If you're eager to find out the local and the remote changes in the master branch then try the git diff command.

USAGE:

git fetch ee5df4b

Working tree:

• Working tree is defined as the directory which has the associated repository.
• You can identify a working tree if you hunt down a .git file on your filesystem. Hence it is a collection of directories, contents, and sub-directories.
• Git repository reflects the Unix file system that begins with the root directory and consists of i-nodes that identify the files with a unique number.
• It tracks the changes of a specific user of a repo version. When a change is committed to the git, the latter would hunt for the files in the working tree.

• The user in the Working tree is allowed to modify, create or delete the existing files. The changes can either be committed to the git or reverted, after your changes in the working tree.
  

• git pull: Now that you are aware of git fetch and git merge (scroll your way down to 'Master'), interpreting the working of git pull is a piece of cake. git fetch is executed first then the git merge in the working directory.
  

USAGE:

git pull  --rebase 

Index:

• Having made changes to your project, you directly cannot save it in the repo from your working tree. Hence, the Index acts as a middle man to commit your changes and then store it in the records.
• Index refers to the set of trees and files recently committed, on running the git add command.
• The index is the staging area for your next commit that supports a development model, non-native to the subversion.
• In the case of subversion, the list of actions is determined based on your current working tree.
• The list of actions, in this case, refers to the information within the Index. This is nothing but the succeeding state of HEAD, that helps you exercise control over staging in advance.
• git push: The commits on your local branch that aren't present on your corresponding branch in the origin server will be updated using the command git push.

USAGE:

git push

HEAD:

• HEAD in Git refers to the recent commit made on the current branch awaiting the checkout which is also referred to as an 'Active' branch.
• Git notices the active branch through the internal file .git/HEAD that is not advisable for manual manipulation.
• One buzzword that we hear while knowing the HEAD is Detached HEAD.
• In very few cases, the HEAD file is devoid of the branch of its reference but has an SHA-1 value. The reason for its occurrence is the sole reason to check out a specific commit, branch, or tag. This state is called Detached HEAD.

  Commit:

• The changes in your working tree are saved at a particular time. Commit basically reflects an individual's change to a file in its local repository.
• All that you have to do is, explain git of the change you want to make while running the git commit command.
• You can infer that git does not include a file automatically in the next commit. To resolve this situation try running the git add command.
• Git does not allow you to commit changes in the remote server, rather saves a new commit object in the local Git repository.
• Your desire to change the exchange commits can be performed manually using the git fetch, git pull and git push commands.
• git commit: The command creates a new commit having contents of the commit apart from the log message. The commit serves the purpose of the changes that can be undone if required. Executing a new git commit taking the place of the HEAD would make the previous commit its parent.

USAGE:

git commit 

The '-m' option allows you to set a commit message 

git commit  -m "Commit message"

 The '-a' option shows all the recently changed files

git commit  -a

 The '--amend' option allows you recheck and change the last commit

git commit  --amend

• git reset: Looking to undo a commit that has already been created? git reset HEAD will lead you to your branch specified. It updates the stage and the working directory using the three flags (--soft, --mixed & --hard)besides copying the files from history to the stage.

USAGE:

git reset  HEAD^ 

• git revert: The undo for git that picks all the tasks undertaken at your desired revert. If your commits have already been shared with your team, but your desire to undo the commits is your priority, then git revert is the best option.

USAGE:

git revert  0e70093 

Master:

• Choose to go with the name 'master'. It purely indicates the main branch where the developments are done.
• The accepted pull requests after the individual commit are merged with the master for the complete functioning of that feature.
• Moreover, Master is the terminology used for the branch. The remote repository will have a single local branch after cloning your project from the remote server. This local branch is called the master branch, which can be considered as the repository's default branch.
• But when you clone a repo for the first time, Origin is the name given to the remote repo that pushes and pulls the changes.

  Branch:

• Branch refers to the line of development that is different from the main branch. Your fancy or feature can be depicted in your code without disturbing the main branch(master).
• In such a case, the code from the master will be copied on your local system and the change would be private unless your code would enter the staging process(Commit).
• The branch is a movable pointer to one of the commits. Moving forward with the commits, operations are performed on the master branch pointing to your last commit.
• Branching for the record is the most common feature of Version Control Systems.
• git branch: The command creates a new branch that points to the recently checked out commit. If you're not happy with your branch you can delete it using git branch -d name. Remember, when your clone your remote repo, the main branch of the repo is your default master.

USAGE:

git branch  myBranch 

The '-d' to delete the particular branch

git branch -d myBranch

• git merge: A new commit with two parents having the records of the changes made at both the branches are combined using the git merge command. This new commit would now contain the latest complete code.

PRO-TIP: Keep the latest version of code in the master branch.

USAGE:

git merge  master 

Merge with the master

• git checkout: The prime importance of git checkout is to switch between the branches and workout a git commit command to notice the working. It can also copy the files from history to the working directory, in case of which the current branch wouldn't be changed.

USAGE:

git checkout  myBranch 

Tag:

• The name of the commit apart from the name of the person who issues the pull request and the time of the issuance is reflected in a Tag.
• Git being a Version Control System, will be able to tag specific points of importance in the history of the repository. This specific Git feature is used to mark the release points.
• It is like an unchanged branch that doesn't have a history of commits. It serves the meaningful names to a specific version in the repository.

Cherry Pick

• The cherry-pick command acts like a patch on another commit by copying a commit on this other commit in the current branch.
• If you have your commits on the wrong branch or do not need the entire branch to be merged then git cherry-pick is a bright option.
• To stage the all changes, run the git cherry-pick -n command.
• Stuck with conflicts? Try out git cherry-pick —abort or git cherry-pick —continue.

git cherry-pick -n

Using either of the below commands, resolves your conflicts
git cherry-pick -abort

git cherry-pick -continue

Rebase

• A rebase combines multiple branches. However, the fine line of difference between Rebase and Merge is drawn between the fact that Rebase combines the commits from the current branch to another with a linear history whereas Merge makes a single commit with two parents with a non-linear history.
• Essentially Cherry-picks in a row is its Rebase with the command git rebase master.
• git rebase: The commits on a particular branch move them to a new base by creating very new commits with varied IDs, without affecting the old ones.

USAGE:

git rebase  master

Healthy Git tip: The pushes cause a fast-forward merge on the remote repo. The rejected difference between local and remote branch can be overcome by pulling and then pushing it to the branch.

Work your way through the Git Flow

Click here for the visual guide of the Git workflow

Sort your PRE-REQUISITES

• After setting up Git in your local system, create a new directory.
• Open your new directory and create a new repo using the git init.

CLONE the repo

• Cloning is nothing but creating a working copy of the local repo. Try running the command git clone /path/to/repository.
• Attention: If you're using a remote server make git clone username@host:/path/to/repository your priority.

  Concentrate on the WORKFLOW

• Know the trees of Git which are Working Directory, Index and HEAD to understand the workflow.
• Spark your knowledge on the three terms by scrolling up to the first section.
• Know that Working Directory holds your actual files.

  ADD you first Git change

• Your desired changes can be added to the Index using git add ; git add *.
• Make a commit to your HEAD git commit -m "Commit message". Let's understand the fact that the remote repo is undisturbed.

  Treat your remote repo with a PUSH

• Push the changes in the HEAD of your local working copy to your remote repo, executing git push origin master. [You can change the branch as per your needs.]
• In case of pushing your changes to the remote server execute the command git remote add origin

  BRANCHING your way out

• Learn Git branching
• Create a new branch and switch to add your feature, later enabling it to be merged with the master branch. Type-out git checkout -b new_feature for this purpose.
• Make a switch to master using git checkout master or delete your branch using git branch -d new_Feature.
• No worries, your branch will remain private until you run thegit push origin command to push it to your remote repo.

  Make a quick UPDATE and a permanent MERGE

• The local repo has an update of the recent commit using the git pull that fetches and merges the remote changes.
• Make another merge to your current branch by git merge .
• The possible conflicts to the changes auto-merged are overcome by manually handling the files and later indicating them as merged withgit add .

  Find out your Commit ID

• git log to find out your recent repo history. Check out the following log parameters when you:
• Do you require a Compressed log? - git log --pretty=oneline
• Targetting an author's commits? - git log --author=bob
• Want to know more about the parameters? - git log --help

  Software release TAGS

  It is a good habit and a professional approach of creating the tags for the Software releases which can be achieved by git tag 1.0.0 .

GIT Takeaways

Check out the tools to play around with Git.

• Learn GIT from scratch
• Aurees Git Client
• Git Kraken
• Git Fork
• Git Master
• Manage your DevOps lifecycle tool

Follow our community for more goodies, stickers,
t-shirts