Quick and Dirty tutorial on Jenkins and Git plugin

Jenkins is a popular open source Continuous Integration tool which is widely used for project development, deployment, and automation. Continuous integration is a process in which all development work is integrated as early as possible. The resulting artifacts are automatically created and tested. This process should identify errors as very early in the process. Jenkins is one open source tool to perform continuous integration and build automation. The basic functionality of Jenkins is to execute a predefined list of steps. The trigger for this execution can be time or event based. For example, every half an hour or after a new commit in a Git repository. Jenkins also monitors the execution of the steps and allows to stop the process if one of the steps fails. Jenkins can also send out notification about the build success or failure.Jenkins can be extended by additional plug-ins, e.g., for supporting Git version control system, provisioning with docker or integration with the puppet.

In this post, we’ll discuss Installation of Jenkins and how to use Jenkins to integrate with GitHub in such a way that a git commit can trigger a Jenkins build. Jenkins can be started via the command line or can run in a web application server. In Linux, you can also install Jenkins as a system service. Almost all the Linux platforms there is a native package of Jenkins available. Please check the Jenkins home page for more details on this.

All the demonstrations in this post are shown using and Amazon EC2 RHEL 7  instance. We’re using an Amazon instance because we need to establish a connection to the system’s public IP via Git web hooks. If you are using any other Linux distribution you can make use of most of the steps described here except the RHEL specific command like yum, systemctl etc. Also, you can find your OS-specific installation details in the Jenkins Wiki.

We will be installing Jenkins using the native package available for the RHEL/Fedora/CentOS. There is another way of installing the Jenkins which includes deploying the Jenkins war file which you can see here

Installing Java:

The prerequisite of installing Jenkins is to setup a Java Virtual Machine on your system. This will be done by installing a latest OpenJDK package. Before that, we will be installing EPEL repository for RHEL 7. You can download the epel package from fedora project URL using wget command and if in case wget is not installed on your machine install it using yum.

# yum install wget

# wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

# yum install epel-release-latest-7.noarch.rpm

You can do a yum search OpenJDK to know the available JDK packages.

# yum install java-1.8.0-openjdk-devel.x86_64

Verify the java installation as below,

# java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

Next step is to set the environment variables namely JAVA_HOME and JRE_HOME. This is used by the Java applications to identify the Java virtual machine path. This is accomplished by adding these environment variables to the file /etc/profile.

export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk
export JRE_HOME=/usr/lib/jvm/jre

Once this is added you can reload the environment variables from /etc/profile by executing,

# source /etc/profile

Installing Apache Ant and Apache Maven:

The next step is to install the apache foundation siblings Ant and Maven. These siblings are used while building Java based application in Jenkins. Both these packages can be downloaded from the respective project site as a tarball.

Downloading

# wget http://redrockdigimark.com/apachemirror//ant/binaries/apache-ant-1.10.0-bin.tar.gz

# wget http://redrockdigimark.com/apachemirror/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz

Installing

The command provided below will extract your downloaded tar ball and put it in /opt. Then we will go to the /opt directory and create a symbolic link.

# tar -zxvf apache-maven-3.3.9-bin.tar.gz -C /opt/
# tar -zxvf apache-ant-1.10.0-bin.tar.gz -C /opt/

# ln -s apache-maven-3.3.9/ maven
# ln -s apache-ant-1.10.0/ ant

The final listing of the /opt will show something like seen below,

# ls /opt
ant apache-ant-1.10.0 apache-maven-3.3.9 maven

Environment Variables

Now we will setup environment variables for this apache sibling and verify the installation. These variables are set by creating files maven.sh and ant.sh under /etc/profile.d and reload the environment variables.

# cat > /etc/profile.d/ant.sh
export ANT_HOME=/opt/ant
export PATH=${ANT_HOME}/bin:${PATH}

# cat > /etc/profile.d/maven.sh
export M2_HOME=/opt/maven
export PATH=${M2_HOME}/bin:${PATH}

# source /etc/profile

At this stage, if everything goes well you'll see and output similar to the one below,

# echo $JAVA_HOME;echo $JRE_HOME
/usr/lib/jvm/jre-1.8.0-openjdk
/usr/lib/jvm/jre

# ant -version
Apache Ant(TM) version 1.10.0 compiled on December 27 2016

# mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-514.el7.x86_64", arch: "amd64", family: "unix"

All our prerequisites for Jenkins installation is ready and we’ll now proceed to install Jenkins. We will add an RHEL 7 specific Jenkins repository and install with the yum command.

# wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
# rpm --import http://pkg.jenkins-ci.org/redhat-stable/jenkins-ci.org.key
# yum install jenkins -y

Once the installation is complete, we will enable the service and start it.

