Creating a Repository
Creating a Repository
This guide explains how to create and configure a new repository. Remember – if you create a repository you are also responsible for maintaining it.
Naming
A good repository name allows users to accurately guess its contents. Repositories in Flutter-Global
follow the conventions:
- repository names MUST be lower case, using a dash (
-
) as a word separator. - a general capability documentation repository should be prefixed with
cap-
e.g.cap-cashout
. - use a common relevant prefix to group several related repos together. e.g. for the fixed odds cashout quote functionality this is
fcq-
. - for the primary repository of an application use
-service
suffix, e.g.fcq-service
. - supporting repositories can be referred to as a
lib
(shared library code),tests
(separate testing code) ortool
(a supporting utility) - each division usually maintains its own service deployment with a repository for each specific divisional configuration. If these repos live in
Flutter-Global
they usually containconfig
to indicate their contents. Since they are owned by a particular division that is indicated by a suffix (-ppb
,-fdg
, or-isp
). e.g.fcq-config-ppb
contains PPB deployment config for the FCQ service.
Creating
Every user in Flutter-Global
has permission to create a new repository in the normal way in GitHub. Use the + drop-down menu on the top-right corner of a GitHub page and select New repository.
In the Owner drop-down, select the Flutter-Global Organization, this is where our inner source code is shared.
Enter the name of your repository and a description.
Within Flutter-Global, all repositories have Internal visibility. If you want something different, please contact the inner source team.
Choose how you want to initialise then continue to create the repository. Creating the repository manually simply gives you an empty repository that you have full admin control over but has not been yet been appropriately configured.
Configuring
To setup your repository you will need to define:
- a branching strategy: where is the code initially contributed to and then merged into?
- an access control strategy: who can access the repository, and with what permissions?
- branch protections to ensure the combination of (1) and (2) is secure.
If you are familar with GitHub and know what you want you can simply go ahead and configure as you wish. If you are uncertain we recommend:
- Consider using one of the standard source control patterns.
- Use the Codebase Governor tool to config your branch protection and access control via a GitOps file-based workflow.