git-workflow

To maintain a linear Git history, you should use rebase at the start of your development sessions and during merges. This workflow avoids direct pushes to the main branch and ensures predictable, auditable version control.

The best way to structure commits for code reviews is to use atomic refactoring. Commits should be small, focused, and testable, using conventional commit messages like feat:, fix:, or refactor: to ensure reproducible changes.

To prevent accidental direct commits to the main branch, enforce a branching discipline that requires feature work on dedicated branches. You can create an opencode branch and submit regular pull requests instead of pushing directly.

You need to rebase before merging feature branches to maintain a linear project history. Rebasing integrates the latest changes cleanly, prevents merge commit clutter, and ensures the deployment lifecycle remains auditable.

Git workflow automation supports deployment rollbacks through a structured lifecycle. It guides you to build, test, review, deploy, and rollback with verification, ensuring reliable and documented recovery for version control.

You should update documentation during version control after completing changes. Updating relevant docs and workflow references enriches the project for the next agent and ensures knowledge sharing across the development lifecycle.