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.
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.
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.
Before starting work on the hotfix, commit the incomplete changes on this current branch.
Step 3 - Switch back to master branch
Switch back to the master branch by right-clicking the EJB project > Team > Switch To > master
After switching back to master, observe that the logic has been rolled back to its previous state.
Step 4 - Work on hotfix on a new branch
Create a new branch to work on the changes required for the hotfix.
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.
Commit the changes for the hotfix in the fix_nullpointer branch.
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.
Right click on the fix_nullpointer branch and select Merge.
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.
At this point, all the changes in fix_nullpointer has already been incorporated into master, so the branch can be deleted.
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.
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.
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.
The source code now automatically includes the changes introduced by the hotfix.
Work is continued on the change request to produce the final source code below.
The final logic is committed into the flexi_namespace branch.
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.
Switch to master branch. Then right click on flexi_namespace branch and select Merge.
Following is the merge result as well as the updated History view.
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.
And the final source code contains all the changes from both the hotfix and change request developments.
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