Advanced Git Commands And GitHub Integration Tutorial

This Tutorial Explores Useful Git Commands such as Git Stash, Git Reset, Git Cherry Pick, Git Bisect & Explains how to Integrate GitHub with Jira:

In our previous tutorials in this series, we have seen most of the features of GitHub.

In this tutorial, we will look at the following:

  • Creating Releases
  • Integration with Atlassian Jira
  • Most commonly used Git commands for Developers
    • Git Stash
    • Git Cherry Pick
    • Git Reset
    • Git Bisect

=> Take A Look At The GitHub Guide Here.

Advanced Git Commands

Creating Releases

Releases in GitHub is used to bundle your software, add release notes and binaries (WAR, EAR, JAR files) for customers and people to use the same.

To create a Release, go to the main page of the repository and click on the Releases tab under Manage topics.

Releases Tab

Click on Create a New Release.

Create a new release

Provide a Tag and a Release title. The binaries are also added to the release. Once done click on Publish Release.

Release Published

The release is now ready with the source code and binaries.

GitHub Integration With Jira

One of the important traceability aspects is to reference the Jira issue with the commits in GitHub. GitHub can be integrated with Jira not only just to reference the issue but also to help create branches and Pull Request from within Jira.

So typically, once the developer starts to work on the task or bugs, a branch is created by him. Post the development or resolving the bugs a pull request can be created from Jira to merge to the main master branch. The branch created by the developer can then be deleted.

To set up the integration, we have used a plugin Git Integration for Jira. This is a commercial plugin. The plugin can be downloaded from here

Install the plugin in Jira from Admin -> Add-ons.

Install Plug in

Once the plugin is installed go to Application -> Git Repositories and connect to GitHub.

Connect to Git Repositories

Enter the GitHub username and password. Click Connect.

Enter GitHub Username and Password

The repositories mentioned for the user account will be displayed. Click on Import Repositories to finish the integration setup.

Import repositories

GitHub Commit With Jira Issue

As a part of the commit message enter as shown below. Click on Commit Changes.

Example 1: Below is an example of Smart Commit which allows the developers to perform actions on the Jira issues from the commit message. One such command is the #comment along with the Issue key that adds the comment to the Jira issue as shown below.

Click on Commit changes

Git Commits

Comments section updated.

Comments section updated

Example 2: Assign to a user and update time spent as 4 h.

Use the #assign and #time smart commit command in the commit message.

Assign to a user and update time spent

Both the actions have been completed.

Actions completed

Example 3: Change the status of the issue to In Progress.

Status Change to In Progress

Implement Reset Feature

Create A Branch

As tasks and bugs are assigned to developers, they need to start working on the development. For this they create a branch for the issue they are working on, do the development activities and raise a pull request to merge into the master branch.

In the Jira issue at the bottom click on Create Branch.

Create Branch

Create Branch Page

Click on Create branch.

In GitHub, make a change to the file in the above-created branch and commit the same.

Make change to file in created branch

As the development is completed the user can then raise a Pull Request from Jira.

At the bottom of the issue click on Create Pull Request.

Pull request

Create pull request page

Click on Create. The Pull Request will be shown as Open.

Pull request is show as Open

The next step is to merge the pull request in GitHub.

Merge the pull request in GitHub

The status is updated accordingly in Jira.

Status is updated accordingly in Jira

Advanced Git Commands For Developers

In this last section, we will look at some of the commonly used Git commands for developers. Nothing to do with GitHub but will aid the developers before they push the changes to GitHub.

Git Stash

In most of the project scenarios when you are working on a new feature or enhancement, suddenly there would be a need for you to work on an urgent defect that has been reported and is a show stopper. As you are midway into your new work and not completed it there is no point in committing the changes which are half done.

So, it is better to suspend or save the half-done work temporarily, work on the bug and come back to work on the new feature or enhancement. Git stash provides a solution to this. You can easily switch the context of doing changes quickly.

Example 1: Assume that you are working on a task assigned to you and when you look at the status, it shows that it is untracked as of now.

