Introduction

If you are already using EGit for Java source code management in NWDS, you can sleep sound at night knowing that the versions of your codes are safe and sound This may encourage you to be more daring in trying new changes for your logic, knowing that you have the ability to rollback to a previous version of the code.

Without such a version management system, you would have to manually save copies of source codes, and manually restore them (one by one!) in the event a rollback is required.

In this post, I will share about basic branching and merging in EGit. The branches concept in EGit allows developers to juggle between multiple development requests while maintaining a consistent state of the source codes.

Example Use Case

A simple example of the usage of branches is as follows:-

i) Working on a change request for a development object

ii) Receive an urgent production issue for the same object in the midst of the change request

iii) Complete the production fix

iv) Switch back to the change request and incorporate changes from the production fix

v) Complete change request

Prerequisite

EGit has to be installed and configured correctly as described in the following post:-

Using EGit for Java source code management in NWDS

Step By Step Approach

To illustrate the usage of branching and merging in EGit, we will walk through the above use case with a custom adapter module development. For the sake of simplicity, the logic is just a passthrough scenario which adds a prefix to the filename when it does not begin with “Test”.

Step 1 – Initial state of development object

To begin using branching and merging in EGit, it is recommended that the current state of the Git repository is clean, whereby all/any changes have already been committed, i.e. meaning also nothing else to be committed.

Below is an initial screenshot of the module’s logic.

/wp-content/uploads/2016/04/logic_init_921458.png

Step 2 – Work on change request on a new branch

A change request is received to enhance the module such that it can access the file name that is stored under a configurable Dynamic Configuration attribute (instead of hard-coded to the File adapter’s namespace).

To begin with, create a new branch to work on. Right click on the EJB project > Team > Switch To > New Branch ..

Give the branch any arbitrary name as shown below, accepting default values for the rest.

/wp-content/uploads/2016/04/new_branch1_921459.png

EGit will automatically create the new branch and switch to it (also called check out the branch). Here continue making changes to the logic as shown below. However, before the changes can be completed, a hotfix request is received.

/wp-content/uploads/2016/04/logic_enhance1_921460.png

Before starting work on the hotfix, commit the incomplete changes on this current branch.

/wp-content/uploads/2016/04/commit1_921461.png

Step 3 – Switch back to master branch

Switch back to the master branch by right-clicking the EJB project > Team > Switch To > master

/wp-content/uploads/2016/04/switch_master_921462.png

After switching back to master, observe that the logic has been rolled back to its previous state.

/wp-content/uploads/2016/04/restored_921463.png

Step 4 – Work on hotfix on a new branch

Create a new branch to work on the changes required for the hotfix.

/wp-content/uploads/2016/04/new_branch2_921464.png

In the original logic, there is no check if the Dynamic Configuration value is available during runtime. If it is not, then a null pointer exception will occur. To fix this, additional exception handling logic is introduced to raise a “gentler” exception.

/wp-content/uploads/2016/04/logic_fix_921465.png

Commit the changes for the hotfix in the fix_nullpointer branch.

/wp-content/uploads/2016/04/commit2_921466.png

Step 5 – Switch back to master and merge the hotfix changes

In order to incorporate the changes done in the fix_nullpointer branch, it needs to be merged back to the master branch.

It is easier to perform merging in the Git Repository Exploring perspective, so switch to this perspective.

Switch back to master branch.

Then right click on the Git repository > Show In > History, to view the history of commits in this repository. As shown below, it displays the master branch and the two branches that came out of it.

/wp-content/uploads/2016/04/history_921467.png

Right click on the fix_nullpointer branch and select Merge.

/wp-content/uploads/2016/04/merge_fix_921455.png

The results screen will show that the master branch has been fast-forwarded and points to the same reference commit as the fix_nullpointer branch.

/wp-content/uploads/2016/04/merge_fix_result_921468.png

/wp-content/uploads/2016/04/history_merge1_921469.png

At this point, all the changes in fix_nullpointer has already been incorporated into master, so the branch can be deleted.

/wp-content/uploads/2016/04/delete_fix_921470.png

/wp-content/uploads/2016/04/delete_fix_confirm_921471.png

Step 6 – Switch back to the flexi_namespace branch and continue work on change request

Now that the hotfix has been completed (and assumed to be deployed to production), work on the change request can continue.

Switch back to flexi_namespace branch.

The logic will be rolled back to the state that it was. Notice that it does not include any of the hotfix changes.

/wp-content/uploads/2016/04/logic_flexi_restored_921472.png

In order to incorporate the hotfix related changes, the master branch needs to be merged to this flexi_namespace branch. In the History view, right click on master branch and select Merge.

/wp-content/uploads/2016/04/merge_master_921456.png

The results shows that the commits from the master branch are merged into the flexi_namespace branch and the History view updated to reflect this.

/wp-content/uploads/2016/04/merge_master_result_921473.png

/wp-content/uploads/2016/04/history_master_merge_flexi_921474.png

The source code now automatically includes the changes introduced by the hotfix.

/wp-content/uploads/2016/04/logic_merged_flexi_null_921475.png

Work is continued on the change request to produce the final source code below.

/wp-content/uploads/2016/04/logic_final_921476.png

The final logic is committed into the flexi_namespace branch.

/wp-content/uploads/2016/04/commit_final_921477.png

Step 7 – Incorporate change request into master branch

Finally, incorporate the latest changes back into the master branch to complete the development.

Switch back to master branch. Notice that the logic is per the changes introduced by the hotfix only.

/wp-content/uploads/2016/04/logic_master_921478.png

Switch to master branch. Then right click on flexi_namespace branch and select Merge.

/wp-content/uploads/2016/04/merge_flexi_921457.png

Following is the merge result as well as the updated History view.

/wp-content/uploads/2016/04/merge_flexi_result_921479.png

/wp-content/uploads/2016/04/history_after_merges_921480.png

And finally, now that all the changes have been completed and fully merged, the flexi_namespace branch is deleted, with the History view updated as shown below.

/wp-content/uploads/2016/04/history_final_921481.png

And the final source code contains all the changes from both the hotfix and change request developments.

/wp-content/uploads/2016/04/logic_merge_final_921482.png

Conclusion

As illustrated in this post, using EGit can significantly improve developer’s workflow, especially when managing multiple concurrent development requests that affect the same project. Without it, a lot of manual effort is required to save and track each line of code, and the effort increases when there are a lot of source codes involved. With EGit’s branching and merging feature, all this is handled automatically and the state of the repository is always consistent when switching between branches.

This post just illustrates a basic branching and merging example using EGit. There are more advanced techniques like rebasing which is not covered here. For further reading, refer to the following links below.

Reference

Git – Basic Branching and Merging

Merging vs. Rebasing – Conceptual overview | Atlassian Git Tutorial

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply