Working with Git: Branching & Best Practices

Talend Subscription Solutions support different flavors of Git including GitHub, Gitblit, and BitBucket. This post will cover general concepts of versioning, branching, and best practices.


With Git, a branch will always begin as a copy and will move forward from that point in time, creating its own history. A Talend project can be associated to its own repository or a particular branch/tag. If a repository is associated with multiple Talend projects, then any branches or tags within that repository will be visible across those Talend projects. After a Git repository has been configured and verifying that the repository is accessible for pushes, a branch can be created to begin development.

Generally, development teams will define their own workflows. With Git projects, branches will either be remote by default or local. A local branch means that the developer is working offline in the branch that was last worked on. Changes are committed to the local repository only and need to be pushed to a remote branch before merging back to master.

The examples below will use a remote Git repository and provide scenarios with developers Jane Smith and Tom Baker.

Simple Branching

In the first example below, Jane will clone a branch from master, create a job, then merge back to master.

There are two approaches to create a branch; checkout as a local branch or New Branch.

New Branch

check out as a local branch

After the new branch has been created, the repository will now show (Local Mode) indicating any development will be local. In addition, the local branch will appear in the repository menu.

An indicator (* [ 6 ]) shows how many changes the local branch is ahead of master. The initial cloning of a branch will write metadata in the form of several commits. At this point, the local branch could be pushed to master. As an example, a job will first be created in the local branch.

Once the job has been created, changes can be pushed to master.

Switching Branches

In the following example, Tom has developed a second job and has not pushed changes.

If Tom attempts to switch to the remote branch (which in this example is master) with uncommitted changes on the local branch, the Studio will display an error:

After Tom pushes changes to master, Jane will pick up development on the second job in the next example.

Synchronizing Branches

Jane has returned to the Studio and switches to the local master branch. The studio will automatically pull from master:

A manual pull and merge can also be done through the repository menu:

Conflict Resolution

Once the repository has been synced, Jane continues work on the second job. At the same time, Tom also continues work on the second job and commits his changes.

Note: both Jane and Tom are working in local mode; if the repository was in remote mode, the item would display as locked and only a single user would be able to access the item at a time.

Jane attempts to commit:

If there are conflicts found, the following message will appear:

In order to resolve the conflicts, the Git Merge perspective will display a Conflict Navigator:

The items in conflict will appear in the tree structure. After selecting the conflict item (job2), a detailed comparison of the conflicts will be displayed. Additionally, by selecting specific components or connections in the item, they will become highlighted in the view.

Conflicts can be resolved a the component/connection level, or at the item level.

Component/Connection Level Resolution

Item Level Resolution

After the conflicts have been resolved, a dialog box will be displayed to continue the commit process:

Copying Between Branches

Jobs can be copied between branches directly through the repository:


To perform a comparison of versions, right click on the job and select Compare Job:

After selecting the desired versions, the studio will display the compared jobs side-by-side as well as with a tree structure:


Each time a job is saved or run, a commit occurs. Each commit will automatically add user information. In the repository menu, choose More… and Show History.

History can be viewed directly from the studio:

By clicking on a commit, detailed information will be displayed:

Best Practices

The best practices for Git are outlined in the Talend Software Development Life Cycle documentation.

The complete documentation for working with project branches and tags with Git is available in the documentation.

One thought on “Working with Git: Branching & Best Practices

  • May 9, 2017 at 9:08 am

    Is it possible to have own commit messages?


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: