In GitLab, you can create projects for hosting your codebase, use it as an issue tracker, collaborate on code, and continuously build, test, and deploy your app with built-in GitLab CI/CD.
Your projects can be available publicly, internally, or privately, at your choice. GitLab does not limit the number of private projects you create.
When you create a project in GitLab, you'll have access to a large number of features:
Issues and merge requests:
- Issue tracker: Discuss implementations with your team within issues
Repositories: Host your code in a fully
- Branches: use Git branching strategies to collaborate on code
- Protected branches: Prevent collaborators from messing with history or pushing code without review
- Protected tags: Control over who has permission to create tags, and prevent accidental update or deletion
- Signing commits: use GPG to sign your commits
- Merge Requests: Apply your branching strategy and get reviewed by your team
- Labels: Organize issues and merge requests by labels
- Time Tracking: Track estimate time and time spent on the conclusion of an issue or merge request
- Milestones: Work towards a target date
- Description templates: Define context-specific templates for issue and merge request description fields for your project
- Slash commands (quick actions): Textual shortcuts for common actions on issues or merge requests
GitLab CI/CD: GitLab's built-in Continuous Integration, Delivery, and Deployment tool
- Container Registry: Build and push Docker images out-of-the-box
- Auto Deploy: Configure GitLab CI/CD to automatically set up your app's deployment
- Enable and disable GitLab CI
Pipelines: Configure and visualize
your GitLab CI/CD pipelines from the UI
- Scheduled Pipelines: Schedule a pipeline to start at a chosen time
- Pipeline Graphs: View your entire pipeline from the UI
- Job artifacts: Define, browse, and download job artifacts
Pipeline settings: Set up Git strategy (choose the default way your repository is fetched from GitLab in a job),
timeout (defines the maximum amount of time in minutes that a job is able run), custom path for
.gitlab-ci.yml, test coverage parsing, pipeline's visibility, and much more
- GKE cluster integration: Connecting your GitLab project with Google Kubernetes Engine
- GitLab Pages: Build, test, and deploy your static website with GitLab Pages
- Cycle Analytics: Review your development lifecycle
- Syntax highlighting: An alternative to customize your code blocks, overriding GitLab's default choice of language
Integrate your project with Jira, Mattermost, Kubernetes, Slack, and a lot more.
Learn how to create a new project in GitLab.
Fork a project
You can fork a project in order to:
- Collaborate on code by forking a project and creating a merge request from your fork to the upstream project
- Fork a sample project to work on the top of that
Set the project's visibility level and the access levels to its various pages and perform actions like archiving, renaming or transferring a project.
Read through the documentation on project settings.
Import or export a project
- Import a project from:
- Export a project from GitLab
- Importing and exporting projects between GitLab instances
Learn how to add members to your projects.
Leave a project
Leave project will only display on the project's dashboard when a project is part of a group (under a group namespace). If you choose to leave a project you will no longer be a project member, therefore, unable to contribute.
Redirects when changing repository paths
When a repository path changes, it is essential to smoothly transition from the old location to the new one. GitLab provides two kinds of redirects: the web UI and Git push/pull redirects.
Depending on the situation, different things apply.
- The redirect to the new URL is permanent, which means that the original namespace can't be claimed again by any group or user.
- Existing web URLs for the namespace and anything under it (e.g., projects) will redirect to the new URLs.
- Starting with GitLab 10.3, existing Git remote URLs for projects under the namespace will redirect to the new remote URL. Every time you push/pull to a repository that has changed its location, a warning message to update your remote will be displayed instead of rejecting your action. This means that any automation scripts, or Git clients will continue to work after a rename, making any transition a lot smoother. To avoid pulling from or pushing to an entirely incorrect repository, the old path will be reserved.
When renaming-a-repository, the same things apply, except for the Git push/pull actions which will be rejected with a warning message to change to the new remote URL.