In this part of the ‘Git Experience’ series we are looking at GitFlow. GitFlow is a branching model which helps you and your company to structure your work in a way which is understandable and has proven it’s value in many projects. I don’t want to copy all information given in the link about GitFolw but only use the image from the blog post:

GitFlow Model
What we see in this image is a timeline of development with releases, hot fixes, development and feature branches and how they work together. We like to use this model to structure the work of the development. The development needs to set up the software for releases which are delivered to the customer or an internal server. Then there is the need to supply hot fixes if a release version has a major bug. Nevertheless development has to develop for the next release, probably breaking the task into smaller pieces we call features. To keep this features in our repository as well we use feature branches which are merged back to the development branch once they are ready and tested.
The development branch is the grapevine for the development. Feature branches as well as release branches are started from the development branch. Once a release is ready the release branch is merged and tagged on the master branch and merged to the development branch.
IMPORTANT: you never work directly on the master branch!
In the last part ‘The Git Experience (Part 3)’ we started a new repository on GitHub which we use in this part to introduce GitFlow on it. There are several ways to do this. You can use the command line and execute the git commands from there. Or you use shell scripts to put multiple git commands as a unit of work together and call the script to e.g. start a new feature branch. The last and least complicated way is to use a tool which already has set up the scripts for you and gives you a nice GUI to work with.
We follow the last suggested way and use a tool with graphical user interface. As JDeveloper does not support the usage of GitFlow with a GUI we use an external tool like ‘SmartGit’ or ‘Source Tree’ which both come with a graphical user interface supporting GitFlow. For the remainder of this blog we use SmartGit as it’s available for Windows and Linux operating systems. It’s free for non commercial use.
Once we started SmartGit we can add our local repository to be shown in SmartGit. Don’t be confused this with cloning a repository. Cloning fetches a remote repository from a remote server and creates a local copy of it on your pc. As we already have the local repository on out machines we just add the local repository.
-
-
Add Local Repository
-
-
Select Local Path
-
-
View the added Repository
For those of you how did not create the repository in the last part you can clone it from my GitHub server repository using ‘https://github.com/tompeez/BlogReadConfigFile.git’ as url for the clone command.
-
-
Clone a remote Repository
-
-
Clone URL
-
-
Select what to Clone
-
-
Select Local Path
After this SmartGit looks the same as the last image after adding the repository. You now can play with the SmartGit UI (or any other too you are using). One thing I like to bring to attention is the ‘Log’ button. Clicking this button opens a new window which shows the timeline of all commits.
-
-
Log Button
-
-
Timeline View
Right now we only see two nodes which were created during creation of the repository.
Let the fun begin: Introduce GitFlow to the project
Now that the local repository is up in the tool of choise, lets introduce GitFlow to it. For this we click the GitFlow Button, select the ‘Full’ radio button and leave the rest of the options as is.
-
-
GitFlow Button
-
-
Configure GitFlow
This will add another branch to the repository named ‘develop’

Repository after GitFlow Introduction
However, this new branch is not the current branch as the ‘master’ branch is still marked current. Please also note the different color of the GitFlow button. In this shape it starts a HotFix as the master branch is the current branch and all hot fixes are started from the master branch, or better a release tag on the master branch.

GitFlow Button: Start HotFix
We change this by double clicking the develop branch to get
-
-
Make ‘develop’ Branch the Current Branch
-
-
‘develop’ is now the Current Branch
-
-
GitFlow Button: Start Feature
and see the GitFlow button changes to a different default action, ‘Start Feature’ as we are now working on the develop branch. Before we start our first feature we take a look at the GitHub remote repository:

