5 ms·
As a side note, I always found it annoying to use “feature/123” instead of “features/123“. Just like in REST APIs, the slash brings to mind a collection or a fi
by tga 6y ago
As a side note, I always found it annoying to use “feature/123” instead of “features/123“. Just like in REST APIs, the slash brings to mind a collection or a file system directory, both of which should be pluralized.
- leksak 6y agoI like fix/ refact/ feat/ special/ docs/ as pre-fixes and would not like to pluralise any of them.
- soonix 6y agoITYM "doc", since "docs" is already pluralised...
- taftster 6y agoWhy do you like these prefixes? Honest question. My thoughts are: They don't really add any value to the branch nor do they inform the developer. Identifying a bug fix, a new feature, or a document branch doesn't change the way you treat the branch in any way, nor would it necessarily prioritize the branch. If you are drowning branches (like dozens or hundreds) and need to categorize them like this, it's somewhat a "code smell" reflecting the development process. Having too many things open and not closing them is not the greatest strategy. Anyway, honestly interested in your opinion and why you find those prefixes useful. They seem to me to be some holdout from early blog postings recommending this approach, but turn out to not really add any value.
- FalconSensei 6y agoAgree with you. Branches are branches, they have code. That's it. We review tickets / pull requests. Tickets should already be prioritized, be tagged as task/improvement/fix, and pull requests are displayed in order of creation. No need to worry about branch names. Just use either the ticket code, or the title (or code-title)
- thiht 6y agoI used to be a big fan of conventional branches and commits (feat, fix, etc.), but realistically after a few years this scheme has never been useful once. It just wastes precious characters in commit messages.