For a component to be independently collaborated on, it must maintain its own version history. This history consists of 'snaps', which are the component's immutable recorded changes. Each snap records the state of the entire component including its source files, dependencies, configuration, metadata, and build artifacts.
Snaps are stored in the local scope before they are exported to their remote scopes.
Before you record your component's state, verify no issues are preventing it from being isolated from the workspace:
The output should display no issues. Note that this component is listed as 'new' as it hasn't been snapped yet.
> apps/to-do ... ok
Run the following to snap the latest component changes:
The output lists the snapped component and the hash that points to that snap:
new components
(first version for components)
> apps/to-do@9eef073f69860b34d67161a866b38530c889bb49The snap process includes a series of build tasks. The data and artifacts generated by these build tasks are persisted in that snap. To learn more, see Build pipelines.
Use 'lanes' (alpha) to suggest cross-component changes
Use 'lanes' to collaborate on groups of components without interfering with the main development course. For example, to create a new lane named 'new-feature', and switch to that lane, run:
New snaps will now be part of the 'new-feature' lane, instead of the default 'main' lane. Merge the 'new-feature' lane into the 'main' lane, when the new updates are ready.
To learn more, see Lanes overview.
To record changes that represent a new release, create a snap that's tagged with a sematic version:
The output lists the snapped component and the semantic version that points to that snap. Since no information regarding the semantic version number was provided, the tag defaulted to the next patch number:
new components
(first version for components)
> apps/to-do@0.0.1The tag process includes a series of build tasks. The data and artifacts generated by these build tasks are persisted in that snap. To learn more, see Build pipelines.
By default, Bit does not snap components that have not been modified since their last snap.
To override Bit's default behavior and snap unmodified components, run the following:
To snap with a release version unmodified components, run:
To tag with a release version (unmodified) components that have untagged head snaps (i.e, the components' latest snap in the main lane was not tagged), run the following:
To reset snaps (that have not been exported yet), and revert a component to its previous state, run the following:
The output notifies apps/to-do has been reset. Its tag version, 0.0.1, has been removed. The component is now back to its previous status as 'new':
text/my-text. version(s): 0.0.1
Note that the 'reset' command does not affect the component's source files in the workspace. To checkout the source files of a component after resetting, run:
Bit uses the workspace dependency graph to snap (and build) the direct and indirect dependents of a snapped component. This ensures all affected components are tested, built and versioned accordingly. This also ensures unaffected components are not built nor versioned, to provide efficient builds and avoid insignificant component updates for consumers of components.
Check your component status to discover components that are pending to be auto-snapped. For example:
The output for this hypothetical workspace lists the modified components and the dependent component that will be snapped automatically, when their dependency is snapped:
> entities/blog-post ... ok
components pending to be tagged automatically (when their dependencies are tagged)
> my-org.blog/pages/blog-page ... ok
> my-org.blog/apps/public-blog-app ... ok
To prevent auto-snap, run the following:
To prevent auto-tag (for snaps tagged with a release version), run the following:
Use the 'changelog' tab (in the UI) to review previous component versions. Browse thorough the component tabs to see its past states in its documentation, compositions, dependency graph, and more.
To review past versions in the terminal, run the following:
Use the 'compare' tab to compare previous versions.
Alternatively, run the following to compare versions in the terminal:
You can checkout a different component version to your workspace, to review and maintain its files and config from that point in time, or more precisely, from that snap in the component's history tree.
To learn more, see Update components.
