Any branching strategies or approaches adopted in the repository should extend from the Basic Foundation:
- Help roll back to a specific good point in time
- Helps share work to: test, get feedback, identify dependencies.
- Provides context
GitLab - Commit often and push frequently
- It can contain any raw and not ready-made code
- It is not stable and can be changed or deleted by the developer at any time
- Internal commits should primarily help the developer.
- Acceptance criteria met
- Definition of Done met
- Tests completed successfully
- The developer is ready to receive feedback from the reviewers
- Should have a short life.
- Should contain only one Feature.
- Should represent changes from one and only one developer.
- Should frequently pull changes from main branch.
- Should squash all commits before merged into main branch.
- Should be removed after they are merged into main branch.
- Feature branch name should start with ticket id
- Commit message should start with ticket ID
- Recommended workflow for Feature
- Recommended workflow for Integration
Copyright © 2017 Stanislav Kochenkov