GitLab is a code repository platform researchers can use to share code with collaborators and track versions of software. GitLab is useful for projects in which multiple collaborators are writing different parts of the code base, working with multiple versions of the software, or deploying the software for use in new projects.

Git is software that is commonly used in research to version control source code. If you want to learn more about using Git, consider taking a Software Carpentry Workshop through the Data Science Hub.

GitLab and GitHub are web platforms based on Git that store remote copies of Git repositories, allowing your code to be backed up to another location besides your computer. They also allow you to share your repositories with collaborators.

Comparisons between the three, including the type of license agreement for each and how it protects the intellectual property of your or a third party’s code are summarized here:

The answer is: it depends! If you are using software that is covered by a contractual agreement with an outside party, the software license might specify terms of use or you might want to consult with a contractual specialist in your department/unit or the University Office of Legal Affairs (https://legal.wisc.edu/), before using GitLab with this software.

If it is determined that you can use GitLab for your proprietary software, ensure the appropriate user attestation process and management in place. For example, make projects with proprietary software private and limit the membership as much as possible.

GitLab is a repository and collaborative platform for working code but it should not be used as a repository for making code accessible to the public. Best practices for making code publicly accessible include; using a repository that is designed to archive code long term and provides permanent digital object identifiers. For more information, consult resources in the UW Madison Libraries Data Sharing Essentials and the Researcher Toolkit.

GitLab has several visibility options to facilitate collaboration across projects. Contributors to the project must have an active UW Madison Net ID to contribute to the project and to make pull requests. The three visibility options are:

1. Public
2. Internal
3. Private

GitLab can be used to make your code publicly available to anyone by changing the project's visibility to Public. However, contributors to your code base would have to have a UW-Madison NetID to make pull requests and contribute to the project.

Tools like GitLab are designed to support several software development practices commonly referred to as DevOps. DevOps is a term that emphasizes the importance of closely integrating the development and operations cycles of software. This makes it easier to:

• Catch and correct bugs during all stages of software development
• Shorten the time for delivering new versions and releases of the software

DevOps includes the practice of Continuous Integration/Continuous Delivery (CI/CD). This practice focuses on:

• Automating code build updates
• Testing
• Delivery

GitLab’s CI/CD features include automation tools for creating components such as pipelines for compiling and testing code.  

The DevOps concept may be applicable to your research if you and your collaborators are iteratively developing new versions of software that:

• Will be used by multiple individuals
• Need testing that is regularly or automatically performed
• Require bug fixes and code updates to be managed in each version

The KB article “Migrating your code from RStudio to GitLab” provides the steps for migrating code to GitLab.