Git and GitHub An Introduction

Git

Git is a distributed version control system. It is primarily used for software development. It can also be used literally to keep track of changes to any files. Git was created by Linus Torvalds in 2005 for the development of the Linux kernel, with other kernel developers contributing to its initial development. Linus was not satisfied with any of the available free systems to replace BitKeeper. Consider it as a series of snapshots (commits) of your code. You see a path of these snapshots, in which order they were created. You can make branches to experiment and come back to snapshots you took. Currently, it is used by many popular open source projects, such as the Android or the Eclipse developer teams, as well as many commercial organizations.

GitHub

GitHub is a web-based Git repository hosting service, founded in 2008 which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features. It actually hosts remote repositories and allows code collaboration with anyone who has an access to the GitHub. It adds enhanced features like UI, bug tracking etc on top of Git. It’s free to use to host public repositories and has an Enterprise version like most open source applications.

This post discusses git essentials like repositories, branches, commits, pull, fetch and clone. You’ll create your own repository and learn git’s workflow, a popular way to create and review code.

Initial Steps:

The two things that you’ll be doing in order to play around with git and GitHub is to install git on your operating system first and then proceed to create a free account in the GitHub. The steps provided below assumes that we are using a Linux machine, though I’ll be providing quick links for installation in other operating systems.

Installing git:

Linux: Debian and its derivatives – #sudo apt-get install git

Linux: Fedora, RH and its derivatives – yum install git or dnf install git

Mac OS – https://git-scm.com/download/mac

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

We’ll use a Ubuntu machine to install git and the steps are as follows,

ajoy@testserver:~$ sudo apt-get update
ajoy@testserver:~$sudo apt-get install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
git
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/2,586 kB of archives.
After this operation, 20.5 MB of additional disk space will be used.
(Reading database ... 62961 files and directories currently installed.)
Preparing to unpack .../git_1%3a1.9.1-1ubuntu0.3_amd64.deb ...
Unpacking git (1:1.9.1-1ubuntu0.3) ...
Setting up git (1:1.9.1-1ubuntu0.3) ...
ajoy@testserver:~$

A more flexible way of installing git is to compile the software from the source. This procedure anyhow is time-consuming and will not be maintained by aptitude. The main advantage of doing so is that it will allow you to download the latest release and also gives you some control over the installation if you wish to customize your git installation. Before proceeding to compile from source you need to install a couple of dependency packages which allows you to compile git.

Another way of installing the latest version is to download the git source and to package it using an easy packaging tool called FPM with all your customizations in the new package. This process will provide you a package in .deb, .rpm or any other format which will be unique with your customization. This is a little more time-consuming way than the previous one.

Setting up git:

ajoy@testserver:~$ git --version
git version 1.9.1
ajoy@testserver:~$

ajoy@testserver:~$ git config --global user.name "ajoy"
ajoy@testserver:~$ git config --global user.email "ajoy.XXXX@XX.com"
ajoy@testserver:~$ git config --list
core.editor=/bin/vim
user.name=ajoy
user.email=ajoy.XXXX@XX.com
ajoy@testserver:~$

These details are stored in a file called .gitconfig which you can edit manually to add different configurations and also make sure you’re following the syntax and formatting properly.

GitHub account:

Next step is to go to the GitHub site and signup. GitHub accounts are free for setting up public repositories but there will be a nominal charge for setting up private repositories.

Creating a local repository:

Now we’ll be creating a local repository on our Linux machine.

ajoy@testserver:~$ mkdir mytestrepo
ajoy@testserver:~$ cd mytestrepo/
ajoy@testserver:~/mytestrepo$

Then we’ll be initializing this directory as a repository. We will execute git init command in the root of the new directory to do this.

ajoy@testserver:~/mytestrepo$ git init
Initialized empty Git repository in /home/ajoy/mytestrepo/.git/
ajoy@testserver:~/mytestrepo$

We’ll now create a file in the directory with touch command or with any of your favorite editors,

ajoy@testserver:~/mytestrepo$ touch file1
ajoy@testserver:~/mytestrepo$ ls
file1
ajoy@testserver:~/mytestrepo$

