93 lines
3.1 KiB
Markdown
93 lines
3.1 KiB
Markdown
# Version Control
|
|
|
|
Version control is essential for SIA's self-improvement capabilities.
|
|
It provides a way to track changes, revert to previous states when necessary, and maintain a coherent evolution of the codebase.
|
|
This document outlines the git workflow designed specifically for SIA's unique development model, where the agent itself is the primary developer.
|
|
|
|
## Core Principles
|
|
|
|
The git workflow for SIA is designed around several key principles:
|
|
|
|
- **Simplicity**: Since SIA is the sole developer, complex branching strategies designed for human teams are unnecessary
|
|
- **Traceability**: Every change should be traceable to its purpose and the reasoning behind it
|
|
- **Stability**: The master branch should always be in a working state
|
|
- **Recoverability**: It should always be possible to revert to a known good state
|
|
- **Security**: Git credentials must be handled securely to protect repository access
|
|
|
|
## Branching Strategy
|
|
|
|
### Branch Structure
|
|
|
|
SIA uses a simple branching strategy with two types of branches:
|
|
|
|
- **master**: The main branch containing stable, production-ready code
|
|
- **feature/{timestamp}_{description}**: Temporary branches for implementing specific improvements
|
|
|
|
This minimal approach is appropriate because:
|
|
- There is only one developer (SIA itself)
|
|
- Changes are typically focused on specific, well-defined improvements
|
|
- There's no need for parallel development streams
|
|
- Simplicity reduces the cognitive load on the agent
|
|
|
|
### Branch Naming
|
|
|
|
Feature branches follow a consistent naming convention:
|
|
```
|
|
feature/{YYYYMMDD}_{brief_description}
|
|
```
|
|
|
|
For example:
|
|
```
|
|
feature/20250115_improve_context_management
|
|
feature/20250203_add_email_tool
|
|
```
|
|
|
|
This convention:
|
|
- Makes it easy to identify when a branch was created
|
|
- Provides a clear indication of the branch's purpose
|
|
- Creates a chronological ordering when listing branches
|
|
- Avoids potential naming conflicts
|
|
|
|
## Commit Strategy
|
|
|
|
### Commit Frequency
|
|
|
|
SIA should commit changes before running tests.
|
|
This ensures that crashes of the core system can be traced back to a specific change.
|
|
|
|
### Commit Messages
|
|
|
|
Commit messages should follow a structured format:
|
|
|
|
```
|
|
{type}: {concise description}
|
|
|
|
{detailed explanation of changes and reasoning}
|
|
|
|
{reference to any relevant issues or test results}
|
|
```
|
|
|
|
Where `{type}` is one of:
|
|
- `core`: for changes on the core system
|
|
- `procedure`: for changes on procedures
|
|
- `test`: for changes on tests
|
|
- `tool`: for changes on tools
|
|
- `training`: for changes on training data
|
|
- `web`: for changes on the web interface
|
|
|
|
This structure:
|
|
- Makes it easy to understand the purpose of each commit
|
|
- Provides context for future review
|
|
- Creates a useful and navigable history
|
|
|
|
### Merge Strategy
|
|
|
|
The `--no-ff` flag creates a merge commit even for fast-forward merges, maintaining a clear record of the feature's development and completion.
|
|
|
|
## Credential Management
|
|
|
|
### Credential Storage
|
|
|
|
Git credentials are stored in the environment, not in the filesystem.
|
|
This ensures that credentials are not exposed in the iteration log.
|
|
Info about the repository and relevant environment variables is stored in `/root/data/environment/sia_repo.md`. |