To understand what Git and GitHub is we first need to understand what version control system is.
What is Version Control System?
Version Control System(VCS) solves two problems of a Software Development Lifecycle(SDLC). 1. Sharing 2. Versioning
Sharing :
Let’s say you and your friend are developing a calculator application and are working on different functions of the calculator. Here it may be easy to share the code over email or any other medium but in real world industry projects there are thousands of files and dependencies. So it becomes impractical to share files and keep making changes to them over some medium like email. This is where version control systems come to the rescues. We will discuss how later.
Versioning :
To understand let’s say you initially created a function to add only two numbers. Eventually you improved the function and made appropriate code changes to make the function able to add three numbers. Let’s assume this change added a bug to the calculator or the function created a problem of overabundance or the management want to go back to previous function of adding two numbers only for whatsoever reason. In this particular example, you can simply have a copy of previous code before changing the function, but in real industry projects, hundreds if not thousands of changes are made to the code everyday. Therefore it is almost impossible to keep copies of previous versions of code with each and every developer while still making changes to the code.
Now that we have understood how version control systems help. We need to understand the difference between two types of version control systems : Centralized version control system and distributed version control system.
Centralized vs Distributed Version Control System
Before git, CVS and SVN existed which were Centralized Version Control. In centralized version control the changes need to be committed remotely to the central repository. This creates problems as remote commits are slow and there is a single point of failure. Also unsolicited changes may break the builds. Distributed version control solves these problems as unlimited number of copies of the central repository can be made by each developer and they can work on those copies. This solves the problem of single point of failure. It is termed as forking. Developers can commit the changes locally which is superfast and doesn’t require internet and then these changes can be pushed to the forked repository. A pull request is then created to the central repository which is accepted by moderators after thoroughly reviewing the changes. This improves the security. The difference between these two version control systems is explained even better in the following video.
Now let’s understand
What is git and GitHub?
Git is an open source Distributed Version Control System. So any organization can download git and setup their own distributed version control server. Few organizations have added various functionalities such as raising issues, comments and project management and have offered this as a solution so that organizations don’t necessarily need to setup their own servers for version control. GitHub is one such solution. Other examples include Gitlab, Bitbucket etc.
Complete git life-cycle project
We will understand the git life-cycle and git commands with a simple project. To start with we first need to need to install git on our system.
We then need to initialize a folder as git repository. For this we use the git init command inside the folder. Initially git doesn’t keep track of any files in the folder . We can check that using the git status command. However git keeps a record of which files are tagged to be tracked and which aren’t.
We can mark the files to be tracked using the git add <filename> command. It is also called as staging the files. The git add . command is used for tracking all files in the current directory. We have added calculator.sh to be tracked and excluded hello.txt from being tracked and as shown in following snapshot.
Once we add a file to be tracked git then checks for any changes made to those files. We will now edit the calculator.sh file and if we want to go back to the code before it was changed we can simply use the command git restore <filename>. If we mistakenly delete any files or code in our working directory we can use the same command to recover those files. If we want to keep the changes we have made we cann simply run the git add <filename> command again.
Once we are done with editing the code we can commit the changes using the git commit-m “message here“. After this let’s say we make changes to the calculator.sh file and commit those changes as “Second commit“.
We can look for all the changes that we have made using the git log command. And if we want to go back to any previous versions we can use the git reset —hard <commit id> command. This is how git gives the versioning functionality.
After committing the changes locally we need to push the changes to the remote repository using the git push command but before that we need to add the remote repository with the git remote add <name> <remote repo url> command. If we have cloned the repository we don’t need to add we can simply use the git push command.
Now we can see the changes in the remote repository.
If we want to add a new feature to add 2 numbers in calculator.sh there is a possibility that the changes made may break the entire code. Therefore whenever adding new features or fixing bugs we create separate branches for it. There are different ways to create a branch. Let’s create a branch ‘division’ using the git checkout -b <branch name> command. This creates a copy of all the files in the main branch. Let’s edit the calculator.sh file in this branch and stage the changes using git add and commit using git commit
We need to merge the changes committed to division branch to the main branch. There are different ways to merge the changes : git rebase, git merge, git cherry-pick. In this project we will use the git cherry-pick command. With this command we can merge select commits to the main branch. Git merge and git rebase merges all the commits from the division branch. The difference between git merge and git rebase is the git merge changes are merged at the top of all other changes whereas in git rebase the changes are in linear order. This can be understood better with below article
Now the changes from division branch can be seen into the remote repository after pushing using git push.