Example of Git Stash

Suddenly there is a high priority bug assigned to you. Thus, we need to temporarily save or stash the work currently being worked on.

Run the following command.

git stash save “Message”

Temporarily Save or Stash the work

At this moment the working directory is clean. Any new commits can be made and if there are bugs then you may switch branch to work on it etc.

When you want to re-apply the changes where you had left, use the command.

git stash pop

The above command will remove the stash from the list and will apply the last saved state.

You can also use:

git stash apply

The above command will keep the changes in the stash and not remove them.

Git Stash Apply

Now the changes are reapplied and you can commit the changes.

Example 2: Stash your changes, switch branch and merge changes.

Make the change to the Html file in the master branch and stash changes.

Example 2 Stash your changes

Next is to switch to the bug branch, make changes and commit changes.

git checkout -b bug

Make changes to the Html file.

git commit -a -m “Fixed email issue”

Switch back to the master branch and reapply changes from stash.

Switch back to master branch

Now merge from the bug branch to the master branch. Commit the changes after the merge.

Bug branch to the Master branch

Git Status

Example 3: Working with Multiple Stash.

In the local repo, there are 2 Html files. So, it is possible that multiple developers would work on multiple files and stash changes as needed to work on urgent requests that come their way to fix the changes.

Developer 1 works on hello.html and Developer 2 works on index.html.

Example 3 Working with Multiple stash

Developer 1

Developer 1

Stash list has 1 entry now.

Developer 2

Developer 2

Stash list now has 2 entries. The latest stash is first in the stack which is stash@{0}. Now both the developers can do any other commits urgently or work on some other branch and then come back to the master branch and apply the stash changes.

To apply the latest stash, you can just run

git stash pop

To apply a specific stash in the stack run the following command.

git stash pop stash@{1}

Let’s apply the second stash which is stash@{1}

Apply a specific stash in the stack

Similarly, the other stash can be applied.

Git Cherry Pick

Today, the developers work on multiple branches like feature, enhancement, bug, etc.

There are situations where only a couple of specific commits need to be picked and not merge the entire branch into another branch. This is called a Cherry Pick. This process allows you to arbitrarily pick any Git commit from the other branches and append it to the current HEAD of the working tree.

Example 1:

In the local git repository, we have the following 6 files.

Git Cherry-pick Example 1

One file is deleted say file5.txt.

Delete one file

Commit the changes.

Commit the changes after delete

Look at the log now. File5.txt is deleted.

File5.txt is deleted

So, we want to Cherry-Pick the commit where we added file5.txt. We need to find the commit id of file5.tx and run the command.

git cherry-pick <Commit-Id>

In this case, the commit id of when file5.txt was added is a2f0124

file5.txt was added is a2f0124

File5.txt is now restored. We Cherry-Picked the commit.

Example 2:

Let’s just modify file6.txt and commit the changes in the master branch.

Look at the second line in file6.txt where the email is not specified correctly.

Email is not specified correctly

Create a bug branch and fix the issue. At the same time modify file5.txt as well so that we have multiple commits done in the bug branch but will Cherry-Pick only the commit done in file6.txt.

File6 modified in bug branch.

File6 modified in bug branch

So, overall, we have done changes to file5 and file6 in the Bug branch.

changes to file5 and file6

Let’s now switch back to the master branch and Cherry-Pick the commit done for file6.txt only.

Back to the master branch

As you can see that instead of merging the bug branch into the master branch, we have just Cherry-Picked only a specific commit and applied in the master branch.

Git Reset

Git reset is a powerful command to undo local changes. So, to un-stage, all the staged files this command is used.


Modify a file and add it to staging

Modify a file and add it to staging. Reset using the command as shown when the staged changes are unstaged.

Parameters of git reset command.

–soft: This parameter will point the HEAD to another commit. All files are changed between the original HEAD and the commit will be staged. The working directory is intact.

Look at the current HEAD location.

Look at the current HEAD location

Let’s go back 5 commits in the history.

