Replies: 1 comment
-
|
How you work with branching is up to you. We are disconnecting the spec creating from the branch creation and making that an opt-in as how you work in your organization might not fit for you. And how you manage your specs depends on how you want. Some folks commit them, others do not. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Moin folks,
I’m looking for best practices on how to handle the creation of multiple specs and how to work with them over time.
Consider a project where multiple specs are created for different features. For example, an initial spec defines the MVP, and subsequent specs extend this MVP with additional features. These later specs often build on a kind of “foundation” established by the MVP spec.
Currently, each spec is created in its own feature branch, with no awareness of the others.
So how should this be handled?
Should new feature branches be created from the existing 001-mvp branch?
How do you manage this when multiple people are working on spec definitions and later on the specifications and the implementations themselves?
So far, everything I’ve read about spec-kit feels quite “waterfall-like” to me :-(
Beta Was this translation helpful? Give feedback.
All reactions