Bit workspaces track changes done to components, and shows the state of each component in your project's workspace. Understanding the state of the workspace's components during the development process can be essential and provides useful information to whether components are staged, modified, or even have missing dependencies, syntax errors, or other potential issues.
A component may have more than one state. It may have a state derived from its code status (such as modified) and a state derived from its dependencies (e.g. pending to be tagged).
Bit prompts component status on both the UI and the CLI. To quickly check your workspace status, use the bit status command.
$ bit status
You can also see the status of a component on the Workspace UI component sidebar.
No components have pending changes. Either no files are tracked in the workspace, or the tracked components have no pending changes.
bit status
nothing to tag or export
Components that have been tracked, but not yet tagged.
Bit tries to validate if a new component can be isolated, and will print all isolation issues it finds (if any).
bit status
new components (use "bit tag --all [version]" to lock a version with all your changes) > bits/a ... ok
All tagged components that are ready to be exported and shared to a remote Collection.
In Git status terms, the equivalent would be changes which have been committed but not pushed to the server.
Staged components have been verified by Bit as fully isolated.
bit status
staged components (use "bit export <remote_collection> to push these components to a remote Collection") > string/index. versions: 0.0.1, 0.0.2, 0.0.3 ... ok > string/is-string. versions: 0.0.1 ... ok > string/pad-left. versions: 0.0.1, 0.0.2 ... ok
Components that have already been staged or sourced (bit import), and then modified - meaning there's at least one tagged version, and untagged changes on top of it.
Modified components are waiting to be tagged and set as a new version.
Bit tries to validate if a modified component can be isolated, and will print all isolation issues it finds (if any).
bit status
modified components (use "bit tag --all [version]" to lock a version with all your changes) (use "bit diff" to compare changes) > string/pad-left ... ok
Components with newer versions fetched by bit import and available to use. Use bit checkout to start using the newer version.
bit status
pending updates (use "bit checkout [version] [component_id]" to merge changes) (use "bit diff [component_id] [new_version]" to compare changes) (use "bit log [component_id]" to list all available versions) > string/pad-left current: 0.0.1 latest: 0.0.2
A component was deleted locally, or remotely by another user, without the --hard flag. If locally, run bit export to complete the deletion.
If remotely run bit remove <comp-id> -f to remove the now-unavailable component from your workspace.
In either case, bit recover can be used to revert the deletion (only available for soft-deleted components).
bit status
deleted locally:
components soft-removed locally (tag/snap and export the components to update the deletion to the remote. to undo deletion, run "bit recover") > bits/b ... ok
deleted remotely
components soft-removed on the remote (use "bit remove" to remove them from the workspace. use "bit recover" to undo the soft-remove) > bits/b ... ok
A Component (not in state new) where at least one of its dependencies is in a modified state.
bit status
components pending to be tagged automatically (when their dependencies are tagged) > string/index ... ok
