Wen Ping

Posted on Oct 31 Edited on Oct 31 Originally published at anguskit.com

Choose a self-hosted Git platform: replace GitLab with repositories and pull requests

#git #angusgit #gitlab

This article explains how to choose among a bare Git server, GitLab, and AngusGit when a team wants to self-host Git on an intranet and replace GitLab. After reading it, you can judge the choice from the features people use every day — code hosting, pull requests, review, issues, and branch protection — and check separately whether pipelines, Git LFS, import scope, and accounts can move over as they are.

When people only push and pull code, a bare Git server is enough. A bare repository stores only Git data and has no working files you can edit. A bare Git server is that kind of repository plus SSH accounts. When you need pull requests and review, and builds can stay on Jenkins, AngusGit Community can replace an intranet GitLab. Built-in pipelines need Team or Enterprise.

1. List what the team uses every day

Before you compare platforms, write down how the team actually uses GitLab today. Hand this list to the team and ask people to mark the items they use every week:

Create a repository, clone, and push
Open a merge request, read the diff (the code difference) on the web, comment on a line, and approve or send it back
Track requirements and defects with issues, and track versions with milestones
Protect the main branch: block a direct push, and require an approved review before merge
Name who must review each directory (CODEOWNERS, a file that lists an owner for each directory)
Pipelines: build and test automatically after a commit
Store large files with Git LFS (a Git add-on that keeps large files outside the repository), such as design files and model files
A container image registry and a package registry
Connect a company directory, for example one sign-in through LDAP

The first five items are the main path of working on code together. The rest are surrounding capabilities. The main path has to be covered completely. For each surrounding capability, look for a replacement one item at a time.

A pull request is a request to merge one branch into another after someone reviews the change. GitLab calls the same thing a merge request. AngusGit's label is Pull Requests.

2. How the three options cover the main path

This table puts GitLab and AngusGit Community in one column and compares them with a bare Git server:

Feature	Bare Git server	GitLab and AngusGit Community
Repository hosting, push and pull over SSH / HTTPS	Yes (SSH)	Both
Browse code and commit history on the web	No	Both
Merge request / pull request	No	Both. The AngusGit label is Pull Requests
Code review on the web (diff, line comments, approve / request changes)	No	Both
Branch protection (block a direct push, require a review)	No	Both
CODEOWNERS assigns reviewers automatically	No	Both
Issues, labels, milestones, Releases, and Wiki	No	Both
Access tokens and deploy keys	No	Both
An operation record of who changed members, protection rules, and what was merged	No	Both. On AngusGit, look under Activity

The split is whether there is a website. A bare Git server can store code and can push and pull. It has no website, so it has no pull requests and no review. Every rule is a spoken agreement. As soon as the team requires "someone reviews a change before it lands on the main branch", you need a platform in the GitLab or AngusGit class.

On the main path, AngusGit Community and GitLab line up item for item. The differences are surrounding capabilities and migration details. The next section lists them.

3. What does not move straight across from GitLab

After the main path is covered, check surrounding capabilities and migration details one by one. Confirm pipelines and Git LFS first. Pipelines decide whether the team's build process changes after the replacement. Git LFS decides whether some repositories can move at all. The table shows what AngusGit does with each item, and what to do at replacement time:

Item	What AngusGit does	What to do when you replace
Pipelines	Built-in pipelines are available in Team and Enterprise. Community has no CI/CD menu. The config format is not the same as GitLab CI	On Community, keep building with Jenkins or the tool you already use. On Team or Enterprise, use Import GitLab CI in the console to produce a first draft, then edit it
Git LFS	Not supported	Put large files in an artifact repository or in Release attachments. Leave a repository that depends heavily on LFS where it is for now
Repository import	Filling in a source URL takes the current code on the default branch and saves it as one new commit	To keep the full history, every branch, and every tag, push with `git clone --bare` plus `git push --all` and `git push --tags`
Issues, Wiki, CI config, and protection rules	Import does not bring them	Recreate protection rules on AngusGit. Recreate issues and Wiki by hand when you need them
Repository mirror sync	None	During the move, let only the GitLab side accept writes. Push the repository in full once more before the cutover
Container image registry and package registry	Not inside AngusGit	Use the artifact repository AngusRepo, or the artifact repository you already have
Accounts and sign-in	Users, teams, and sign-in are managed by the companion user center, GM	Configure LDAP on GM Enterprise. AngusGit itself has no separate LDAP switch
User count	Community allows at most 10 users	Above 10 people, use Team or Enterprise

