Strategies for using git and bit together

[sbland]

I'm curious to know how others have integrated git and bit as bit takes on a significant amount of the version control but does not (yet?) have the same existing toolsets. Is the plan ultimately to replace git with bit?
I tried to combine the 2 and had to give up on any branching. I recently moved to just using bit for my components but as in the discussion here (#5030) that leaves some files not version controlled. My solution to this is to have a repo with just those files with a git ignore for any component directories.
I have also seen other topics where github actions is used to run the Bit commands.

[ranm8]

You can use Bit and Git together to run a component monorepo also with Github Actions.
To learn how to think about Bit in your repositories head to Thinking Bit.

To use Github Actions to release your components use the Github Actions CI scripts or automate the Bit commands from the CI yourself.

[davidfirst]

Worth an update, since a lot has changed here since the last reply.

On the original question — Bit can replace Git. Components are versioned, snapped and merged by Bit, lanes are the branching model, and teams do run Bit-only with no Git repo at all.

But you don't have to. If you keep Git, the seam between the two is now automated by the bit ci command group in the CLI, instead of a hand-rolled script of bit lane create / snap / export:

• bit ci verify — status + build check; good as a pre-push hook or the first CI job.
• bit ci pr — on a PR, derives the lane name from the current Git branch, snaps and exports it, so the branch has a reviewable lane on bit.cloud.
• bit ci merge — on merge to the default branch, tags semantic versions, exports, and commits the updated .bitmap + lockfile back.
• bit ci sync — keeps lanes and branches converged in both directions, opening and closing the PRs as needed.

# on: pull_request
- run: npx @teambit/bvm install && bit ci pr
# on: push to main
- run: npx @teambit/bvm install && bit ci merge
# both with BIT_CONFIG_ACCESS_TOKEN in env

bit ci sync is the one that addresses the "I had to give up on branching" part of the original post. It's a stateless reconciler: it compares each lane's remote head against the state the branch itself records (the committed .bitmap) and converges — importing lane changes onto the branch, exporting branch commits onto the lane, merging when both moved. It's idempotent, so a webhook, a push and a cron can all trigger it safely. bit ci sync --init scaffolds the workflows; --dry-run prints the plan without touching anything remote.

Two smaller ones for Git-side friction: bit ci merge --skip-push plus "bitmapAutoSync": true keeps release commits off a branch-protected default branch, and bit git set-merge-driver resolves .bitmap merge conflicts for you.

The files Bit didn't version

The other half of the original post — the files left outside Bit, which #5030 was about — is being addressed right now. #10698 (in review) lets a single component own the workspace root with rootDir: ".": its file-set is everything under the root minus the nested components' root-dirs, .bitmap included, and a trackAllFiles flag keeps package.json, root tsconfig.json, lint configs and lockfiles tracked instead of treated as generated. bit import <root-component> --path . then restores the whole workspace onto an empty directory from the scope alone — no Git repo needed for the repository-level files, and no second repo with an ignore list for component dirs.

It comes out of the pnpm-workspaces RFC (#10675, design in pnpm/rfcs#33): map every pnpm project to a component and give the unclaimed repository files to a root component. So it cuts both ways — it's what makes a Git-free workspace fully restorable, and it's also how an existing monorepo gets adopted without moving any files.

bit ci <command> --help has the full flag list.