Once we add a file or change any existing file of a directory which holds a git repo, git will be aware of the changes happening But, git won’t keep a track of it unless until you tell it to do so. This process is called committing, which is a crucial task while using git.

In this point of time, you can use a command called git status to know how git sees your file,

ajoy@testserver:~/mytestrepo$ git status
On branch master

Initial commit

Untracked files:
(use "git add <file>..." to include in what will be committed)

file1

nothing added to commit but untracked files present (use "git add" to track)
ajoy@testserver:~/mytestrepo$

This actually means that git has noticed the creation of a new file called file1 but unless you execute git add command git is not going to do anything with it.

One of the most confusing parts while learning git is the concept of the staging environment and how it relates to a commit. A commit is a record of what files you have changed since the last time you made a commit. Essentially, you make changes to your repo (for example, adding a file or modifying one) and then tell git to put those files into a commit. Commits make up the essence of your project and allow you to go back to the state of a project at any point.

So, how do you tell git which files to put into a commit? This is where the staging environment or index come in. As seen in above, when you make changes to your repo, git notices that a file has changed but won’t do anything with it (like adding it in a commit).

To add a file to a commit, you first need to add it to the staging environment. To do this, you can use the git add <filename> command.
Once you’ve executed the command git add to add all the files you want to the staging environment, you can then tell git to package them into a commit using the git commit command.

ajoy@testserver:~/mytestrepo$ git add file1
ajoy@testserver:~/mytestrepo$ git status
On branch master

Initial commit

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

new file: file1

ajoy@testserver:~/mytestrepo$

Now the file is added to the staging environment and ready to commit.

Note: The staging environment, also called ‘staging’, is the new preferred term for this, but you can also see it referred to as the ‘index’.

Our First Commit:

It’s now time to go for our first commit. Commit is made with git commit -m “<message about the commit>”

ajoy@testserver:~/mytestrepo$ git commit -m "My First Commit"
[master (root-commit) e198044] My First Commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1
ajoy@testserver:~/mytestrepo$

The message at the end of the commit should be something related to what the commit contains – maybe it’s a new feature, maybe it’s a bug fix, maybe it’s just fixing a typo. Don’t put a message like “asdfadsf” or “1234” or any such junk. It should be something meaningful describing our commit so that other contributors or users who see this will understand what this commit is all about.

Pushing our repository to the GitHub:

Now we have our repository created locally in our system. Our next step is to push this repository to the GitHub so that it will be available for public and users can see our code, pull it to their system modify it and push it back. If we need to keep track of this codes locally, we don’t need to push it to GitHub. GitHub push is recommended if we need to work collaboratively on the code. The pictures provided below shows a demo of creating a repository in the GitHub

When you’re done filling out the information, press the ‘Create repository’ button to make your new repo. GitHub will ask if you want to create a new repo from scratch or if you want to add a repo you have created locally. In this case, since we’ve already created a new repo locally, we want to push that onto GitHub so follow the ‘….or push an existing repository from the command line’ section. But we will first see what that means and then will do our push.

In order to push the local repository to the GitHub, we need to set the remote URL of the newly created GitHub repository to our local repository. The command git remote -v will show whether our local repo is linked to any remote URL.

ajoy@testserver:~/mytestrepo$ git remote -v
ajoy@testserver:~/mytestrepo$ git remote add origin https://github.com/ajoybharath/mytestrepo.git
ajoy@testserver:~/mytestrepo$ git remote -v
origin https://github.com/ajoybharath/mytestrepo.git (fetch)
origin https://github.com/ajoybharath/mytestrepo.git (push)
ajoy@testserver:~/mytestrepo$

The command git remote add origin <url> will set the remote repo url to our local repository. This can be verified by executing git remote -v again.

Now we’ll be pushing our repo to remote GitHub,

ajoy@testserver:~/mytestrepo$ git push -u origin master
Username for 'https://github.com': <username>
Password for 'https://<username>@github.com':
Counting objects: 3, done.
Writing objects: 100% (3/3), 211 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/ajoybharath/mytestrepo.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
ajoy@testserver:~/mytestrepo$

