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):
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:
Use the full lane ID to merge a lane that is not available locally:
Choose a merge strategy for conflicts, using the one of the following options:
ours
- keep the current version of the component, ignore the incoming versiontheirs
- use the incoming version of the component, ignore the current versionmanual
- stop the merge process and let you manually resolve the conflicts
For example, to use the manual
strategy, run the following command:
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.
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
):
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:
<<<<<< 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:
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:
To merge only the components that are currently maintained in the workspace, run the following:
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.
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').
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:
Merging to main is typically done to release new component versions. Run the the following to merge and snap with a release version (tag):