Naming repositories is a very critical task irrespective of how insignificant it may seem. Fact is number of repositories, you have to deal with, will only grow in future and you might have to archive and revisit some. Having a clear searchable and predictable repo name will help.
Points to consider while establishing repository naming convention
- Minimum required words
- Should enable drill down.
- Its meaning should be deducible by any person knowing the naming convention.
- Any other person should almost also get to the same name if asked to name a repository with the given standard e.g. if person “A” names a repository “a.b.c” person “B” should also name it “a.b.~c”
Parts of repository name
- Organisation name – organisation name should be a part of repository name. Don’t worry about it being repeated with each repository.It will help in future.
- Technical Department – Its the next logical level. Department should be classified as per your organisation. An example could be iOS , Android, PHP, Testing, node etc.
- Content Type – what is contained in the repo. e.g Library, Front end ,Api, app.. At this level name should explain the content of the repository.
- Nature of the repository – What is the nature of repository is it something which is used by organisation on multiple projects or its specific to a client?
- Name of the package – finally the individual name of the package. It could be any name of your choice. If the previous segments of name has been properly thought of, it will never matter what you call your content.
Example format
<Company Name in short> – <ios | andriod | php | ng2 | node | testing .. > – < lib | api | frontend | app>-<core | client> – <component name>
So if we have to name a iOS app “bingo” which we are making for a client, than we will name it like
amar-iOS-app-client-bingo
Similarly if we have a PHP library for making our apis we can name it as
amar-PHP-lib-core-curdcreator
Hope the above put you on right track. These standards keep on evolving with the organisation.