The user name and the password is the one we created during the GitHub signup process.

We had done a push to the GitHub now let’s try something a little more advanced.

Assume that you want to make a new feature but are worried about making changes to the main project while developing the feature. This is where git branches are applicable.

Branches allow you to move back and forth between ‘states’ of a project. For instance, if you want to add a new page to your website you can create a new branch just for that page without affecting the main part of the project. Once you’re done with the page, you can merge your changes from your branch into the master branch. When you create a new branch, Git keeps track of which commit your branch ‘branched’ off of, so it knows the history behind all the files. Let’s say you are on the master branch and want to create a new branch to develop your web page. Here’s what you’ll do: execute git checkout -b <my branch name>. This command will automatically create a new branch and then ‘check you out’ on it, meaning git will move you to that branch, off of the master branch. After running the above command, you can use the git branch command to confirm that your branch was created.

ajoy@testserver:~/mytestrepo$ git checkout -b devel
Switched to a new branch 'devel'
ajoy@testserver:~/mytestrepo$ git branch
* devel
master
ajoy@testserver:~/mytestrepo$

The branch name with the asterisk next to it indicates which branch you’re pointed to at that given time.

Now, if you switch back to the master branch and make some more commits, your new branch won’t see any of those changes until you merge those changes onto your new branch.

The next step is to push the devel branch we created to the remote repository. This allows other people to see the changes you’ve made. If they’re approved by the repository’s owner, the changes can then be merged into the master branch. To push changes to a new branch on GitHub, you’ll want to run git push origin <yourbranchname>. GitHub will automatically create the branch for you on the remote repository.

ajoy@testserver:~/mytestrepo$ git push origin devel
Username for 'https://github.com': <username>
Password for 'https://<username>@github.com':
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/ajoybharath/mytestrepo.git
* [new branch] devel -> devel
ajoy@testserver:~/mytestrepo$

Now let’s discuss the word “origin” in the command above. When you clone a remote repository to your local machine, git creates an alias for you. In nearly all cases this alias is called “origin.” It’s essentially shorthand for the remote repository’s URL. So, to push your changes to the remote repository, you could’ve used either the command: git push git@github.com:git/git.git <your branch name> or git push origin <your branch name>

In order to get the most recent changes that you or others have merged on GitHub, use the git pull origin master command (when working on the master branch).

ajoy@testserver:~/mytestrepo$ git pull origin master
From https://github.com/ajoybharath/mytestrepo
* branch master -> FETCH_HEAD
Already up-to-date.
ajoy@testserver:~/mytestrepo$

Now we can use the git log command again to see all new commits.

ajoy@testserver:~/mytestrepo$ git log
commit e19804462d4b87336e4607d26e467f2ca14a5d3a
Author: ajoy <email>
Date: Wed Feb 1 21:10:23 2017 +0530

My First Commit
ajoy@testserver:~/mytestrepo$

Finally, three more basic git commands, git pull git fetch and git clone:

Git pull – Git pull will pull down from a remote whatever you ask (so, whatever trunk you’re asking for) and instantly merge it into the branch you’re in when you make the request. Pull is a high-level request that runs ‘fetch’ then a ‘merge’ by default, or a rebase with ‘–rebase’. You could do without it, it’s just a convenience.

Git fetch – Git fetch is similar to pull, except it won’t do any merging. So, the fetch will have pulled down the remoteBranch and put it into a local branch called “remoteBranch”. creates a local copy of a remote branch which you shouldn’t manipulate directly; instead, create a proper local branch and work on that. ‘git checkout’ has a confusing feature, though. If you ‘checkout’ a local copy of a remote branch, it creates a local copy and sets up a merge to it by default.

Git clone – Git clone will clone a repo into a newly created directory. It’s useful for when you’re setting up your local repo. It additionally creates a remote called ‘origin’ for the repo cloned from, sets up a local branch based on the remote’s active branch (generally master), and creates remote-tracking branches for all the branches in the repo

You can find more usage and command options in this post