Replies: 4 comments 2 replies
|
I dont feel super strongly. a common practice is something like this: feature/ (e.g. Feature/LP3Tests, or Feature/LP3Tests#63) |
|
Seems to me like this is a low consequence choice. If we're sticking to our guns on short branch life, none of these will last long, and we'll never see their names again once they're merged. That said, I'll conform to whatever. Just so long as it's descriptive of the task being done. |
|
The branch names can be used to identify features via an api query on the project - so if we were really good about our management here, we could rely on our naming convention to generate a feature list automatically for each new release. |
|
Oooh. I like that. That's cool. |
|
I’m hearing little downside but opportunities for upside. We could use branch names as another device for demonstrating our use of SET funds?
… On Sep 22, 2021, at 10:04 AM, Will Lehman ***@***.***> wrote:
The branch names can be used to identify features via an api query on the project - so if we were really good about our management here, we could rely on our naming convention to generate a feature list automatically for each new release.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
We've not been very regular on naming branches. I think this is OK for FY22 because we're moving very fast. In FY23, I hope that we can tighten this up to help us with reporting. |
Uh oh!
There was an error while loading. Please reload this page.
@HenryGeorgist I see that there are many different views on the best practices for naming branches. Would you mind expressing your view or point to an article with which you are agreeable?
All reactions