Why Use Git With JDeveloper?

If you’re a JDeveloper user and haven’t noticed yet – the JDeveloper version has been update with support for the git source control repository. If you’re looking for great detail on how to use the repository integration itself, I’ll point you to the first of (hopefully a few) articles on using git with JDeveloper by Timo Hahn. Timo has done a great job of taking screenshots detailing the features of the JDeveloper integration – so I’ll happily point you Timo’s article for details.

(For a general overview and a general test drive of git, take a look at this tutorial from GitHub.)

What I would like to address is the reason to be either excited about this, or if you are new to source control systems in general, totally confused. Because JDeveloper (and nearly every IDE) has included support for cvs or subversion for a long time – why git?1

Distributed Source Control

I’ll demonstrate the main difference between git and other source control systems by looking at the menu of commands available to JDeveloper users in a controlled file:

Git commands menu

You’ll notice a number of commands that may not be famliar with names like ‘pull’, ‘push’, ‘fetch’. The additional commands in the menu are due to the decentralized nature of git. To explain what a decentralized source control system is, let’s compare with a tradition (CVS, SVN) client-server source control system.

Svn workflow

In a client-server source control system, working copies are directly tied to a repository hosted on the server – histories, statuses, checkouts and updates are performed on a server repository. These repositories can be “main” repositories or perhaps branches. All information about the history of the source tree is maintained with the server.

Git workflow

A distributed source control system like git relies on the concept of repository cloning. When a source repository is cloned, all information about the source tree is copied to a local repository, with all changes and commits in a working copy being kept locally. Changes the source tree are communicated to the blessed repository through a git push command. (A blessed repository is often a shared server that is running the git daemon in a corporate environment or a github repository, etc.)

What happens in practical terms is that a developer’s source checkout is entirely isolated from the main source repository, with changes only communicated with ‘push’ commands. This frees developers to create and maintain different branches or working copies where developers may be working on different features or bugfixes without needing to keep branches on the shared server.2

Two Advantages in Using Git

The distributed nature of the repository grants developers a few advantages and from the perspective of a software development team encourages two positive behaviors:

Frequent Commits: With Git, commit operations are local and isolated from server operations. Most developers (especially ADF developers) have been in the situation where a commit is not as atomic as one would hope. Files could be missing from the repository, changelists may be improperly maintained or merges could be left incomplete from prior operations. If the repository is ‘local’, then commits are cheaper operations and the local repository can allow developers to keep a history and allow rollback operations against a local copy rather than a shared server resource. Keeping the repository ‘local’ also isolates developers working on specific features from needing to constantly merge changes to a shared respository until the developer rebases (using either pull or fetch commands) a local working copy to the shared repository.

Cleaner Merging: If developers are allowed to perform commit operations against a local database, merges with shared repositories can be done following feature completion. This can help keep developers ‘in the flow’ when it comes to working on specific code features rather than being interrupted with a constant need to update and merge local copies. Keeping a local repository in sync with working copies and the shared repository also keeps the merges local – allowing developers to merge (and test merges) without interfering with other operations against the shared repository.

Advantages for ADF Developers

Development teams that have been working with ADF for any period of time are also likely familiar with the challenges of keeping a shared source repository ‘clean’. Oracle ADF source trees contain many XML descriptors (Application Modules, Data Controls, etc.) that have the effect of breaking builds if XML files have not been properly merged. Application Modules can be particularly problematic if they are a shared resource amongst a team of developers – a ‘broken’ merge can often sideline an entire team until the XML files are properly merged and checked in. Git was designed to make maintenance of large and complicated codebases easier3 – ADF is often a great example of a ‘large and complicated codebase’.

What git won’t solve for ADF developers is the problems in working with dev databases – though database scripts that are maintained and applied using tools like puppet can help in those regards.

A Few Shortcomings with the JDeveloper Integration

A few items in the existing integration that I struggled with in my limited testing (at the moment this is a ‘your milage may vary’ and will likely result in a few ERs) :

  1. Because JDeveloper source control integrations are designed with client/server systems in mind, keep in mind that the ‘status’ indicators reflect the status of your working files against your local repositories. There’s not a clear indication that a source file has been ‘pushed’ to remote repositories. (In many aspects – it really shouldn’t, though developers used to using client/server systems won’t have a clear indicator that a change has been ‘pushed’ to a shared repository.)
  2. I did have some issues merging between local and remote repositories – the dialogs available in JDeveloper are not quite as simple conceptually as some native GUI clients or even the command line tools. Fortunately the local repositories can be manipulated with other tools, and JDeveloper users may wish to keep external git tools close at hand when dealing with repository operations.


This integration is, of course, a fantastic addition to JDeveloper for many ADF / Java developers. Being able to perform operations on local Git repositories will be familiar to most JDeveloper users – and having the integrated status indicators and menu options will make working with git repositories vastly simpler than my current experiences in working with JDeveloper and github. I hope other developers will find this as useful as I do!

  1. I use GitHub for personal project hosting myself; you can checkout my personal profile and public repositories listed on my github profile 

  2. Some IDEs, such as JetBrains IntelliJ IDEA have features built in that attempt to mimic the concepts of distributed source control with ‘Local History’ functionality. Git keeps the concept of local histories consistent with the repository itself. 

  3. The git source control system was designed, of course, for the maintenance of the Linux kernel. While ADF projects may get large and complex, I’ll safely assume that binding files are easier to deal with than multiple processor architectures.