# systemctl enable jenkins.service
# systemctl start jenkins.service
# systemctl status jenkins.service

If you have followed the instalation so far you find Jenkins running under the following URL:

http://<ip of your ec2 instance>:8080/

Note: if there are any connection issues or page not loading in the browser check the firewalls inside the system and flush it if any with the command iptables -F. Also check the security-groups of your EC2 instance to allow traffic on port 8080.

You’ll see a Jenkins page similar to the one above and you can use the password as described there and setup a user to create Jenkins builds.

#  cat /var/lib/jenkins/secrets/initialAdminPassword

Now we will install the git package in the system and Jenkins GitHub plugin to create a build job.

# yum install git

Create a repository in GitHub by importing the repository https://github.com/ajoybharath/hello-world.git

You can clone your newly created repository to your system and make it ready to accept push from your repo to GitHub. You can see more on git installation and setup here

Once all the steps as provided in the above screen shots are done we’ll be ready to create our first build. You can follow the sequence of images below and setup a Jenkins build job. We’re using the following git repository in this demonstration.

https://github.com/ajoybharath/hello-world.git

Apply and Save the job and go ahead and build the project.

If in case you’ll find any issue in the build similar to the one below,

FATAL: command execution failed
java.io.IOException: Cannot run program "mvn" (in directory

Please add the following lines to the Jenkins config:

# vi /etc/sysconfig/jenkins and add the line to "source /etc/profile" the end of the file and stop and start Jenkins.

Try building the job again. Also, we will be adding the GitHub webhook to enable the build trigger if a change is pushed to the repository.

In the Jenkins home page guide to Manage Jenkins=>Configure Systems and find the GIT

Click on the Advanced setting there and check on the “Specify another hook URL for GitHub configuration” and we need to copy the URL specified there.

This URL is the web hook to our Jenkins and we’ll be adding this to our GitHub repository. Navigate to your repository and click on settings tab as shown below,

Also, we have to go to our Jenkins dashboard and select the job we created and click on configure and navigate to Build Trigger and click on the check box GitHub hook trigger for GITScm polling

If everything goes fine, we can do some change in the readme file of the repository and push it which will trigger an automatic build in the Jenkins.

 

Jenkins – An Introduction

Jenkins is a Continuous Integration, Continous Deployment (CI/CD)tool. Jenkins is written in Java and released as open source product. It’s used heavily in Continuous Integration as it allows code to be build deployed and tested automatically. For software development, you can hook it up with most code repo’s and there are loads of plugins that you can integrate with various software tools for better technical governance. Think it as a very advanced task scheduler which can do workflow or as a middle man between your code repo and your build server which triggers a build for every change made in the source code repository.

Jenkins offers the following major features out of the box, and much more can be added through plugins:

  1. Easy installation: Just run java -jar jenkins.war, deploy it in a servlet container or install with any native package manager. No additional install, no database.
  2. Easy configuration: Jenkins can be configured entirely from its user-friendly web GUI.
  3. Rich plugin ecosystem: Jenkins integrates with virtually every SCM or build tool that exists.
  4. Extensibility: Most parts of Jenkins can be extended and modified, and it’s easy to create new Jenkins plugins.
  5. Distributed builds: Jenkins can distribute build/test loads to multiple computers with different operating systems.

Jenkins is pretty much understood after you’ll understand the terms Continous Integration and Continous Deployment (Delivery).

The relevant terms here are “Continuous Integration” and “Continuous Deployment”, often used together and abbreviated as CI/CD. Originally Continuous Integration means that you run your “integration tests” at every code change while Continuous Delivery means that you automatically deploy every change that passes your tests. However recently the term CI/CD is being used in a more general way to represent everything related to automation of the pipeline from where a developer adds his change to a central repository until that code ends up in production. This post is based on the latter meaning of the terms CI/CD.

CI system gathers all your code from different developers and makes sure it compiles and build fine. Once the code is built it deploys it on the test server for testing. Once you’re made sure the build compiles fine then, Jenkins can be tuned to deploy the application on the production server satisfying the goal of CD. There are many different ways in which Jenkins can be set up to drive a CI/CD pipeline. This details provided below describes a simple yet powerful configuration:

The pipeline consists of 4 steps: “Build”, “Unit”, “Integration”, “System” and “Deploy”

Each step is implemented as a Jenkins job of type “free-style software project”.

The first step (“Build”) is connected to a version control system. This step can either poll the repository, get notified via a webhook, or run on a schedule or on demand. Subsequent steps have a build trigger that starts the job when the previous step finished.
Artifacts are copied between the different jobs via the “Copy Artifact” plugin. This requires the “Archive Artifacts” setting to be enabled. Deploy triggers from “Copy Artifact” to a Configuration Manager which will trigger a Container service to deploy the new application.

As told earlier in this post we can install Jenkins using the native package available for the respective Operating System. This is detailed in another post which you can read here. There is another way of installing the Jenkins which we’ll be discussing here and consist of 2 steps,

  1. Install the latest version of Apache tomcat
  2. Download and Deploy Jenkins war file

As a prerequisite, we will be installing Java which can be installed with yum command.

# yum install java-1.8.0-openjdk-devel.x86_64

[root@devopsnode1 ~]# java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
[root@devopsnode1 ~]#

After Java is installed we’ll set the Java path as below:

[root@devopsnode1 ~]# cp /etc/profile /etc/profile_orig
[root@devopsnode1 ~]# echo "export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk" | tee -a /etc/profile
export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk
[root@devopsnode1 ~]# echo "export JRE_HOME=/usr/lib/jvm/jre" | tee -a /etc/profile
export JRE_HOME=/usr/lib/jvm/jre
[root@devopsnode1 ~]# source /etc/profile
[root@devopsnode1 ~]# echo $JAVA_HOME;echo $JRE_HOME
/usr/lib/jvm/jre-1.8.0-openjdk
/usr/lib/jvm/jre
[root@devopsnode1 ~]#

Now we’ll be installing the latest version of Apache tomcat. We’ll be using the wget command to download the latest Apache tomcat tarball from the website http://tomcat.apache.org/download-90.cgi

[ajoy@devopsnode1 ~]$ wget http://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.0.M17/bin/apache-tomcat-9.0.0.M17.tar.gz

After the tarball is downloaded we’ll extract it and rename the directory to tomcat9, though the renaming is not mandatory step we’ll do it for having a simple tomcat paths 🙂

[ajoy@devopsnode1 ~]$ tar zxf apache-tomcat-9.0.0.M17.tar.gz
[ajoy@devopsnode1 ~]$ mv apache-tomcat-9.0.0.M17 tomcat9
[ajoy@devopsnode1 ~]$ ls
apache-tomcat-9.0.0.M17.tar.gz tomcat9

We’ll have to set roles and users in the tomcat configuration and then start the tomcat server:

[ajoy@devopsnode1 ~]$ cp /home/ajoy/tomcat9/conf/tomcat-users.xml /home/ajoy/tomcat-users.xml_orig
[ajoy@devopsnode1 ~]$ vi tomcat9/conf/tomcat-users.xml

<tomcat-users xmlns=”http://tomcat.apache.org/xml”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://tomcat.apache.org/xml tomcat-users.xsd”
version=”1.0″>
<role rolename=”manager-gui”/>
<role rolename=”manager-script”/>
<role rolename=”manager-jmx”/>
<role rolename=”manager-status”/>
<role rolename=”admin-gui”/>
<role rolename=”admin-script”/>
<user username=”ajoy” password=”ajoy” roles=”manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script”/>
</tomcat-users>

Starting Apache tomcat server:

[ajoy@devopsnode1 tomcat9]$ cd bin/
[ajoy@devopsnode1 bin]$ ./startup.sh
Using CATALINA_BASE: /home/ajoy/tomcat9
Using CATALINA_HOME: /home/ajoy/tomcat9
Using CATALINA_TMPDIR: /home/ajoy/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/jre
Using CLASSPATH: /home/ajoy/tomcat9/bin/bootstrap.jar:/home/ajoy/tomcat9/bin/tomcat-juli.jar
Tomcat started.
[ajoy@devopsnode1 bin]$

If everything is fine you’ll be able to browse to http://localhost:8080 which will open the default tomcat web page.

Shutting down Apache tomcat server:

[ajoy@devopsnode1 tomcat9]$ cd bin/
[ajoy@devopsnode1 bin]$ ./shutdown.sh
Using CATALINA_BASE: /home/ajoy/tomcat9
Using CATALINA_HOME: /home/ajoy/tomcat9
Using CATALINA_TMPDIR: /home/ajoy/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/jre
Using CLASSPATH: /home/ajoy/tomcat9/bin/bootstrap.jar:/home/ajoy/tomcat9/bin/tomcat-juli.jar
[ajoy@devopsnode1 bin]$

Now our tomcat server is up and running we’ll now download the Jenkins war file and deploy it in tomcat.

[ajoy@devopsnode1 ~]$ wget http://ftp.yz.yamagata-u.ac.jp/pub/misc/jenkins/war/2.44/jenkins.war

Click on the Manager App button. It will ask for username and password which we have put in the “tomcat-users.xml”.

We’ll provide a Context Path and specify our Jenkins war file with an absolute path and then click on Deploy.

Once it’s deployed you can access the Jenkins as shown above.

Using the cat command open the file and to copy the password and paste it on the Unlock screen.

[ajoy@devopsnode1 ~]$ cat /home/ajoy/.jenkins/secrets/initialAdminPassword

Follow the below screenshot sequences to complete the Jenkins setup:

That’s all folks, you’re ready to build your project with award-winning, cross-platform, continuous integration and continuous delivery application that increases your productivity. You can read here another post describing the build steps.

Data Source Courtesy: Jenkins JenkinsWiki, Quora,

Git Cheat Sheet

This post is a Git cheat sheet, which git users can bookmark so that you’ll have most basic Git commands handy. A more detailed post about git installation and commit can be seen here

General Git Commands

$ git –version ==> Displays the version fo the git installed

$ git config –global alias.st status ==> Create an alias for git status

$ git help ==> Displays help on the git command

$ git init ==> Initialize git

$ git add . ==> Make everything in CWD ready to commit

$ git add index.html ==> Make one file ready to commit

$ git commit -m “Message” ==> Commit changes

$ git commit -am “Message” ==> Add file and Commit in one commad

$ git rm index.html ==> Remove files from git

$ git add -u ==> Update all changes

$ git rm –cached index.html ==> Remove & not to track a file any more

$ git mv index.html dir/index_new.html ==> Move or Rename files

$ git checkout — index.html ==> Restore file from a latest commit

$ git checkout 6eb715d — index.html ==> Restore file from a custom commit of current branch

$ git clean -n ==> Delete dry run of untracked files

$ git clean -f ==> Delete untracked files

$ git reset HEAD index.html ==> Undo adds

$ git commit –amend -m “Message” ==> Commit to most recent commit

$ git commit –amend -m “New Message” ==> Update most recent commit message

Tagging and Branching and Merging

$ git tag ==> Show all released version

$ git tag -l -n1 ==> Show all released versions with comments

$ git tag v1.0.0 ==> Create release version

$ git tag -a v1.0.0 -m ‘Message’ ==> Create release version with comment

$ git checkout v1.0.0 ==> Checkout a specific release version

$ git branch ==> Show branches

$ git branch branchname ==> Create branch

$ git checkout branchname ==> Change to a branch

$ git checkout -b branchname ==> Create and change to a branch

$ git branch -m branchname new_branchname

or ==> Rename a branch

$ git branch –move branchname new_branchname

$ git branch –merged ==> List all completely merged branch with current one

$ git branch -d branchname

or ==> Delete merged branch

$ git branch –delete branchname

$ git branch -D branch_to_delete ==> Delete not merged branch

$ git merge branchname ==> True Merge

$ git merge –ff-only branchname ==> Merge to Master

$ git merge –no-ff branchname ==> Merge to master/force a new commit

$ git merge –abort ==> Stop merge

Working with remote Git/GitHub

$ git remote ==> Show remote

$ git remote -v ==> Show remote details

$ git remote add origin https://github.com/user/project.git ==> Add remote origin from GitHub project

$ git remote add origin ssh://root@123.123.123.123/path/to/repository/.git ==> Ad remote origin from existing empty project

$ git remote rm origin ==> Remove origin

$ git branch -r ==> Show remote branches

$ git branch -a ==> Show all branches

$ git diff origin/master..master ==> Compare

$ git push -u origin master ==> Default push/set default with -u

$ git push origin master ==> Push to default

$ git fetch origin ==> Fetch

$ git pull ==> Pull

$ git pull origin branchname ==> Pull specific branch

$ git merge origin/master ==> Merge fetched commits

$ git clone https://github.com/user/project.git or: git clone ssh://user@domain.com/~/dir/.git ==> Clone to local system

$ git clone https://github.com/user/project.git ~/dir/folder ==> Clone to a local folder

$ git clone -b branchname https://github.com/user/project.git ==> Clone specific branch to local host

$ git push origin :branchname or: git push origin –delete branchname ==> Delete remote branch/Push nothing

Git Logs

$ git log ==> Show commits

$ git log –oneline ==> Show oneline summary of commits

$ git log –oneline -3 ==> Show oneline summary of last three commits

$ git log –author=”Sven” git log –grep=”Message” git log –until=2013-01-01 git log –since=2013-01-01 ==> Show only custom commits

$ git log -p ==> Show changes

$ git log –stat –summary ==> Show status and summary of commits

$ git log –graph ==> Show history of commits as graph

$ git log –oneline –graph –all –decorate ==> Show history of commits as graph summary

Archiving

$ git archive –format zip –output filename.zip master ==> Create a zip archive

$ git log –author=sven –all > log.txt ==> Write custom logs to a file

And finally a useful template for creating .gitignore,

.gitignore Templates

 

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