Create a source code repository

Each project can have one or more source code repositories.

1. Click SOURCE CODE from the Project Home menu.
2. In the list of the project repositories, click Create Repository.
3. Choose the server on which you want to create the repository.
   Note: The drop-down list shows all of the SCM servers that the TeamForge administrators have added to the TeamForge environment.
4. On the Create Repository page, enter the directory name for the repository.
   Note: For CVS repositories, the directory name is the name of the directory relative to the CVS server's repository root directory. A UNIX group by the same name is also created to enforce permissions.
5. Enter a name and description for the repository. If you plan to use an SCM server that requires approval for new repositories, use the DESCRIPTION field to provide your reason for asking to create this repository.
6. If you are creating a Git repository:
   1. Select a Repository Category.
      This is where you define the code review policy for your repository.

      • Default - no review (default): No review is required for pushing changes to the repository.
      • Pull request: Users can create and push to feature branches but require pull requests to certain “protected branches”. See Review code for more information.
      • Optional review: Every change submitted to the repository can be pushed for code review or directly pushed to the repository bypassing review. This depends on the TeamForge user having the appropriate permissions — source code "Delete/View" or "Commit/View" permission for the former and source code "Admin" permission for the latter.
      • Mandatory review: Every change pushed to the repository must pass through a review process before it can be pushed (merged) to the repository.
      • Custom: Users with TeamForge source code "Admin" permission to directly fine tune permissions (access rights) in Gerrit’s web interface. Such changes are not overridden by TeamForge.
      • User defined: User defined code review policy.
      For more information, see the following blog posts that talk about access right mappings between TeamForge and its Gerrit integration.

      • What Gitflow is, and how to best use it with TeamForge/Gerrit user defined repository policies.
      • How to implement your own user-defined repo category with branch based permissions.
      • Alternative approaches to implement branch based permissions (without user-defined repo categories) and when to use which approach.
   2. Enable history protection, if required. Select the Protect History check box.
   3. If you are enabling Git Large File Storage (LFS), select a value for LFS Enabled and MAX LFS Object Size fields. For more information, see Set up LFS.
7. If you want to require that each code commit be associated with an artifact (or a task or some other work item), select Required on Commit. Selecting this check box enables the following options:
   • Artifact must be in open state: Select this check box to ensure that users cannot perform a commit for closed artifacts. Therefore, if a user attempts to commit changes for a closed artifact, an appropriate error message is displayed.
     Note: When the commit log includes multiple artifact ids, then all artifacts must be in the OPEN state for the user to perform a commit.
   • Committer must Own Artifact: Select this check box to ensure that only an artifact owner can perform the relevant commit. If the committer is not the artifact owner, then an appropriate error message is displayed preventing them from committing the changes to the specific artifact.
     Note:

     • In the case of a Git repository, the pusher who pushes the commits must be the owner of the artifact.
     • Once you enforce the above rules, validations are strictly enforced for commits against tracker artifacts only. In case you commit against any other TeamForge object, for example a wiki or a document, mere existence of the object ID ensures successful commit and association; no validations are performed against the status of the object or who it is assigned to.
8. For security reasons, you may want to restrict email notifications to the essential information. If so, select HIDE DETAILS IN MONITORING MESSAGES.
9. By default, the Available in Search Results check box is selected. Clear the check box if you want to exclude the repository from searches.
   Tip: You have the ability to control whether source code is included in search results. For example, you may want to exclude source code from searches that have sensitive information. You may also want to omit some repositories, such as the branding and publishing repositories, from search results. The Available in Search Results setting in Create Repository or Edit Repository page allows you to configure this. By default, this option is selected for all repositories, except for the branding repository in the look project and for Publishing repositories.
10. Click Save.