Go back 5 commits

Re-Commit the changes.

Re-Commit the changes

–mixed: The option is similar to the soft parameter. Usually, when there are some bad commits, you remove them and fix it later and commit it back. So essentially, we need to add to index using git add and then git commit. Changes are left in the working tree.

Let’s go back 2 commits in history and see that the files are untracked.

Go back 2 commits

Now add the files to staging and commit the changes.

Add the files to staging and commit changes

Git log-oneline

–hard: This parameter will rest to a point where a particular file existed. The changes will not be available in the working tree.

Looking at the above log lets go back to the point where only file 1 was committed i.e. the last entry.

Using git reset –hard <CommitID>

Using git reset-hard (CommitID)

Git Bisect

Find the exact commit which broke the code (We all are humans after all). Often during testing of the application, we hear from our testers that there is a bug or the feature is broken and you as the developer will say that it worked last week. So, what happened and why did this bug appear?

Sometimes a change in the other code could have impacted your feature. You have to spend time going through the history where there are lots of commits that is time-consuming and hard to track which change caused the code to break.

Git Bisect is the command to find the exact commit when the bug was introduced. With Git bisect you need to pick two commits, one good and one bad. About halfway between both commits will be checked out. You check each commit either bad or good until the commit that caused the bug or code to break is found.


  • Create a new local git repository and create a file called index.html
  • Initial contents of the file as shown.

Initial contents of the file

  • Add to staging and commit to the repository.

Add to staging and commit to repository

  • Create a history of commits as shown, so that we can choose between good and bad commits. Now as the initial commit is done do the other changes as shown and commit the same. Overall, we will do 7 commits.

Second Change

Second change

Second change Initial Commit

Third Change

Third Change

Third Change initial commit

Fourth Change

Fourth Change

Fourth Change Initial commit

Fifth Change

Fifth Change

Fifth Change Initial Commit

Sixth Change

Sixth Change

Sixth Change initial Commit

Seventh Change

Seventh Change

Seventh Change Initial Commit

Let’s stop here. So, we have seven commits.

If you look at the Html page, the lines after “All the 4 events … “are wrong and thus the documentation is not correct. So, we need to find the commit where the error was introduced so that we can rest our HEAD to that commit.

Need to find the commit with error

Let’s look at the log and find out the bad and good commit.

Bad and good commit

The latest commit is not right, so it can be a bad commit. The commit was introduced after the third commit, so we can have the Third Change as the good commit.

The process of bisecting starts with git bisect start and ends with git bisect reset.

Process of bisecting

git bisect bad // As latest commit is bad. No need to provide the commit id.

git bisect good <Commit Id of third change>

You can now see that HEAD is now in between half of the bad and good commit.

Half way of bad and good commit

Look at the content of index.html and see if there is a good commit. If not, then the error is still not found.

Look at the content of index.html

Not really that the error still exists. The last line is wrong. So, we run ‘git bisect bad’. There is still a bad commit and the current content is not acceptable.

Run ‘git bisect bad’

The above content is correct and acceptable.

Run ‘git log –oneline’ and ‘git bisect good’.

Run ‘git log --oneline’ and ‘git bisect good’

So, the Fifth Change was the first bad commit and truly so. The error is identified.

The current content should be in the final documentation.

final documentation

As the bad commit is identified you can inform the developer to correct the changes that may be to reset the head to the fourth change which was the last good commit.

Run ‘git bisect reset’ to end the process.

Run ‘git bisect reset’ to end the process.


In this GitHub hands-on primer, we have tried to cover all that a developer would need to work on i.e. from version control and tracking point of view.

In the first three tutorials of the GitHub series we have learned about version control activities, creating repositories, pull request, branches, code reviews, organizations & teams, fork a repository, labels, milestones, issues, project boards, wikis, releases, integration with Jira and some commonly used Git commands for developers.

We truly hope that all the developers would find this hands-on approach for GitHub and the Git commands useful in their projects.

=> Read Through The Easy GitHub Training Series.