Git Workflow
Relevant source files
The following files were used as context for generating this wiki page:
The Git Workflow for the Dev-Template repository establishes a standardized process for code contributions, environment management, and automated deployments. It ensures that the main branch remains stable while allowing for iterative development through feature branching and continuous integration.
The workflow is designed to facilitate collaboration among developers by providing clear guidelines on branching strategies, commit standards, and the integration of automated checks before code is merged into the production-ready branch.
Sources: README.md, CONTRIBUTING.md
Branching Strategy
The project employs a feature-branch workflow to maintain a clean history and ensure that every change is validated.
- main branch: Contains the production-ready code. Direct commits to
mainare restricted to ensure stability. - feature branches: Created for specific tasks, bug fixes, or enhancements. These branches use the naming convention
feature/task-nameorbugfix/issue-id. - Release branches: Used to prepare for a new production release, allowing for final testing and minor adjustments.
Workflow Visualization
The following diagram illustrates the transition of code from development branches to the main production branch.
This flow ensures that no code reaches the main branch without passing automated validation.
Sources: CONTRIBUTING.md, .github/workflows/main.yml
Continuous Integration (CI)
Automated workflows are triggered by Git events to maintain code quality and prevent regressions. These are primarily defined in the GitHub Actions configuration.
CI Pipeline Steps
| Step | Action | Description |
|---|---|---|
| Linting | Static Analysis | Checks code for stylistic consistency and syntax errors. |
| Testing | Unit/Integration Tests | Executes automated tests to verify functional requirements. |
| Build | Build Process | Ensures the project compiles or bundles correctly without errors. |
The CI pipeline is triggered on every push to feature branches and every pull_request targeting the main branch.
Sources: .github/workflows/main.yml
Environment Management and Exclusions
To prevent environment-specific configuration or sensitive data from entering the repository history, a comprehensive .gitignore file is maintained. This ensures the workflow is portable across different developer machines.
Key Exclusions
- Dependency Directories:
node_modules/,venv/, or local binaries are excluded to keep the repository lightweight. - Environment Variables:
.envfiles and local secrets are ignored to prevent security leaks. - Build Artifacts: Compiled code and distribution folders (e.g.,
dist/,build/) are generated via CI rather than tracked in Git.
Sources: .gitignore
Contribution and Pull Request Process
The project enforces a strict Pull Request (PR) process to ensure peer review and accountability.
- Fork/Branch: Developers create a local branch from the latest
main. - Commit: Changes are committed locally with descriptive messages.
- Push: The branch is pushed to the remote repository.
- Open PR: A Pull Request is opened against the
mainbranch. - Review: At least one maintainer must review and approve the changes.
- Merge: Once CI passes and approval is granted, the branch is merged and deleted.
Sources: CONTRIBUTING.md, LICENSE
Summary
The Dev-Template Git Workflow provides a robust framework for software development, prioritizing the stability of the main branch through automated GitHub Actions, strict branching conventions, and comprehensive environment filtering via .gitignore. By following this structured approach, the project ensures high code quality and a reliable path from development to production.