End of November Oracle released a new JDeveloper version 126.96.36.199.0 Build 6229 (What’s new 188.8.131.52.0) which introduces Git support as one of the new features.
Part 1 showed how to setup and use git integration in JDeveloper
In part 2 of the series I show how branching and merging are done using the git integration in JDeveloper.
Let’s start with a picture of the current git repository:
Here is the first missing part in JDeveloper’s git integration. There is no visual representation of the whole repository available as shown in the image above. To get such a representation we need to install a third party tool (msysGit in my case, or Tortoise Git which can run in parallel on a Win7 machine). JDeveloper only allows you to see the history of one file via the ‘Version History’ menu. The images of the repository we’ll see in this blog are done with msysGit.
As we see there is only one branch named ‘Master’ and we see a straight line of dots, each representing a commit to the ‘Master’ branch. We start by adding a new branch to the repository named ‘AddCalcuatorClass’. The name of the branch can be almost anything, as long as it doesn’t contain spaces. We choose the name of a branch so that it reminds us later why we created the branch, or what it’s used for. As the name of the branch indicates we add a class to the project which implements a simple calculator.
Name the new branch ‘AddCalcuatorClass’
The ‘Application Navigator’ did not change, but the new branch is visible in the ‘Version Navigator’ in JDevelpoer
the same from the view of msysGit:
We need to play close attention to the different views and what they tell us. In JDeveloper we still see ‘[master]’ behind the project name. This tells us that we are still working on the ‘master’ branch and not the new created branch ‘AddCalculatorClass’. The msysGit image shows the same as the ‘master’ branch is printed in bold (which it does for the current branch).
To switch to the new branch we need to checkout the branch.
then click the ‘Select Branch’ button in the dialog to get to the available branches and select the ‘AddCalculatorClass’ and click ‘OK’, finally close the dialog by clicking ‘OK’ again.
After that we are working on the ‘AddCalculatorClass’ branch, only we don’t see it right away. We need to refresh the project (e.g. clicking the refresh button) to see the ‘[AddCalculatorClass]’ right to the project name.
Again the msysGit image:
Now we add a new class ‘Calculator’ to the project. For this we add the new class from the ‘Candidate’ tab and then commit the new file by committing it
Now we add an other method in the calculator class which should multiply to parameters and return the result. After that we commit the change and the repository looks like:
Let’s assume that we have to fix a bug in the main development path, which is ‘master’. We have to switch back to the ‘master’ branch. This is done by checking out the ‘master’ branch again. The procedure is the same we already saw before. The result in JDeveloper looks like:
As we see the new class ‘Calculator’ is not part of the project as it was not added in the ‘master’ branch. Back to the ‘master’ branch we add another class ‘Stack.java’ and add some lined to the existing class. After committing the changes, in multiple commit cycles to get a better visibility of the different branches, the repository look like:
Let’s switch back to the ‘AddCaclulatorClass’ branch to finish the work on this class by adding two more methods to subtract and divide to parameters. After this work is done the repository look like:
A requirement is that we need the changes done in the ‘master’ branch now need in our current branch ‘AddCalculatorClass’. For this we need to merge the branch ‘master’ to the current branch ‘AddCalculatorClass’. This is easily archived by opening the ‘Version Navigator’, open the node of the project and then the open the ‘Branches’, ‘Local’node. Here we see the currently available branches ‘master’ and ‘AddCalculatorClass’. The same can be archived by right clicking the Project and select ‘Versioning->Merge…’.
Don’t forget to refresh the project to see the added class. The resulting repository now looks like
with all changes made to the branch ‘master’ including the new class Stack. We could have done the merge the other way around. Then we had to checkout branch ‘master’ and then merge branch ‘AddCalculatorClass’. This would give us a repository looking like:
The difference at this moment is, that the changes are visible in the ‘master’ branch and which branch is active after the merge. We can create another branch from every other tag or branch currently present in the repository. Let’s make a new branch ‘DoCalcDifferent’ from the ‘master’ branch. Remember that we are currently in branch ‘AddCalculatorClass’. Still we are able to create the new branch. We can also create a branch based onany other branch like ‘AddCalculatorClass’ which we call ‘AddCalc2’. A look at the repository after all this:
We see it’s easy to create new branches, switch between them to do some work, merge the different branches without problems. Make yourself familiar with the technique and how to use it. This is especially true after some wild changes to different branches. We may end up with a confusing repository like
where it’s not obvious which change created which node in the repository. It may take a while, but in the end it’s much easier then it looks and it’s more productive then SVN or CVS.
Learning to use git the integration into JDeveloper is a good start. However, we need some of the other git commands (e.g. cherry pick) or representations (gitk to view the whole repository) integrated into JDeveloper to make it really a great tool integration.
I have planned a third part for this series, but can’t really tell when it is going to happen. This 3rd part covers remote git repositories which add a new dimension to the git picture. Right now I don’t have a remote git repository available. I’m looking into this issue in the next couple of days/weeks and hopefully get one installed and running.