GitHub Timeline
As we see the remote repository still only have one branch ‘master’. This is a lesson we have to learn fast. Everything we do, we do only locally. The remote repository doesn’t know about our work until we tell about it or push our changes to the remote repository.
Let’s push the ‘develop’ branch to the remote repository by clicking the Push button
-
-
Push ‘develop’ Branch
-
-
Select to Push the Current Branch
-
-
‘develop’ Branch in Remote Repository
-
-
‘develop’ Branch in Remote Repository GitHub
Last thing to do is to do some house keeping on the GitHub side. Here we set the ‘develop’ Branch as ‘default’ branch.
-
-
Mark ‘develop’ as Default
-
-
View on GitHub
Now we are ready to start our first feature. Remember that the feature branch is only created on the local repository and not automatically pushed to the remote GitHub repository. If you like the feature branch to be visible in the remote repository you have to push it there after creating it.
We create a feature ‘Feature_1’ (you should choose a more meaningful name!):
-
-
Create Feature
-
-
Resulting View in SmartGit
-
-
Resulting View in JDeveloper
-
-
Git Tree View in JDeveloper
As we see the new branch is the current working branch. We now make some changes e.g. adding a header above the table and then look at the changes in the SmartGit and GitHub UI.
We add a panelGroupLayout to the top facet of the panelStretchLayout to add a header telling us what we see and another text telling that this was added with ‘Feature-1’. This is just for the time we are playing with the GitFlow features. We later can safely remove this second text.
-
-
Changes for ‘Feature-1’
-
-
Changed Files in SmartGit
-
-
Changed Files in JDeveloper
As we see, all tools showing the same changed files. The interesting thing is that we see a changed index.java file. The only change we made was to add something to the index.jsf file!
Well, this second change was not intended but is the result of a setting in JDeveloper which adds a property to a backing bean for every component we add to the index.jsf file. Before we remove this nonsense setting let’s save the changes to our repository and look at the different tools:
-
-
SmartGit View of Changes
-
-
Push Changes to Remote Repository
-
-
Select Branch to Push
-
-
Commands to Push the Local Branch
-
-
New Branch In Remote Repository
-
-
Timeline of Commits
-
-
Branches in GitHub
In the first image we see an interesting info: ‘Outgoing (1)’. This means that SmartGit knows that this branch isn’t connected to the remote repository and can’t seen there. This isn’t really necessary as Git is a distributed version control system, but other users can’t get to this branch if the PC holding it isn’t available (due to network restrictions or because it’s offline).
After this the new branch is visible and tracked in GitHub. Now we can remove the not needed nor wanted index.java backing bean.
Why is it there in the first place?
If we create a new view in a task flow we have the option to activate the automatic component binding to a backing bean in this dialog

Automatic Component Binding
Well, it’s either a bug in JDev 12.1.3 or a saved configuration I made to investigate something else which uses automatic component binding. Les’s assume the latter and remove this setting.
Now we have to remove line 76 in the index.jsf file, fix the bindings in index.jsf by replacing them (find: binding=\”#{backingBeanScope.backing_index..*\”), remove the bean from adfc-config.xml and finally remove the index.java file from the project
-
-
Fix index.jsf
-
-
Replace Bindings in index.jsf
-
-
Remove the Managed Bean
-
-
Delete the index.java file from Project
-
-
Confirm Delete
Now we can compile the source, test the application and then save the changes in the repository. Don’t forget to push the changes to the remote repository!
If you use SmartGit to commit the changes you can commit and push in one command by clicking the ‘Commit & Push’ button in the dialog. The final timeline in SmartGit looks like

SmartGit Timeline
Time to wrap everything up. We made some changes and now are finished with our feature. We now finish the feature in SmartGit by clicking the GitFlow button and follow the dialog
-
-
Finish GitFlow Feature
-
-
Options for Finish Feature
-
-
Git Commands
-
-
Need to Push Changes
-
-
Timeline before Push
-
-
Timeline after Push
-
-
Repository in JDeveloper
The second image shows the options we have to finish a feature. Here we can decide to remove the feature branch completely or, as we do, keep it for later. As features are not used by GitFlow to build a release or hot fix on them, there is generally no need to keep them after they are finished and merged back into the development branch.
The final thing to make the circle is to build a release from the current development branch.
-
-
Start Release
-
-
Set Release Name
-
-
SmartGit Repository after Release Start
-
-
Add Release Note to README.MD File
We add a release note part to the README.MD file to make the release visible in the file too. Now we commit the change (not shown) and finish the release
-
-
Finish Release
-
-
Finish Release Options
-
-
Executed Git Commands
-
-
Timeline after Finished Release
-
-
Branches in GitHub
In image 2 we can set the options we want to use to finish the release. The one we change from the default is that we like to keep the release branch so that we can see it in the timeline. This is not necessary as you can’t do anything with the branch (beside cherry picking :)). The last image shows the SmartGit timeline where we see all commits and the different branches used. This show look like the GitFlow image we started this blog with.
This finishes part 4 of the blog. The repository (and it’s branches) and be cloned or loaded from GitHub.