Reading Time: 8 minutes

Well, this is my first blog on IT, so go easy on me. I just started my internship as a Software consultant and witnessed the need for GIT in an actual development environment. So I went straight to google and googled it, this is what I understand and as an open source guy I want to share what I have learned so far in this domain.

So folks fasten your seat belts and let’s start.

We all are kind of content creators or knowledge creators, whose main task is to create content, a file, a document or anything and after creation we save it. Then edit the content of that file and then again save it. So this cycle keeps going on

CREATE -> SAVE -> EDIT -> SAVE AGAIN

This is somehow our daily task are in our respective lives. But sometimes we might want to revert the last changes we made to our content or file., or maybe we want to know what changes were made on this specific day or time or who did these changes if our file is shared among multiple personalities when we are working on a collaborative project. These when, why, what changes related questions are simply not possible in the traditional way of managing our contents or files neither we can work carefree in collaborated projects in which we might want to know who did what changes at a certain period of time or if a file is being edited by two persons how to manage the changes of both.

Enter VCS acronym for Version Control System or Version Control Software which deals with all those questions of who did what changes, etc.

• VCS is a system that monitors changes over a file for a certain period of time. It is also known as source code management software or revision tool. It manages the changes to a file or collection of files over a time period. Basically, it tracks the history of each file and manages that accordingly.
• VCS is a vital tool for software developers without this collaborated projects would be a huge pain.
• VCS maintains a collaborated history i.e. which team member has edited which file and at what time. It tracks each file in the project and thus helps the developers of that team from lots of problems.
• VCS provide ways to sort out who added these changes to my file, how to revert last changes from a certain file, what content is added by this specific person and many more.
• VCS also provides branching mechanism in which every user creates a branch of an original master branch and add his/her changes to that branch without affecting the original source code or master branch. Through this, we are applying the separation of concern methodology. After we have added our features in the branch we can simply merge it with the master one.

Still not getting VCS? Why it is important or why the whole IT field is crazy about it? Then follow me, consider you are a developer in some xyz company, working on an abcd project which consists of a team of 10 people including yourself. Now if the age is of no VCS then you might have to shout to your whole team that you are working on this particular file so that nobody else works on that same file. Getting the picture now? In big projects where team ranges from 10 to 100 and directory structure ranges from 1000 of files to 10K, editing a file and that too not being used by other teammates might be next to impossible. In addition to this, someone’s changes might get override or delete by some other person. That’s the reason why VCS is so important and why there is a separate career path in IT for this i.e. Dev-Ops.

Now back to theory –
There are three different types of VCS:-
1). Local VCS
2). Centralized VCS
3). Distributed VCS

Local one actually monitors files on a local system mainly for solo runnable projects.

Centralized one means VCS is maintaining collaborated history on a single system which poses a risk of failure.

Distributed means that each node in the network maintains the full collaborated history of every file in the project which gives an advantage of backup of the whole system on each node.

To implement VCS in your project, you have to use one of the following tools which are designed by different vendors:-

– GIT
– CVS
– SVN
– Mercurial
– Bazaar
– TFS
– BitKeeper
– Monotone

GIT is one the most popular and most widely utilized Distributed VCS based tool out there. GIT emerged to the top because:-

• It’s lightweight
• Track history
• Easy to use
• Speedy
• Tracks all collaborated changes
• Offline based
• Open Source

GIT provides strong support for non-linear development, meaning files are tracked in a sequential fashion rather than random. It can efficiently handle small to large sized projects. No matter what kind of project you may be working on, GIT can easily track all of its files.

Well, enough of the GIT advantages and features, there are always two sides to every coin. So the disadvantages of GIT are:-

• Complex and Bigger History as the project code gets bigger and bigger.
• It does not support Keyword expansion.

Installation of GIT

Installing on Linux

If you’re on Fedora (or any closely-related RPM-based distribution, such as RHEL or CentOS), you can use dnf:

$ sudo dnf install git-all

If you’re on a Debian-based distribution, such as Ubuntu, try apt:

$ sudo apt install git-all

Installing on Windows

follow – https://git-scm.com/download/win

Installing on MacOS

follow – https://git-scm.com/download/mac

To check version

 git --version

In order to use GIT, you might have to first create an account on GitHub.com and have to learn the basics of GitHub.

