Version Control System (VCS)
To understand the git first let’s understand the version control system (VCS). VCS is a system that records the changes to file or set of files over time so that one can recall specific versions later on need basis. The complete version history get stored on a centralized repository. This centralized repository can be on local machine or on any. Central VCS server. To understand let’s take example where we code is stored using VCS. If somebody wants to make a change in the code, one need to checkout the code on local. When changes are done, new version needs to be added back to VCS. There are many VCS but subversion or SVN is most popular one.
Distributed Version Control System (D-VCS)
Challenge comes when a large group is make simultaneous changes. To solve that Distributed version control system came. If you are familiar with one or more traditional or centralized version control systems like Subversion, there will be several mental adjustments to make in your migration to Git. The first is that there is no central server. The second is that there is no central server. The full history of the repository lives on every user’s machine that has cloned (checked out) a copy of the repository. This is the essence of a Distributed Version Control System (DVCS). It’s also important to note that Distributed VCS doesn’t store exact progressive versions of the files. Instead, it stores just the patch-sets for tracking versions which decrease the volume of history stored on each local machine. Also, developers can record changes in their local machine while working offline.
What is Git
Git is an open source distributed version control system developed by Linux creator Linus Thorvalds in 2005 and released under the free GNU-GPLv2 license. Git is designed to make sure it is secure and it maintains the integrity of content being version controlled. It uses Check-sum to confirm that information is not lost during transit or is tampered with on the file system. Internally Git creates a checksum value from the content of the file and then verifies it while transmitting or storing data. If the checksum is different there is a corruption in the file. The hashing algorithm used is Secure Hash Algorithm 1 (SHA -1) to calculate the hash.
Here are some uses of the Git tool:
- Git is used to tracking changes in the source code.
- It allows multiple developers to work together.
- Git supports non-linear development because of thousands of parallel branches.
- It can handle large projects efficiently.
There are 3 important points about git are:
- Git stores a Snapshot of a file as opposed to storing a Difference, which other Version Control Systems do.
- Git only takes a Snapshot of the changed files.
- To optimize memory, Git keeps a Reference of the file that has not changed instead of making a copy of it in the new version.
| Git | GitHub |
| Git is a software tool that keeps track of the changes | GitHub is a git Repository Hosting service |
| It is installed on local system | It is hosted on the web i.e. it’s cloud based |
| It is used to manage different versions of the files in a git repository | It is space on the web to have a copy of the git repository |
| It is command line tool | It provides a graphical interface |
Git Installation
Windows: http://www.git-scm.com
Linux: apt-get install git
yum install git
MAC: already installed with xcode
To verify the git version use:
git –versiongit version 2.24.3 (Apple Git-128)
Git Bash vs Git CMD
Git Bash is command line based git client while git CMD is nothing just CMD which can run git commands.
Getting Started with Git
First command one should learn is to use Git Help command. Below command will list the git commands:
git help -a
To get help on specific command use:
git help <command_name>
Git Configuration
To start with git one need to configure it. Use below commands to configure git user name and email Id.
git config --global user.name “My Name”
git config –global user.email “My Email”
Creating the repository
Now when you installed the git you can begin with creating a new repository. From a command prompt, change the directories to either a blank folder or an existing project that you want to put under version control. Then initialize the directory as a Git repository by typing the following commands:
git init
If you already have the repository you can clone that by using:
git clone <URL to the repository>
Not to check the status you can use
git status
Clone and Fork
Cloning
By cloning a project, you are downloading a copy of that project to your local computer.
If you intend to collaborate on this project, you will only be able to publish / upload your changes if you have permission to do so (provided by the project’s owner).
Forking
By forking a project, you are creating your own copy of that project.
Since you are the owner of that project, you will be able to make any changes you like and add them (push them) back into the remote repository (the “fork”). You can only fork projects that are either public or where you have sufficient permissions.
Branch
For instance, if you are working on a new feature, and you want the feature and the main version of the code to work simultaneously. Here you can create a branch of your code so that you can work on the new feature, whereas the rest of the team can continue to work on the main branch of the project. Once both are done, you can merge them.
1. List of checked out branches:
git branch
To view both remote-tracking branches and local branches, run the command:
git branch -a
There will be an asterisk (*) next to the branch that you’re currently on.
There are a number of different options you can include with git branch to see different information. For more details about the branches, you can use the -v (or -vv , or –verbose ) option. The list of branches will include the SHA-1 value and commit subject line for the HEAD of each branch next to its name.
You can use the -a (or –all ) option to show the local branches as well as any remote branches for a repository. If you only want to see the remote branches, use the -r (or –remotes ) option.
2. Switch the branch
git checkout feature/my_branch
3. Create new branch
git checkout -b <branch_name>
You can also choose what to base the new branch on. A quite common thing to do is, just for example:
git checkout -b new-branch existing-branch
Same can be achieved in two steps:
# Two-step method
git branch NEW-BRANCH-NAME
git checkout NEW-BRANCH-NAME
4. Compare Branches
You can compare branches with the git diff command:
git diff FIRST-BRANCH..SECOND-BRANCH
You’ll see colored output for the changes between branches. For all lines that have changed, the SECOND-BRANCH version will be a green line starting with a “+”, and the FIRST-BRANCH version will be a red line starting with a “-”. If you don’t want Git to display two lines for each change, you can use the –color-words option. Instead, Git will show one line with deleted text in red, and added text in green.
If you want to see a list of all the branches that are completely merged into your current branch (in other words, your current branch includes all the changes of the other branches that are listed), run the command git branch –merged .
5. Rename a Branch
To rename a branch, run the command:
git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
# Alternative
git branch –move OLD-BRANCH-NAME NEW-BRANCH-NAME
Pull from Remote
This concept of Git allows for pulling the program when the team is working from a remote location.
git pull
Actually, git pull is two step process done in command. It includes fetch and merge.
git fetch [fetch all the info you don’t have from remote repository, no automatic merging]
git merge [automatically merge data from remote with the your repository data]
Once you have latest files on your local repository by using clone or pull or by initiating the new repository you can start editing those or creating new files. For editing you can use vim, nano on unix based systems. While can use any text editor like notepad, ultraedit or notepad++ on windows system.
Default edit can be configured using below command:git config –global core.editor <directory address>
Stage your changes
Git has a staging area, for files that you want to commit. On GitHub when you edit a file, you commit it as soon as you save it. On your machine, you can edit a number of files and commit them altogether.
Staging a file in Git’s terminology means adding it to the staging area, in preparation for a commit.
Add your amended file to the staging area:
git add NewFile.txt
and check the result:
$ git status
# On branch amend-my-name
# Changes to be committed:
# (use “git reset HEAD <file>…” to unstage)
#
# modified: attendees_and_learners.rst
#
If there are other files you want to change, you can add them when you’re ready; until you commit, they’ll all be together in the staging area.
Commit your changes
When you’re happy with your files, and have added the changes you want to commit to the staging area:
git commit -m "added my github name"
The -m flag is for the message (“added my github name”) on the commit – every commit needs a commit message.
Tip: In case do not want to add updated files explicitly you can do it with commit command:
git commit -a -m “added my github name"
Revising or reversing generated commits
If you adopt changes in the form of a commit, you can subsequently revise or even remove the content at any time. A typical case in which adjustments are necessary is, for example, if you have generated the commit too soon and forgotten important files or changes. In this instance, you’ll need to provide the new or adjusted files retroactively using “git add” and repeat the entry into the central repository. To do this, add the option –amend to the standard command:
git commit --amend
However, if you want to withdraw the most recent commit, you can use the following Git command:
git reset --soft HEAD~1
This command reverses the commit last included in the HEAD. The files it contains are then reset back to the status: “Planned changes for the next commit”. To delete the files entirely, enter the command below instead:
git reset --hard HEAD~1
Viewing commit history
The “git log” command lists the generated commits in reverse chronological order, whereby the SHA-1 checksum, the author (name and email address) as well as the date of the commit are shown as standard. What’s more, the individual message can also be seen, providing you and other users with key information to quickly classify each of the changes.
The log command can also be modified by various parameters. Some useful options are shown in the table below:
| Option for the “git log” command | Description |
| -p | shows the changes contained in a commit |
| -2 | only lists the last two commits |
| –stat | adds a small statistic to each entry, showing which files were changed and how many lines were added or removed |
| –pretty | changes the format of the output, with various formats available; –pretty=online is one possible format, for example, which lists all commits in a single line |
| –abbrev-commit | only shows the first characters of a SHA-1 checksum |
| –relative-date | shows the data of a change in a relative format (e.g. “two weeks ago”) |
How to check upstream:
git remote
git remote -v lists all of your configured remote repositories. This script assumes that you only have one GitHub remote URL. If your repo has more than one, you will need to add some logic to account for that.
Push your changes to GitHub
When you made a change on GitHub, it not only saved the change and committed the file at the same time, it also showed up right away in your GitHub repository. Here there is an extra step: we need to push the files to GitHub.
If you were pushing changes from master locally to master on GitHub, you could just issue the command git push and let Git work out what needs to go where.
It’s always better to be explicit though. What’s more, you have multiple branches here, so you need to tell git where to push (i.e. back to the remote repository you cloned from, on GitHub) and what exactly to push (your new branch).
The repository you cloned from – yours – can be referred to as origin. The new branch is called amend-my-name. So:
$ git push origin amend-my-name
git push -u origin new_branch
Once you have pushed the changes to your branch you might need to get the branch merged into master branch which might need the reviewer. For that login into github or bitbucket repository and perform steps using browser UI.
Tagging: creating, deleting and listing tags in Git
Like many other version management systems, Git also offers a tagging feature that allows selected points in the history of a repository to be marked as important. These tags are typically used to label the releases of a software program (like version 1.0, 2.0, etc.) so that they remain easy to access even for larger projects. Git supports two types of tags:
- “Annotated” tags are saved as independent objects in the database, including their own checksum, tagging message, date, name, and email address of the tag author as well as an optional GNU Privacy Guard signature (GPG signature).
- “Lightweight” tags act like branches, only serving as a reference to a commit. This type is suitable when you only need temporary tags or don’t want to save the extended information.
You can create annotated tags in Git by using the “git tag -a” command on the respective commit. If you also add the “-m” parameter as a suffix, you can compose the desired tagging message directly in the command line (between straight quotation marks). In this Git guide, we generated the “Test” commit which we can also link with a tag including the message “example tag”:
git tag -a Test -m "example tag"The approach for lightweight tags is similar. However, you only need to use the basic command “git tag” on the relevant commit – without any further parameters. This command would appear as follows for our Git tutorial example:
git tag TestAs soon as tags exist for your repository, you can also display them with the “git tag” command and the optional “-l” or “–list” parameters:
git taggit tag -lgit tag --listThe “git tag” command displays the previously created tag for the commit “Test”.
To delete a tag from the local working repository, apply the command chain “git tag -d” to it. We can delete our tag for “Test” as follows:
git tag -d Test
Tags have to be manually adapted into the central repository. To do so, both the tag name and the command “git push origin” are required. Instead of the tag name, you can also add the parameter “–tags” which carries all generated tags over to the repository.git push origin --tags