Work on separate changes

3 minute read · Projects & Git

Use separate conversations for changes that need their own context. They can share a branch, or you can give one an isolated worktree so the file edits stay separate.

• Decide whether chats should share files
• Finish an isolated change
• Coordinate commits and running apps
• Test the parts together

Decide whether chats should share files#

Two chats on the same branch can work on independent parts of an app. They still edit the same checkout, so simultaneous changes to the same file can conflict. Tell each chat its exact responsibility, such as article-list styling versus API validation, and review the combined result before committing.

Choose a worktree when you need an isolated branch and directory for a task. The worktree is derived from the parent project, with its own branch and directory. It may still need its own dependency preparation, running processes or port configuration. A second checkout is not a second database unless you explicitly configure one.

Finish an isolated change#

1. Open the task's worktree and confirm its current branch and changed files.
2. Run the relevant project checks there and inspect the actual result.
3. Use the supported finish workflow to bring the change back when the source and destination states permit it.
4. If a merge conflicts, inspect and resolve the affected files, then rerun the checks that cover the resolution.
5. Verify the parent checkout before removing an unused worktree through its explicit action.

Do not delete a project directory to close a worktree tab. Closing a UI surface, archiving a chat and removing a checkout are different operations.

Coordinate commits and running apps#

A manual commit records the selected current changes; it is separate from agent automatic-commit safeguards. If two chats share a checkout, review whether the commit includes both tasks. Switching branches, pulling or finishing a worktree while an app or agent is using the files can change its working context. Follow the busy/dirty checks and avoid treating a disabled control as a reason to run an equivalent destructive shell command.

Test the parts together#

Suppose one chat updates the API response and another adds a search interface. Give each chat the expected request and response shape, then test the combined flow in the preview: enter a search, inspect the request, compare the response and verify the displayed rows. Passing each task's own check is useful, but it does not establish that the two changes agree.

Keep database configuration explicit in isolated worktrees. Two checkouts can still point to one database, share an upload directory or compete for a port. Review the project's environment and startup commands before running them side by side. Changing one worktree's branch does not isolate external services automatically.

When only a linked task's result remains, use the local wait/resume workflow instead of repeatedly asking for its status. The linked chat retains its approvals and exact run result. Review a failure or partially completed merge with its evidence; do not discard a checkout to make the task appear finished. Read linked tasks and Git review before combining independent work.