All Collections
Projects and languages
Project features and settings
Project branching
Project branching
Work on multiple branches of the project, merge branches as needed.
Ilya Krukowski avatar
Written by Ilya Krukowski
Updated over a week ago

This feature is available from the Pro plan and above. Please note that it is available only for "Software localization" type of projects, but not for "Documents".

The development process often requires you to work on multiple branches. Lokalise supports branching similar to GitHub, with some limitations (see below).

If you're looking for recommendations and best practices, please refer to Software localization workflow document in our DevHub.

Index

What is branching?

To put it simply, a branch is a separate version of your translation project. When the branching feature is enabled for a project, this project can have multiple independent versions. You can switch between these versions, delete them, and merge changes from one version into another.

For example, suppose you have a welcome key with the "Welcome to the app!" translation value. You enable branching and create two branches: master and develop. Initially the welcome key has identical translations in both branches, however you can switch to the develop branch and modify the key's value to "Welcome to our app". This change will not affect the translation value stored in the master branch (it will still contain "Welcome to the app!" text).

Now you can decide which translation suits best. If you prefer the master version, then simply delete the develop branch, otherwise you can merge the develop branch into master thus incorporating all the recent changes from develop. This is very convenient because with branches you can safely experiment with your keys and translations without worrying that your changes might affect the "main" version of the project.

Please be aware that certain project elements are global (in other words, do not support branching) as explained in the corresponding section.

Enabling branching

If the branching feature is included in your subscription plan, you can enable it by proceeding to More > Settings:

Tick the Branching checkbox under the General tab, Miscellaneous section. Don't forget to click Save changes in the bottom afterwards:

Once enabled, the Branches tab will appear in the project settings. You can add, delete, and merge branches there.

Creating branches

By default, a single branch called master will be created for you. You can create additional branches either under the Branches tab in the project settings, or directly from the branch selection dropdown (in the Editor or at the projects dashboard):

Branch names have certain restrictions:

  • must start with a letter or number or dot

  • must end with a number or letter

  • may contain numbers, letters, and . - _ / characters

  • multiple consecutive slashes are not allowed

  • multiple consecutive dots are not allowed

  • no slash-separated component can begin with a dot

  • no slash-separated component can end with the sequence .lock

  • minimum length is 2 characters

  • maximum length is 100 characters

Merging

Once you are done working on a branch and would like to merge it (in other words, take the changes from this branch and incorporate those into another one), there are several things you should consider:

  • You cannot delete a branch that has active tasks or orders.

  • Merging is not available when there are active tasks or orders on the target branch.

  • Conflicts can be resolved before merging.

  • Merge operation is irreversible.

Proceed to Settings > Branches to start the merging process. We'll check for any conflicts beforehand:

A conflict means that a certain element (for example, a translation key) was modified in both branches and therefore you have to decide which version of this element should be kept.

You can resolve conflicts in favor of one of the branches by clicking Resolve all using... or by clicking Show next to the conflict (check the screenshot above). When the Show button is clicked, you'll see a similar interface:

Now simply choose what version to preserve.

Special note on translation orders

In some cases you might see a checkbox I understand, no claims can be done further on TOs in this branch:

You'll see this checkbox if you have an active professional translation order created on the source branch, and this order is still in progress. You should be aware that if the source branch is merged into the target, the order is not moved to the target branch. It stays valid for the source branch only.

Basically, this checkbox appears to remind you that you won’t be able to request corrections on the source branch order, because the translation history is lost.

Understanding merging

It is vital to understand how the merging process works, so let's take a look at some examples.

Suppose you have a branch named master. Then you create a new branch named develop which is based on master. Initially, these two branches are equal (meaning that the translation data, language settings, and other content is identical in both branches). Let's also suppose we have a key called welcome with the English translation "Welcome to the app!".

Scenario #1: perform changes in develop only and merge into master

In develop branch we change "Welcome to the app!" to "Welcome to our application!". The master branch has no changes. Then we merge develop into master. As a result, the master branch will now also contain the "Welcome to our application!" translation for the welcome key.

Scenario #2: perform changes in master only and merge into develop

This scenario is very similar to the first one. If you change the translation for the welcome key to "Welcome to our application!" in master and then merge this branch into develop, then this new version will appear in the develop branch as well.

Scenario #3: change the same translation both in master and develop and perform merge

Now suppose we have modified the English translation for our welcome key in both branches:

  • master — "Welcome to our application!"

  • develop — "Welcome onboard!"

