TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Project Hosting and Collaboration Alternatives

23 posts · Sep 2014 – Dec 2025

What this trail covers

GitLab's integration management capabilities are evolving to streamline the connection of third-party applications with GitLab projects. Previously, integrations were managed only at the project level, requiring repetitive configuration for each project. The introduction of group-level integration management allows for simultaneous configuration of integrations across all projects within a group, saving significant administrative time and effort. This feature also enhances security by enabling better control over access and permissions. This post details the benefits of consolidating to a single tool for improved collaboration, security, and administrative overhead reduction, highlighting GitLab Enterprise Edition's capabilities for project sharing and permission management.

All GitLab trails
  1. Guide: Migrate from Azure DevOps to GitLabThis post details the process and tooling for migrating from Azure DevOps to GitLab. It outlines the benefits of GitLab's integrated controls, security testing, and AI capabilities. It introduces Congregate and the built-in Git repository importer as tools for migrating repositories, pull requests, and other assets. The post also covers planning considerations, inventorying migration needs, determining migration timing, and mapping organizational structures from Azure DevOps to GitLab. It highlights the differences in how work items and boards are handled, and the importance of planning permissions mapping.
  2. Streamline migrations with user contribution and membership mappingIntroduced post-import user contribution and membership mapping for group and project imports. This allows for reassignment of contributions to users on the destination instance after import completion, independent of email addresses. Imported contributions are initially mapped to placeholder users and require explicit acceptance by the destination user. This feature is available for direct transfer, GitHub, Bitbucket Server, and Gitea importers. Future enhancements include CSV-based reassignment and improved UI visibility for placeholder limits.
  3. How to tailor GitLab access with custom rolesThis post details the evolution of GitLab's access control system, moving from fixed default roles to customizable roles. It introduces the concept of a consistent CRUD (Create, Read, Update, Delete) model for defining permissions and discusses the ability to build custom roles from templates or from scratch, removing the dependency on default roles. The post also highlights the need to address a wide range of access permutations and provides examples of permission groupings for registries and developers.
  4. Enhanced migration from Bitbucket Server and Bitbucket Cloud to GitLabIntroduced parallel, asynchronous importers for Bitbucket Server (GitLab 16.1) and Bitbucket Cloud (GitLab 16.6) to prevent timeouts on large project imports. Improved error handling to prevent single object errors from stopping the entire import. For Bitbucket Server, fixed issues with imported merged/closed merge requests lacking commit data (GitLab 16.5) and began importing reviewers (GitLab 16.3) and pull request approvals (GitLab 16.6). For Bitbucket Cloud, fixed issues with squashed and merged pull requests not having associated commits (GitLab 16.6), converted Bitbucket refs to GitLab refs in comments (GitLab 16.6), stopped importing deleted notes (GitLab 16.6), began importing LFS objects (GitLab 16.5), and imported pull request reviewers (GitLab 16.6).
  5. GitHub to GitLab migration the easy wayThis post details the process of migrating projects from GitHub to GitLab using GitLab's built-in importer. It outlines the types of data that can be migrated (repository description, Git data, branch protection rules, collaborators, issues, pull requests, wikis, milestones, labels, release notes, attachments, comments, LFS objects, reviews, and events), the prerequisites for migration (Maintainer role, matching email addresses), and a step-by-step guide to performing the import. It also covers the manual migration of GitHub Actions to GitLab CI/CD pipelines by creating a `.gitlab-ci.yml` file and defining jobs that replicate the functionality of the original Actions, including examples for linting, smoke tests, and unit tests.
  7. How to migrate data to GitLab using main importersThis post details the evolution of GitLab's data migration capabilities, focusing on group migration (direct transfer) and file-based export/import. It outlines the process and imported items for group migration, emphasizing its preference over file-based methods for connected instances. It also details the items importable from GitHub, including repository data, issues, pull requests, and attachments, and mentions the 'Repository by URL' import option. The post highlights the ongoing development efforts by the group:import team to enhance these importers.
  8. Moving projects easily: GitLab migration automation benefitsIntroduces the beta for migrating GitLab projects by direct transfer, allowing for automated migration of top-level groups and all their projects between GitLab instances. This improves efficiency over file exports and correctly maps user associations. Details availability, configuration for self-managed instances, and provides step-by-step instructions for using the feature. Outlines future improvements including granular imports (subgroups, project selection), importing project relations, and automatic user migration.
  9. Arm Open Source makes a seamless migration to GitLabThis post details Arm's migration of its open-source projects to GitLab. Key technical aspects include: consolidating stand-alone Git servers and public web-based Git services into a single GitLab solution; leveraging GitLab's open-source nature to host on native Arm-based hardware and use internal tooling; addressing concerns about proprietary solutions and code ownership by choosing an open-source platform; and the successful integration of GitLab with Arm's infrastructure, including support for Arm architecture and fine-grained access control on AWS Graviton EC2 instances. The migration also highlights the ease of setup for CI/CD, tool simplification, and improved collaboration.
  10. Postman integration with GitLab makes API workflows easierThis post introduces a new integration between Postman and GitLab. This integration allows users to link APIs in Postman to their GitLab cloud repositories, enabling version control within Postman for API elements like branches, releases, versions, and tags. It also facilitates pushing Postman-created elements (schema, collections) to GitLab repositories to coexist with source code, and allows for following branching workflows in Postman with review and merging of external changes back to Postman. The integration aims to provide a unified view of API elements and reduce the use of outdated APIs.
  11. Migrating repositories to GitLab just became easierIntroduced Congregate, a utility to automate the migration of source code repositories and associated users to GitLab. Congregate is now source-available under the GitLab EE license, allowing customers and partners to leverage its functionality. The tool optimizes performance using multiprocessing and provides a standard logging format for auditability. A learning path for partners and customers to earn a 'Certified GitLab Migration Engineer' badge has been released.
  12. Kali Linux: Growing Community Contributions with GitLabThis post details how Kali Linux migrated from Gitolite to GitLab to enable community contributions, consolidate their tool stack into a single platform, and leverage GitLab's feature-rich API for automation. They specifically use GitLab for source code management, internal documentation via Wiki, project management (issues, threads, labels, milestones), user permissions with automatic expiration, security features like 2FA and project access tokens, and analytics. They are exploring CI/CD, container management, and GitLab Pages for their website. The migration involved automating find/replace for hardcoded links, importing ~1000 repositories into a structured group hierarchy, and converting WordPress content to Markdown. The key change observed in their open-source community is the enablement of public contributions, leading to merge requests, bug reports, and bug fixes. They also highlight the usability of GitLab's project organization and the benefits of the GitLab for Open Source program.
  13. Integration management for git projectsThis post announces the expansion of integration management capabilities in GitLab. It highlights the introduction of group-level integration management in GitLab 13.6, building upon the project-level management added in 13.3. The post details the benefits of group-level management, including time savings for administrators and enhanced security. It also outlines future considerations such as inheritance overviews, per-field inheritance, field masking, and inheritance locking. The deprecation of Service Templates is also announced, with a planned deprecation in GitLab 14.0.
  14. GNOME: two years after the move to GitLabThis post details GNOME's adoption and usage of GitLab Community Edition for various aspects of their project, including project hosting, documentation, CI/CD, issue tracking, and kanban boards. It highlights the positive impact on community contribution and transparency, as well as challenges related to specific permission requirements for translation teams. The post also touches on the importance of CI/CD awareness and the desire for more concrete metrics on community changes.
  15. A visual prototype of Drupal.org's GitLab integrationThis post details the technical collaboration between Drupal.org and GitLab to integrate Drupal.org's version control system with GitLab. It highlights specific API issues resolved (git merge-base web API, email confirmation API, display URL configuration, hiding user email, developer role delete tags, GL_REPOSITORY in update hooks, deduplication of Git objects) and the development of a custom `versioncontrol_gitlab` module extending `versioncontrol_git`. The post also mentions migration phases and testing efforts.
  16. Welcome to GitLab, freedesktop.org!This post details freedesktop.org's migration to GitLab from a disparate set of services (LDAP, Bugzilla, Mailman, cgit, Patchwork, Jenkins, ikiwiki, FTP). The migration aims to consolidate workflow by integrating repository management, issue tracking, code review, CI pipelines, container repositories, wikis, and websites into a single application. This consolidation is expected to reduce administrative overhead, improve user experience by providing a unified platform, and enhance identity and security management through GitLab's single identity service, two-factor authentication, and improved spam handling.
  17. Customer Story: Moving to GitLab! Yes, it's worth it!This post details a customer's migration from GitHub to a self-managed GitLab instance, highlighting significant cost savings by comparing GitLab's self-hosted CI/CD capabilities (GitLab Runner) against paid third-party CI services like Travis-CI, and comparing GitLab's unlimited user/repository model against GitHub's evolving per-user pricing for private repositories. It also provides practical guidance on installing and configuring GitLab CE, including common gotchas and tips for importing large repositories.
  18. Customer Story: ChargeCharge, a small telecommunications startup, migrated from raw Git with git+ssh to GitLab Community Edition for their 25 repositories and 5 developers. This migration was driven by the need for a web interface for repo management and code review, and strict industry regulations concerning customer information (CPI) security. GitLab CE's self-hosted nature and privacy controls were paramount. The team uses Google OAuth integration, webhooks, and Git hooks for build server integration, leading to decreased deployment times and increased confidence.
  19. The future of SaaS hosted Git repository pricingThis post discusses the evolution of SaaS hosted Git repository pricing, specifically in response to GitHub's announcement of unlimited private repositories. It argues that unlimited repositories are becoming a standard offering ('table stakes') in the market. GitLab's pricing model is highlighted as being per-user, which is considered more predictable and aligned with the value organizations receive, especially with the rise of microservices. GitLab.com offers a free tier with unlimited private repositories, unlimited contributors, and unlimited CI runners, funded by its on-premises solutions. The post also touches on the performance challenges faced by GitLab.com due to rapid growth and ongoing efforts to improve it.
  20. Why move to a single code collaboration tool?This post argues for consolidating code collaboration tools to a single platform like GitLab Enterprise Edition. It outlines the problems of managing multiple tools: difficulty in collaboration, complex security management (patching, permissions), integration overhead, and increased vendor management. It proposes that a single tool improves collaboration by simplifying project sharing and permission management, reduces security burden by consolidating patching and permission schemas, frees up admin resources by reducing maintenance overhead, and lowers commercial overhead with a single point of contact and contract. It addresses caveats like workflow restriction by highlighting Git's flexibility and GitLab Flow, and scalability with Reference Architectures and disaster recovery. It also mentions migration from SVN and GitHub as next steps.
  21. How GitLab Permissions and Protected Branches Keep Your Code SafeThis post introduces GitLab's permission system, defining roles like Guest, Reporter, Developer, Maintainer, and Owner based on read/write access. It also details the 'protected branches' feature, which prevents force pushes and deletions on specified branches, mandating merge requests for contributions to these branches. The underlying authorization mechanism using the 'Six' gem and its 'Ability' class is also explained.
  22. The 7 Most Important Open Source Workflow Practices for EnterprisesIntroduced the concept of 'inner-sourcing' by detailing seven key open-source workflow practices (visibility, forking, pull/merge requests, testing, CI, documentation, issue tracker) and explaining their applicability and benefits for enterprises. Highlighted GitLab's role in enabling these practices, particularly through the introduction of an 'internal' project visibility level.