4. How deployment and operations differ

GitLab's all-in-one package includes a database, a cache, background jobs, Git storage, and other components. It covers a lot, and it also asks for more machine resources and more operations time.

AngusGit covers code collaboration. Deployment is two services: AngusGit itself, and GM, which handles users and sign-in. They share one MySQL or PostgreSQL database. A cache is optional, and there is no message queue. The minimum machine is 2 CPU cores and 4 GB of memory. When there are many repositories and many people, 4 CPU cores and 8 GB is the better starting point. Install through an interactive wizard. The intranet install article linked at the end has the steps.

5. Replace it in steps

After you decide to replace, go in this order. Each step can be checked on its own. Start the next step after the check passes:

Install and check Install AngusGit on the intranet. The check is four actions: create a repository, clone, push, and open and merge a pull request. If all four finish, the platform is usable.
Move one or two pilot repositories Pick one or two repositories that are active and not critical. Push the full history with git clone --bare plus git push --all and git push --tags. The team opens pull requests and reviews on the pilot repositories for a week or two, and you see whether daily work feels smooth.
Set the protection rules Turn on branch protection for main on the pilot repositories. Branch protection is the rule that blocks a direct push and requires an approved review before merge. Where different directories have different reviewers, add a CODEOWNERS file.
Handle builds Community keeps the build tool you already use. On Team or Enterprise, rewrite GitLab CI as a built-in pipeline, get it running on a pilot repository, then roll it out to the other repositories.
Move the rest, and keep GitLab read-only After the pilot is stable, move the remaining repositories in batches. When the move is done, make GitLab read-only and keep it for a while. Archive it after you confirm nothing was missed.

The full migration checklist is in the GitLab migration checklist linked at the end. It covers how to sync during dual-run (both platforms stay up for a while, and only one of them accepts writes) and how to roll back to GitLab when something goes wrong.

Common questions

Can Community be used inside a company?

Yes. Community uses the GPL-3.0 license. The source is public and you can use it freely. The limit is 10 users.

Can merge request history from GitLab come over?

No. The move includes the Git repository itself: commits, branches, and tags. Merge request discussions and review records stay on GitLab. After the move, keep GitLab read-only for a while so you can look them up.

We depend heavily on GitLab CI. Do the pipelines have to be rewritten?

Yes. AngusGit's pipeline format is not the same as GitLab CI. The Team and Enterprise console can import .gitlab-ci.yml and produce a first draft. You still handle include, artifacts, when: manual, and similar forms by hand. The GitLab CI migration article linked at the end shows how to rewrite them.

Summary

To choose a self-hosted Git, start with what the team uses every day. Push and pull only: a bare Git server is enough. Pull requests, review, issues, and branch protection: AngusGit Community lines up with GitLab on that main path and can replace an intranet GitLab. Before you replace, confirm four things. Pipelines need a rewrite, and they are available in Team and Enterprise. Git LFS is not supported. Import brings repository code only. Accounts are managed by GM. Move in this order: install and check, pilot repositories, protection rules, the build method, then the batch. Keep GitLab read-only first, and archive it later.

Conclusion: When the team's core need is repository hosting, pull requests, line-level review, issues, and branch protection, AngusGit starting at 2 CPU cores and 4 GB can replace an intranet GitLab. Before you replace, confirm that no repository depends heavily on Git LFS, and plan how CI will build.

DEV Community