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) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@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?
Beta Was this translation helpful? Give feedback.
All reactions