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.
What You Will Learn:
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.
Click on 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.
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.
Once the plugin is installed go to Application -> Git Repositories and connect to GitHub.
Enter the GitHub username and password. Click Connect.
The repositories mentioned for the user account will be displayed. Click on Import Repositories to finish the integration setup.
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.
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.
Both the actions have been completed.
Example 3: Change the status of the issue to In Progress.
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.
Click on Create branch.
In GitHub, make a change to the file in the above-created branch and commit the same.
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.
Click on Create. The Pull Request will be shown as Open.
The next step is to merge the pull request in GitHub.
The 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.
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”
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.
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.
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.
Now merge from the bug branch to the master branch. Commit the changes after the merge.
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.
Developer 1
Stash list has 1 entry now.
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}
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.
One file is deleted say file5.txt.
Commit the changes.
Look at the log now. 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 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.
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.
So, overall, we have done changes to file5 and file6 in the Bug branch.
Let’s now switch back to the master branch and Cherry-Pick the commit done for file6.txt only.
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.
Example
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.
Let’s go back 5 commits in the history.
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.
Now add the files to staging and commit the changes.
–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>
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.
Example:
- Create a new local git repository and create a file called index.html
- Initial contents of the file as shown.
- Add to staging and commit to the 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
Third Change
Fourth Change
Fifth Change
Sixth Change
Seventh Change
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.
Let’s look at the log and find out the 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.
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.
Look at the content of index.html and see if there is a good commit. If not, then the error is still not found.
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.
The above content is correct and acceptable.
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.
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.
Conclusion
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.