GitHub.com is a hosting platform for collaboration and version control. It’s like a cloud database where numerous person host there projects under open source regulations. GitHub host repositories which are a location where all your project code resides. So generally one project results to one repository. If you are a complete beginner then just create a repository and then just add any file in that repository via GitHub.com. We can also create a local repository and push it to the GitHub or we can have a GitHub repository and clone that to our local system.

Note :GitHub.com is one of the many online platform that supports GIT like GitLab.com

Some basic Git Commands are:-

• git init – Create an empty Git repository or reinitialize an existing one
  • The git init command creates a new Git repository. It can be used to convert an existing, un-versioned project to a Git repository or initialize a new, empty repository. Most other Git commands are not available outside of an initialized repository, so this is usually the first command you’ll run in a new project.

• git clone – Clone a repository into a new directory
  • The git clone url/path-of-repository command is used to target an existing repository and creates a clone or copy of the repository.

• git config
  • The git config command is a convenience function that is used to set Git configuration values on a global or local project level. These configuration levels correspond to .gitconfig text files. Executing git config will modify a configuration text file.

• git config –global user.name “user_name”
  • Sets the name that you want attached to your commit messages

• git config –global user.email user_email
  • Sets the email you want attached to your commit messages

• git status – Show the working tree status
  • The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven’t, and which files aren’t being tracked by Git.
• git add – Add file contents to the index
  • The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit.
• git commit – Record changes to the repository
  • The git commit command is used to save your changes to the local repository. Note that you have to explicitly tell Git which changes you want to include in a commit before running the “git commit” command. This means that a file won’t be automatically included in the next commit just because it was changed. Instead, you need to use the “git add” command to mark the desired changes for inclusion.

• git commit -m “commit_message”
  • By this we are setting a message with our commit

• git checkout – Switch branches or restore working tree files.
  • Git terms, a “checkout” is the act of switching between different versions of a target entity. The git checkout command operates upon three distinct entities: files, commits, and branches. In addition to the definition of “checkout” the phrase “checking out” is commonly used to imply the act of executing the git checkout command.

• git branch – List, create or delete branches
  • 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 the 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.

• git pull – Fetch from and integrate with another repository or a local branch
  • The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content.
• git push – Update remote refs along with associated objects
  • The git push command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repo.
• git fetch – Download objects and refs from another repository
  • The git fetch command downloads commits, files, and refs from a remote repository into your local repo. Fetching is what you do when you want to see what everybody else has been working on. It’s similar to svn update in that it lets you see how the central history has progressed, but it doesn’t force you to actually merge the changes into your repository. Git isolates fetched content as a from existing local content, it has absolutely no effect on your local development work. Fetched content has to be explicitly checked out using the git checkout command. This makes fetching a safe way to review commits before integrating them with your local repository.

• git log – Show commit logs

• git diff – Show changes between commits, commit and working tree, etc
  • Diffing is a function that takes two input data sets and outputs the changes between them. git diff is a multi-use Git command that when executed runs a diff function on Git data sources. These data sources can be commits, branches, files and more.
• git stash – Stash the changes in a dirty working directory away
  • The git stash command temporarily shelves (or stashes) changes you’ve made to your working copy so you can work on something else, and then come back and re-apply them later on.
• git reset – Reset current HEAD to the specified state
  • The git reset command is a complex and versatile tool for undoing changes. It has three primary forms of invocation. These forms correspond to command line arguments --soft, --mixed, --hard. The three arguments each correspond to Git’s three internal state management mechanism’s, The Commit Tree (HEAD), The Staging Index, and The Working Directory.

These were the basics of GIT, with this I hope you now know much more than before reading this blog. I would recommend you to practice all these commands. Additionally, there are even more commands and each command has its own set of options or attributes that make its functioning different. Consequently, I hope some concepts of GIT are now clear and for rest or if you want to master GIT or want to become a Dev-Ops engineer then just deep dive in GIT official docs.
You know where to find GIT official docs right? If not, then just GOOGLE it.
Just kidding, here are some reference links:-

Thanks for sticking to the end. If you like this blog, please do show your appreciation by giving thumbs ups and clicking on the share button. For any feedback use the reply box or just drop a mail at my mailbox. Till then adios!