Gitflow Workflow

The Gitflow workflow does not add any new concepts beyond what is required for the feature branch workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact.

The Gitflow workflow still uses a central repository as the communication hub for all developers. And, as in the feature branch workflow, developers work locally and push branches to the central repository. The only difference is the branch structure of the project.

Instead of a single main branch, this workflow uses two branches to record the history of the project. The main branch stores the official release history, and the develop branch serves as an integration branch for features. All commits in the main branch should be tagged with a version number.

The following is an example of the type of scenario in which the Gitflow workflow is used.

Suppose two developers Andy and Lucy are assigned to work on two new features feature-123 and feature-456 respectively.

The administrator creates a develop branch based on main and pushes it to the remote Git repository in Talend Studio.

Andy creates a new branch andy-feature-123 based on the develop branch in Talend Studio and switches to the newly created branch.

Like Andy, Lucy creates a new branch lucy-feature-456 based on the develop branch in Talend Studio and switches to the newly created branch.

Now, Andy and Lucy work on new features and create Jobs on their local feature branches respectively, then they push changes to the remote repository.

While Andy is still working on his feature, Lucy finishes her feature and begins to prepare a release.

Lucy checks out the remote develop branch as a local branch and switches to the local develop branch.

Lucy then merges her Jobs on the feature branch lucy-feature-456 into the local develop branch using the Git pull and merge tool.

After that, Lucy pushes changes on the local develop branch to the remote develop branch.

The administrator then creates a new release branch from the updated develop branch and pushes it to the remote repository. Lucy finishes the release.

Lucy can then delete the local branch that is not needed any more.

Once it is ready to ship, Lucy checks out the main branch as a local branch, merges the changes from the remote release branch to the local main branch using the Git pull and merge tool, finally pushes changes to the remote main branch.

Lucy then switches to the remote main branch and tags it with the release version.

In addition, the release branch should be merged back into the develop branch, which may have progressed since the release was initiated.

After releasing the current version, the developers can go back to working on features for the next release, until the need arises to readjust the released version.

To work again on the released version, a developer checks out the remote main branch as a local maintenance branch, fixes the issue and pushes changes to the remote repository, a remote maintenance branch is created.

The developer then checks out the remote main branch as a local branch, executes a pull and merge request from the remote maintenance branch, and does a push from the local main branch to the remote main branch. The changes made for the bug on the maintenance branch are now merged into the remote main branch.

The developer then tags the remote main branch with the hotfix numbering v1.0.1.

Like release branches, maintenance branches also need to be merged with the develop branch, so the developer needs to perform that merge as well and removes all local branches that are not needed any more.