git naming guidelines - sauter-hq/git-guidelines GitHub Wiki

Git Naming

This page determines how git repositories should be named following what they contains and how they are going to be searched and used. This has been decided after observing different practices on the web and defined by the Electronic Dept. as well as the Applied Science Dept. in two meetings (Meetings protocols)

Repository name composition

The repository names are composed of multiple reserved keywords separated by -. Each concatenations of reserved keywords is defined by the list below.

The reserved keywords should be used only when a keyword fits perfectly, if one is missing, please define it here before usage.

Reserved keywords

This is a list of reserved keywords for repository name compositions.


application, app

Any repository prefixed with the application or app keyword should contain an application which can run as separate process on some platform.

Name structure: application [-<target-platform> if relevant ] -<application-name> Name structure: app [-<target-platform> if relevant ] -<application-name>

Examples :

  • application-license-daemon : The license daemon which can be used on any OS or platform. Or which is supposed to be usable on any platform.
  • application-moduwebvision : The multiplatform moduWeb Vision webserver.
  • app-alien-bus-connector : The application for alien bus connection.

bootloader, bldr

Any repository prefixed with the bootloader or bldr keyword should contain a bootloader for some platform.

Name structure: bootloader [-<target-platform> if relevant ] -<name> Name structure: bootloader [-<target-platform> if relevant ] -<name>

Examples :

  • bldr-lpc17xx-as521 : The bootloader for subsystems of the AS521 for lpc17xx.

config

Any repository prefixed with the config keyword should contain only configuration for some products or server/pc setups.

Name structure: config-<target-program-name>

Examples :

  • config-eyws500f005 : Configuration files for the signature of update packages of ey-ws500f005
  • config-apache-proxy : Default configuration for apache webserver as web proxy.

course

Any repository prefixed with the course keyword should contain documentation and material for a teaching course.

Name structure: course-<course-name>

Examples :

  • course-cpp-template-metaprogramming : Course about C++ template metaprogramming.
  • course-algebra : Course about algebra.

devtool

Any repository prefixed with the devtool keyword should contain a development tool which can be used on the developer pc to automate or ease some tasks.

Name structure: devtool-<development-tool-name>

Examples :

  • devtool-sisulizer4j : Development tool used to import sisulizer file to java properties files.
  • devtool-licensegenerator : Development tool which can generate developer licenses to test licensed softwate.
  • devtool-code-reformatter : Development tool to reformat the code base to the K&R coding principles.

toolchain

Any repository prefixed with the toolchain keyword should contain a compiler toolchain. Nothing else. No BSPs.

Name structure: toolchain [-<architecture>] -<platform>-<name>

Examples :

  • toolchain-llvm : The llvm toolchain which is multiarchitecture per design.
  • toolchain-arm-phycardL-oselas-gcc : Development tool which can generate developer licenses to test licensed softwate.

testtool

Any repository prefixed with the testtool keyword should contain a tool which can be used to test some aspects of a software or hardware. For example a benchmark for performance test would be an application.

Name structure: testtool-<testtool-tool-name>

Examples :

  • testtool-perfsuite : Performance testing suite.

framework

Any repository prefixed with the framework keyword should contains a framework for application or product development. A framework is different to a lib, in that that it forces the developer to develop in some specific way to benefits from the framework features. A library is a tool that can be used freely and flexibly by anyone.

Name structure: framework-<framework-name>-<framework-component>

Examples :

  • framework-baf-core : The core component of the baf framework ( i.e. Building Automation Framework )

lib

Any repository prefixed with the lib keyword should contains a reusable library source code. And help on how to use it.

Name structure: lib-<programming-language>-<lib-name>

Examples :

  • lib-cpp-boost : The boost library for the C++ language
  • lib-java-spring : The spring library for the java language.

misc

Misceallenous unsorted projects. This is mainly for import of monolithic SVN repositories.

Name structure: misc-<name>

Examples :

  • misc-embedded-firmware : All embedded firmware, softwares, bootloader, stuffs, docs...

os

The content of the repository is necessarily the source code an operating system.

Name structure: os-<os-name> [-<target-platform> if relevant]

Examples :

  • os-linux : The linux operating system, as it is multiplatform, or as platform port can be maintained as branch this doesn't have a specific target-platform within it's name.
  • os-emboS-arm7 : An operating system which is platform specific to arm7.
  • os-freertos : The freertos operating system which is platform independent, all platform specificities should be handled as branches.

product

So that products can be found quickly the keyword product is reserved for them. In product-* repositories everything to get the product working should be available. This is either a repository contains all the source code and details on how to get the product built and working or repository linking different git submodules to find all the parts which allows the product creation.

Name structure: product-<product-family>-<product-type>-<product-name>

Examples :

  • product-modulo5-station-ecos500 : A station of the modulo5 family known as ecos500
  • product-sensors-pressure-sdx100g1 : A pressure sensor known as sdx100g1

study

All the research and study projects needed to check the feasability of something will be prefixed by the study- keyword.

Name structure: study-<study-name>

Examples :

  • study-ConfigSimpleDevicesTool : A study about configuration tool of simple devices
  • study-ipv6forAutomationDevices : A study about ipv6 for automation devices

specs

The specifications of a project, that is to say concept document and projects statement-of-work can be prefixed with specs. Once the project has an implementation the doc should be migrated next to the project, that is as git submodule or as git subtree.

Name structure: specs-<project-or-product-name>

Examples :

  • specs-opensource-license-exporter : Requirements and statement of work for the the opensource-license-exporter tool.
  • specs-license-system-for-devices : The specifications of the license-system for devices.

unittests

This keyword is thought for repositories containing unit tests only.

Name structure: unittests-<project-or-product-name>

Examples :

  • unittests-database : The unittests for the database application.

building-automation-project

This is a keyword meant for prefixing building automation project (e.g. CASE Engine Project).

Name structure: building-automation-project-<site>-<building>-<floor>-<room>

Examples :

  • building-automation-project-sba-03-02-xx : The automation project with documentation and CASE Engine plan for the floor where the Applied Science dept. resides.

⚠️ **GitHub.com Fallback** ⚠️