Be it a Designer, be it a Creator or be it a Developer, we all deal with projects and files every day. Our primary work-cycle revolves around creating a file, saving it, editing or making required changes and saving it again.
Git is a small, yet very efficient version control tool. Git helps both programmers and non-programmers keeping track the history of their project files by storing different versions of their project files.
Git has become significantly popular among the developers in last few years. If you are a part of developer’s world it is expected that you know Git. You must have come across the term Git many times before as well. Don’t worry if you have never used Git, because in this tutorial you will be guided through:
But before diving deep into the understanding of Git, let us discuss little bit about the basics of version control systems and why we need them in the very first place.
While working on any projects or collaborative team work, we don’t want to modify the original source file. Instead we used to follow the steps mentioned below.
Before Version Control:
That is the old school manual method we used to follow earlier to keep in track of our work. But as our tasks/ projects became relatively bigger, keeping track of the history of our work file had also become harder than before. We discovered several drawbacks of that method, which are mentioned below.
This major issue of inefficiency was solved by the Version Control Systems.
After version control:
From the above figure, you might have gathered an idea about how Version Control Systems work. For better understanding let us look at the feature of Version Control System:
Learn DevOps in 16 hrs from experts
Version Control System is a platform that helps us keep track of the history of our project documents, program files storing them securely, in the form of different versions. Version control Systems creates a workflow preventing chaos during collaborative project development.
Till now we understood what version control system is and how version control systems came into the picture Let us also discuss briefly about the two types of version control systems.
There are two types of version control systems.
In Central Version Control System (as you see in the figure given below), we have a central server repository, where we can store the project files, which is also accessible to each member of the team’s workstation.
In the above figure, the basic structure of Centralized Version Control system is being depicted. There, we can see, team members can download the data from the central repository to their respective workstations (also called update). Also, they can make changes to the data and upload that in the central repository (also called commit).
In centralized control version system, every operation is performed directly on the repository. Now that we have learnt what CVCS is and its structure, let us look at the workflow of CVCS.
Now that we have learnt what CVCS is and its structure, let us look at the workflow of CVCS.
It is true that Centralized version control system helped us solve the problem we faced while maintaining versions of file over the time. But soon we have discovered that CVCS is not able to fix all the need of project developers. When it comes to collaborative work having only one central repository turns out to be a disadvantage. That is when the distributed Version Control System came into the picture.
In case of Distributed Version Control Systems, we don’t need to rely on a central server as you can see in the system structure illustrated on figure given below.
The figure shown above depicts the structure of Distributed Version Control Systems.
In DVCS, team members can download the data from the central repository to local repository. Which is also called “pulling”.
Pulling allows us to keep just another local copy of all the files available in the central repository. Which is also called “clone”.
From the local repository, team members are allowed to perform “commit” and “update” from their local workstations.
Once we are done with the new modifications in our project files we can upload them to the central/ remote repository via the local repository. This operation is also called “pushing”.
Now that we have learnt what DVCS is and its structure, let us look at the workflow of DVCS.
Out of so many options of version control systems available, when it comes to securely storing and sharing collaborative project works, Git is arguably the best choice for most software teams today. In the world of developers, a vast number has already adapted Git, and as we have mentioned earlier as a developer you are expected to know Git.
Now we will be diving deep into the understanding of Git.
Git helps developers by keeping track of the history of their codes files by storing them in versions on its own server repository i.e. GitHub. Git has the functionality, performance, security and flexibility that most teams and individual developers need.
Below given graph depicts the rate of popularity that Git has gained over the years (from 2004-2018):
Now let us go ahead and see why Git is used and what are the factors that make Git so unique.
There are some facts which makes Git so popular:
Now that we have learnt the importance of Git, we will move ahead and discuss how Git works. Let us start with the lifecycle of a Git project.
We have successfully committed files to our local repository. But how does it help in our projects? The answer is, when we will be doing collaborative projects, files may need to be shared with our team members. That is when the next stage of Git lifecycle occurs, which is GitHub, where we publish files from local repository to remote repository. And how do we do that? We do that by using Git push command.
Here, we have discussed the life cycle of Git project, where we came across some commands like Git init, Git add, Git commit, Git push etc. Now, we will be explaining these common commands in more details.
But before that let go through the installation and configuration of Git.
For Git installation in windows, click on the link given below:
For Git installation in mac, click on the link given below:
For Git installation in Linux, click on the link given below:
Here, we have successfully installed Git in our system. Before discussing common Git commands let us set up the environment in our systems.
After following these steps your GitHub page should look like this
To tell Git who you are, run the following two commands:
To begin, open a terminal and move to where you want to place the project on your local machine using the cd (change directory) command. For example, if you have a ‘projects’ folder on your desktop, you’d do something like:
We can go to the Git folder and see the new directory that we have just created.
Now we are all set to start working on the Git commands.
We will divide the Git commands into two primary categories.
let us discuss the local commands first.
Git init:Use the Git init command to initialize a Git repository in the root of the folder:
Git touch: To add files to a Project Git touch can be used. Let us see how we add a file to the Git repository we have just created
Step-1: First, we will create a new file with command touch.
Step-2: Then, we will see the files present in our master branch.
Git status: After creating the new file, you can use the Git status command and see the status of the files in the master branch.
Git add: Now we will add the humble.txt file to the staging environment by using Git add before going ahead to the staging and see the change using Git status.
There you go you have successfully created your first commit.
Before we move on to Branching and Merging operation, let us discuss the remote commands like remote, push, pull in Git, but for that, we will have to create a new repository in our GitHub account:
Step-1: Go to your GitHub account.
Step-2: Create a new repository.
Once you are done with filing up the new repository form you should land on a page like the following.
Now we are ready to operate remote commands in our repository that we have just created.
To push an existing repository to remote repository from a command line follow the commands given below.
After that give the following command:
Git push origin EnterBranchName
Don’t get confused by the word origin. Let me tell you what exactly that command is referring to:
Instead of writing the whole Git URL, like: Git push Git@Github.com:Git/Git.Git yourbranchname we can give the following command: Git push origin yourbranchname.
Now let us look at our repository:
When it comes to syncing remote repository pull command comes in handy.
Let us take a look at the steps that leads to pulling operation in Git.
Refer the steps given below:
Now that we have learnt the workflow of Git with the help of common commands, let us take a look at Branching, Merging and Rebasing and, also how and when to use them.
Now that we are a bit familiar with let’s take a step further and discuss one of the most important operations of Git branching.
Every node in the figure above represents commits.
Note: Remember that for “y”, “x” is the base.
Let us say that you want to modify something but don’t want to make any change in the main project that is where we take a branch out of the master branch.
For instance, if you are on the master branch and want to create a new branch to add a feature in the main project.
Step-1: Run Git checkout -b <new branch name>
Step-2: Use Git branch now to confirm that your branch is created
You can see from the above image that we have created a branch called branch1 and we automatically got landed in the new branch. Again, just to see which branch we are currently in we sent another command, Git branch (* mark before the branch name defines the current branch).
Note: Now, you must be wondering how we go back to our master class right?Use the following command:
$ git checkout master
Now that we have learned how to create a branch and work on a branch, let us take a look at merge feature of Git by merging a branch into the master branch.
Let’s understand merging with an example. Say, we have a master and a feature branch.
The merge commit represents every change that has occurred on feature since it branched from master.
Note: Even after merging we can go on with our work on both the master and feature branch independently.
Let us see how to perform merging using Git bash:
Step1: Create a new branch called branch2
Step2: create a new file in that branch.
Step3: Add changes from all tracked and untracked files
Note: refer the following command Git add attributes
In our case, we have given the command as Git add -A and after that, we will commit one sentence as shown below.
Step4: Check the last 3 logs by giving the command as Git log -3
We have created another branch on our master branch. Now we will see how to perform merging.
Git checkout master.
Git merge branch2
Now we have successfully merged the branch into master. Let us take a look at how it looks inside the master branch using the following command.
See the graph one the left. But why the graph is linear?
In our ProjectGit master branch we did branching and committed as well. But after branching master branch had not encountered any commits. So, after merging we have seen the linear.
Let us perform Git log –graph with more than one commits in both master and developers branches that we have created.
Here you can see the graph with commits on both master and developers branch. Red parts of the graph indicate merging operation.
Now that we have successfully learned to branch and merge with Git and GitHub, let us look at another very important Git operation i.e. rebasing.
When the project becomes relatively large, the commit log and history of the repository becomes messy. So, we use rebasing. Rebasing will take a set of commits, copy them and store them outside your repository. That helps us maintain a linear sequence of commits in our repository.
Now let us take the same example of master and feature branch. Here, we will rebase master branch. And see what happens.
Note: In rebasing the base of feature branch gets changed and the last commit of the master branch becomes the new base of the feature branch.
Now let us perform rebasing in Git bash.
Advantage of rebasing:
Disadvantage of rebasing:
Now that we understood what merging and rebasing is let us see where to use merge and where to use rebasing.
Golden rule of Git merging and rebasing:
When to use Merging:
When to use Rebasing:
As we have mentioned earlier, one major disadvantage of merging is merging conflicts, which can be a backbreaking work during a team project. Let us understand how merging conflict occurs and how to resolve this issue.
This drawback of merging operation in Git can be explained with a simple example shown below.
Say, we have two branches of the master branch, branch1, and branch2. And two developers working on these two branches independently on the same code file.
As we have shown in the figure above, they have made below mentioned modifications:
How to merge these two modifications now? That is where our merging conflict occur.
Similarly rebasing has rebasing conflicts as well, which can also be solved with the help of Git merging tool.
Let us look at a few Git workflows briefly, before we end this tutorial, so that you get an idea which Git workflow to choose for your team project.
Why is it important to choose the right Git workflow for team project?
Depending upon the team size, choosing the right Git workflow is important for a team project to increase the productivity.
Now, let us look at different Git workflows:
In Git centralized workflow, only one development branch is there, which is called master and all changes are committed into that branch itself. Below given figure depicts Centralized Workflow:
Feature Branching Workflow:
In feature workflow, feature development takes place only in a dedicated feature branch. Below given figure depicts Feature Branching Workflow:
In case of Git workflow, instead of a single master branch, this workflow uses two branches. Here, master branch stores the official release history whereas our develop branch acts as an integration branch for features.
Below given figure depicts Git Workflow:
In case of forking workflow, contributor has two Git repositories: one private local and one on public server-side.
This brings us to the end of the Git tutorial. In this tutorial, we have gone through Version Control Systems and its different types, basics of Git, terminologies related to Git, Git installation in windows, Linux, mac environment, setting up and working on GitHub repository. We have also discussed workings of some important operations in Git by the end of this tutorial.
Git is one of the most important version control systems that has experienced a significant growth rate and popularity over the years. Git plays a very important role in both developers and the non-developers world. If you are a part of soft developer’s world, it is expected that you know Git. So, having a good grasp of Git is very important.
Even Microsoft has acquired Git very recently. This opens up more possibilities for developers’ community. So, this is the right time to learn Git.
We hope you have understood Git and got the answer to what Git can do.
To have a more deeper level of understanding of different Version Control Systems with hands-on exercise you can also refer to this DevOps Certification Training Course by Intellipaat.Previous Next
Download Interview Questions asked by top MNCs in 2019?