In this case if you try to merge develop into master, or master into develop, a conflict will be detected. You will need to manually pick the version to keep. The other version will be erased during the merge.

Scenario #4: perform changes in develop and merge master into develop

This scenario is less obvious. Suppose you change the welcome translation to "Welcome to our application!" in the develop branch. The master branch, however, has no changes and contains the old translation value "Welcome to the app!". If you merge master into develop, then the "Welcome to our application!" translation will be used as a result.

Effectively, that means you cannot "restore" translations that were modified in the develop using the old master versions. Why? As long as the translation in develop was modified since the branch creation, while the translation in master was left intact, we consider the develop version to be the newest. The older version cannot overwrite the newer one, therefore in this scenario you'll get "Welcome to our application!" translation as a result. If, however, you change the same translation in both master and develop then there will be a conflict as described in scenario #3.

Scenario #5: delete the welcome key in master, update the same key in develop, and then perform merge

In this case the result will depend on the target and the source branches that you choose:

  • If you choose to merge develop into master, then you'll see a conflict saying that the welcome key was removed in one branch and updated in another one.

  • If you choose to merge master into develop, then no conflicts will be detected and as a result the welcome key will be left intact (it won't be removed).

Scenario #6: delete the welcome key in develop and merge into master

Suppose, we delete the welcome key in the develop branch. The master branch has no changes. Then we merge develop into master. As a result, the master branch will now also get the changes for the welcome key, which means that the welcome key gets deleted on master.


How branching affects your project

Once you enable branching, the current version of the project becomes the master (main) branch.

Different areas/functions of the project are now either global or branch-specific:

Automations

  • Automations work only for the master branch

Project settings

  • Project settings are global.

Snapshots

  • Snapshots are currently created only for the master branch. This applies to all automatic snapshots (i.e. when applying bulk actions).

Contributors

  • The contributor list is global.

  • Contributors have access to all branches and you cannot make certain branches "protected" (available only to project admins or certain contributors).

  • Language access and roles are shared across all branches.

Languages

  • Languages are branch-specific.

  • There could be merge conflicts in languages, which you'll need to resolve at the merge phase.

  • Changing a language (in the language settings) is disabled in branching mode.

Keys

  • Keys are branch-specific.

  • There could be merge conflicts which you'll need to resolve at the merge phase.

  • When merging, the new key data overwrites the existing key data in the target branch (check the examples above).

  • Key tags do not create conflicts, they are merged.

Comments

  • Key comments are branch-specific.

  • Key comments are not merged when merging branches. If you merge two branches, only the comments from the target branch will be preserved.

Translations

  • Translations are branch-specific.

  • There could be merge conflicts which you'll need to resolve at the merge phase.

  • Reviewed and Unverified statuses may also create conflicts.

  • Upon merge, the source translation overwrites the target (existing) data including Reviewed, Unverified and Custom translation statuses (if enabled).

  • Spelling exceptions apply to all branches.

  • Key references are branch-specific. 

  • Cross branching key references are not supported. If you reference some other project key then it will default to master.

Glossary

  • Glossary is global.

  • Term extraction works only from master.

Translation history

  • Translation history is branch-specific.

Screenshots

  • Screenshot storage is global, however key linking is branch-specific. If you delete a screenshot it gets deleted from all branches.

Uploads

  • Uploads are branch-specific.

Downloads

  • Downloads are branch-specific.

  • Strings included from other projects are based on the master if branching is enabled in the chosen project.

Activity

  • Activity is branch-specific.

  • Certain events appear only on master if it's a global activity (for example, adding a contributor).

  • Branch activity is lost after the branch is deleted (does not apply to audit logs).

Tasks

  • Tasks are branch-specific.

Orders

  • Orders are branch-specific.

Statistics

  • Statistics is branch-specific.

API

  • API requests are branch-specific.

  • Branching is only available in API 2.0.

Apps

  • Apps (previously known as "integrations") are either global or branch-specific.

  • GitHub, GitLab, Bitbucket, and other Git-related integrations are branch-specific.

  • Webhook, Asana, E-mail, Jira, Slack, Trello can be either global (any branch) or per branch.

  • All other integrations are for the master branch only.

Offline translations

  • Offline translations are branch-specific.

  • If an XLIFF file was downloaded from the branch_a, it can only be uploaded back to the branch_a, but not to the branch_b. Similarly, a file downloaded from the branch_b  can only be uploaded to the branch_b.

Did this answer your question?