Skip to main content Skip to Footer

BLOG


August 02, 2017
Parallel development with GitFlow: How we implement—Part 2
By: Nicholas Gulrajani

This is my second blog on parallel development using GitFlow. Its focus is to show how this model can be implemented using GitFlow with an Eclipse IDE along with EGit. You can read the previous blog here.

A summary of commands in sequence that are used is as shown below.

image

The first step is to initialize GitFlow as shown inside an Eclipse IDE below.

image

A switch to the develop branch occurs as shown below.

image

Starting a Feature

When beginning something non-trivial, it is a good idea to start a new feature. This “Start Feature” will be the default action when you click the GitFlow button if you are currently on the develop branch.

Commit your feature implementations to this branch. If you want, you can push the feature branch to your remote while you work on it (your team can decide on whether that’s normal practice or not).

If at any time you want to switch branches, either to another feature branch or to somewhere else, just use the normal mechanisms in GitFlow to do that. GitFlow will determine your context simply from the branch you currently have checked out.

image

Select ‘Start Feature’

image

Provide a name for the Feature

image

Switch to Feature A branch defined


This action creates a new feature branch based on “develop” and switches to Feature A branch defined.

image

History Log

image

Finishing a feature

When you’re done implementing a feature, use the ‘Finish Feature’ action and the feature branch will merge into the main development branch, essentially queueing it for inclusion in the next release.

Feature branches are deleted by default but you can opt to retain them if you like.

This action performs the following:

  • Merges Feature A into ‘develop’
  • Removes the feature branch
  • Switches back to ‘develop’ branch
image image image

 

Publishing a feature

Are you developing a feature in collaboration?

Publish a feature to the remote server so it can be used by other users.

image

 

Getting a published feature

Get a feature published by another user.

image

 

Starting a release

You start a release branch when you want to start preparing a new release, which probably coincides with a feature freeze.

Most of the time, you want to start the release from the latest commit in the development branch, but you can choose to base it on another commit. This essentially freezes the release, so it’s not affected by subsequent development.

You can also perform preparatory tasks for the release process on this branch, such as updating the version number in source files, updating changelogs, or committing other tweaks. Once these tweaks are done, you can finish the release as described below.

  1. To start a release, use the GitFlow (Eclipse) command. It creates a release branch created from the ‘develop’ branch.
    image
  2. Select
    image
  3. Define 
    image
  4. Create
    image

It’s wise to publish the release branch after creating it to allow release commits by other developers. Do it like feature publishing with the command.

image

Finish up a release

Finishing a release is one of the big steps in Git branching. It performs several actions:

  • Merges the release branch back into ‘master’
  • Tags the release with its name
  • Back-merges the release into ‘develop’
  • Removes the release branch
image

Finishing a release (Eclipse)

image image

Starting a hotfix

What if you need to just fix a bug on the latest release? You don’t want to create a new release, because that will pick up the recent changes from the development branch. Instead, you can start a “hotfix.”

A hotfix or quick-fix engineering update is a single, cumulative package that includes information (often in the form of one or more files) that is used to address a problem in a software product (such as a software bug). Hotfixes always start from the latest production code from the “master” or “default” branch. Other than that, they’re basically the same as release branches.

Moreover, when you’re finished with the hot-fix, they behave the same way as finishing a release branch. The changes are merged back into both the production branch and the development branch, and a tag is created on the production branch for the hot fix release.

  • Hotfixes arise from the necessity to act immediately upon an undesired state of a live production version
  • Hotfixes may be branched off from the corresponding tag on the master branch that marks the production version.

Like the other GitFlow commands, a hotfix is started with:

image

Hotfix Creation (Eclipse

image

Finish a hotfix

By finishing a hotfix, it gets merged back into develop and master. Additionally, the master merge is tagged with the hotfix version.

image

Finish Hotfix (Eclipse)

image

Wrapping up

GitFlow is a great way to automate your handling of branch-based development, and using an Eclipse IDE with EGit and GitFlow plugins, now provides a simple and clear way to use it with an easy-to-use and intuitive Graphical User Interface or GUI.

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

Popular Tags

    More blogs on this topic

      Archive