Merging lanes

Merge a lane to another lane (or main)

Before merging a lane make sure you are on the lane you want to merge to. This is most likely the main lane, which is the default for your workspace. If you're not on the relevant lane, switch to it before proceeding.

Switch to the lane you want to merge into, if you're not already on it (this should typically be the main lane):

$bit
Copiedcopy

Note that you can only tag components in the main lane.

Run the following command with the lane name, to merge it to the current lane:

$bit
Copiedcopy

Use the full lane ID to merge a lane that is not available locally:

$bit
Copiedcopy

Choose a strategy for merge conflicts

Choose a merge strategy for conflicts, using the one of the following options:

  • ours - keep the current version of the component, ignore the incoming version
  • theirs - use the incoming version of the component, ignore the current version
  • manual - stop the merge process and let you manually resolve the conflicts

For example, to use the manual strategy, run the following command:

$bit
Copiedcopy

Manually resolve conflicts in component source files, in their respective directories. Conflicts between component configs and dependencies are manually resolved using the merge-conflict file, at the root of the workspace.

Resolve conflicts in component dependencies and configurations

When a merge conflict occurs in a component dependency or configuration, the merge process stops and lets you manually resolve the conflicts. A file named merge-conflict is generated in the root of your workspace, containing the list of component conflicts.

For example, the following output is of a merge conflict in a component dependency (after running bit lane merge):

components with config-merge conflicts
my-org.my-scope/my-component

conflicts were found while trying to merge the config. fix them manually by editing the merge-conflict file in the workspace root. once ready, snap/tag the components to complete the merge.

Head over to the merge-conflict file at the root of your workspace, and resolve the conflicts manually:

# Resolve configuration conflicts per component and make sure the Component ID remain in place -------------------------------------------------------------------------------- [*] my-org.my-scope/my-component -------------------------------------------------------------------------------- { "teambit.dependencies/dependency-resolver": { "policy": { "dependencies": [ { "name": "lodash",
<<<<<< 0.0.2 (main) "version": "3.0.0",=======
"version": "4.0.0",>>>>>> fd5367de367f0a58b665cc35864ab2c78 (my-org.my-scope/my-lane) "force": true } ] } } }

Once the conflicts are resolved, snap the components to complete the merge process:

$bit
Copiedcopy

Merge some components from a lane

Merge components selected using a pattern

Use a glob pattern to select the components you want to merge from the lane. For example, the following command merges all components from my-org.my-scope scope, under the ui namespace:

$bit
Copiedcopy

Only merge components currently maintained in the workspace

To merge only the components that are currently maintained in the workspace, run the following:

$bit
Copiedcopy

Merge snaps without a common ancestor

The merge operation primarily works on the basis of common ancestors. It tries to merge changes from two or more snaps using their common ancestor as a reference point. If you try to merge two snaps that do not have a common ancestor, Bit will treat this situation as if you're trying to merge unrelated histories.

This could happen when you're attempting to merge components with identical IDs that were created, separately, in two different lanes.

By default, Bit will refuse to merge histories that do not share a common ancestor. However, if you intentionally want to merge snaps from unrelated histories, you can use the --resolve-unrelated flag.

$bit
Copiedcopy

The new snap will have a unique reference, but will be identical to the head snap of the component in the lane you're merging from.

Note that creating a component that already exists in 'main', in another lane, is not allowed. A case of unrelated histories, can only happen when a component was created in a lane, and then created in 'main', or if a component was created in two different lanes (that are not 'main').

Post-merge actions

Merge without snapping

By default, the merge operation will create a new snap. However, in some cases, you might want to merge only to test and verify updates, without persisting them.

Run the following command to merge without snapping:

$bit
Copiedcopy

Merge to main and tag snaps with a release version

Merging to main is typically done to release new component versions. Run the the following to merge and snap with a release version (tag):

$bit
Copiedcopy