ACCESSHUB.APP

Your Git Repositories Helper
Git TipsContact

Git Tips & Best Practices

Essential Git workflows, repository comparisons, and downloadable resources for better development

Tip 1

Repository Platform Comparison

How to Choose a Git Platform

When choosing a repository provider for your projects (GitHub, GitLab, Bitbucket), each platform offers different strengths and features that may suit different team needs and workflows.

For Unity Developers: GitLab is recommended due to its 10GB storage limit vs GitHub's 1GB limit. Unity projects often exceed 1GB and include files over 50MB, making GitLab the practical choice.

Platform Comparison

GitHub

Pros: Most people have accounts, easiest to use

Cons: 1GB project limit (Unity projects often exceed this), 100MB file limit

Cost: Free for small teams, $4/user/month for teams

Bitbucket

Pros: Good for very small teams (5 users max free)

Cons: 2GB project limit, strict 5-user limit, fewer features

Cost: Free up to 5 users, $3/user/month

GitLab Recommended

Pros: 10GB project limit, handles large Unity files better, free tier works for most

Cons: Less familiar interface for some users

Cost: Free tier sufficient for most, $19/user/month for premium

Summary

Choose GitHub for its large community and ease of use, GitLab for comprehensive DevOps capabilities, and Bitbucket for Atlassian integration - but consider the limitations and pricing that fit your team size and project requirements.

Tip 2

Basic Good Practices

Simple Rules

  • Commit messages: Write what you changed (e.g., "Fixed player jump bug")
  • Branch names: Use clear names like "fix-player-jump" or "add-new-level"
  • Commit often: Save your work daily, don't wait weeks
  • Automate builds: Set up automatic builds on every commit - cheap, easy, and incredibly useful for finding when features break
  • Don't build locally: Invest in automation instead of manual Unity builds

Key Takeaway

Keep it simple: write clear messages, use descriptive names, save regularly, and automate your builds to catch problems early.

Tip 3

GitHub Desktop for Artists & Non-Technical Team Members

Perfect for Artists & Designers

GitHub Desktop makes Git simple and visual. No command line, no complicated setup - just click buttons to save and sync your work.

Why It's Better Than Other Git Tools

  • Visual interface: See your changes clearly with before/after comparisons
  • One-click sync: Push and pull changes with a single button
  • No technical knowledge needed: Built for people who just want history and safety
  • Works with any Git platform: GitHub, GitLab, Bitbucket - all supported

Getting Started

Download GitHub Desktop, sign in with your account, clone your repository, and start working. When you're done, write a simple message about what you changed and click "Commit" then "Push".

Summary

GitHub Desktop removes Git's complexity and makes version control accessible to everyone on your team, regardless of technical skill level.

Tip 4

Unity .gitignore Template

Why You Need This

Unity creates many temporary files that waste space and slow down your repository. A .gitignore file tells Git to skip these unnecessary files when committing.

What Gets Ignored

Library folder, Logs, Temp files, and other Unity-generated content that you don't need to backup.

.gitignore for Unity
# Unity generated files
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Aa]ssets/AssetStoreTools*
/[Aa]ssets/Plugins/
*.pidb
*.booproj
*.tmp
*.user
*.userprefs
*.unityproj
*.DS_Store

Quick Setup

Download our .gitignore file, put it in your Unity project root, and never worry about temporary files cluttering your repository again.

Tip 5

GitLab says your namespace is over the 5 user limit

The message GitLab shows you:

GitLab
Your namespace Utin Dev is over the 5 user limit

Your own group name appears where ours does. The rest of the line is the same for everyone. Your namespace [your group name] is over the 5 user limit

What it actually means

The free plan on gitlab.com allows 5 users in a private top-level group. Go over that and the whole namespace is put into a read-only state. Your code is still there and you can still read it, but you cannot push, and new packages, container images and LFS files are blocked until you are back under the limit.

Why the count is higher than your team

The number GitLab counts is almost always bigger than the number of people you think of as the team. It includes:

  • Everyone in the top-level group, in every subgroup, and in every project inside it
  • People added to a single project directly, rather than through the group
  • People with the lowest role, who only ever look at things
  • People who reach a project through another group that was invited to it
  • Anyone who did one job a year ago and was never removed

One thing that does not count: an invitation nobody has accepted yet. Worth clearing up, but it is not taking a seat.

How to get back under the limit

  1. Look at everyone who has access anywhere in that namespace in one list, instead of going project by project.
  2. Take out the people who left and the contractors who finished.
  3. Check where each person's access comes from. If they are a member of the group, removing them from a project changes nothing. They still count and they still get in.
  4. Once you are at 5 or fewer, the read-only state lifts.

The mistake that wastes an afternoon

Removing somebody from a project does not remove them if their access comes from the group above it. The project member list looks clean, the person still has access, and they still count towards your 5. This is the single most common reason people remove users and stay over the limit.

If you really need more than 5 people

Your other options are making the top-level group public, moving to a paid plan, starting the 30 day trial, or running GitLab on your own server, which has no user limit at all.

Bitbucket's free plan has the same 5 user cap, and the same habit of counting people you had forgotten about.

How AccessHub helps

This is the exact job we built the tool for. Connect your GitLab account and you get one table: every project across the top, every person down the side, their role in each cell. You see straight away who is counted, who has not touched anything in months, and who is getting in through a group rather than the project. Then you remove people from several projects in one pass instead of opening each project in turn. It works the same on gitlab.com and on your own GitLab server, and it also covers GitHub and Bitbucket.

There is a demo on the front page that runs on made-up data, so you can see the whole thing before connecting anything.

Removing one person from every project at once

Tip 6

Removing one person from every project at once

Why this is harder than it should be

Membership is stored per repository. None of the three platforms has a screen that shows every repository one person can reach, so removing them means opening each project in turn and trusting that you remembered all of them. On a team with thirty projects, that is where people get missed.

The manual way, per platform

  • GitLab: open the project, go to Manage then Members, find the person and remove them. If their access comes from a group, do it on the group instead, otherwise it comes straight back.
  • GitHub: an organisation's People page lists members, but not which repositories an outside collaborator can reach. Outside collaborators are removed per repository under Settings then Collaborators and teams.
  • Bitbucket: remove from the whole workspace under Workspace settings then User directory, or from a single repository under Repository settings then User and group access.
  • By script: GitLab has DELETE /projects/:id/members/:user_id over the list from GET /projects?membership=true, GitHub has DELETE /repos/:owner/:repo/collaborators/:username, and Bitbucket has an equivalent under repository permissions. Fine if you do this often, painful if you need it right now.

Three ways a removal quietly fails

Access inherited from a group does not go away when you remove somebody from a project. People who reach a project through a shared group do not appear in the normal member list at all, so you never see them to remove them. And an invitation that was sent but never accepted still sits there waiting. In all three cases the member list looks clean and the person is still in.

A checklist that actually holds

  1. List every project the person can reach, not only the ones you remember.
  2. For each one, check whether the access is direct or inherited.
  3. Remove it at the level it actually comes from.
  4. Cancel any pending invitations in their name.
  5. Look again afterwards. A ticked checklist is not the same thing as access being gone.

How AccessHub helps

Pick the person and you see every project they can reach in one row, with the role in each cell and where each one comes from. Remove them from all of it in one pass, and check the row again straight after. It works across GitLab including self-hosted, GitHub and Bitbucket, so somebody who is in repos on two platforms is still one job rather than two.

The demo on the front page runs on made-up data, so you can see how the removal works before connecting a real account.

GitLab says your namespace is over the 5 user limit

Tip 7

See every member of every repo in one grid

Why no platform shows you this

Membership is stored per repository, so every provider shows you one repository at a time. There is no screen on GitHub, GitLab or Bitbucket that answers the plain question: who has access to everything we own, and at what level. That is why the answer on every forum thread ends with "write a script".

Where each platform actually keeps it

  • GitHub: Settings, then Collaborators and teams, one repository at a time. The organisation People page lists members, but it does not tell you which repositories an outside collaborator can reach.
  • GitLab: Manage, then Members, per project. Anyone who gets in through a parent group is shown as inherited, and cannot be removed from that screen.
  • Bitbucket: Repository settings, then User and group access. Workspace membership is a separate list under Workspace settings, and it is the one your bill counts.

The script everyone ends up writing

List your repositories, then loop over them and ask each one for its members. GitHub has /repos/:owner/:repo/collaborators, GitLab has /projects/:id/members/all, Bitbucket has its permissions endpoints. Handle pagination, handle rate limits, and you have a spreadsheet that is out of date the day after you run it.

And three things that loop still misses

  • Access inherited from a group or team, which does not appear on the project member list unless you ask for it specifically.
  • Workspace or organisation membership, which is separate from repository access and is usually what you are being billed for.
  • Invitations that were sent and never accepted. They do not take a seat yet, but whoever clicks one is straight in.

What the grid does instead

Connect a token and you get one table: every repository across the top, every person down the side, their role in each cell, and a mark on the ones whose access is inherited rather than direct. It reads through the same APIs you would have scripted, across GitLab including self-hosted, GitHub and Bitbucket at once, and it is current every time you open it. From that table you can remove somebody from everything in one pass instead of repeating the loop by hand.

The demo on the front page runs on made-up data, so you can see the shape of it before connecting anything.

GitLab says your namespace is over the 5 user limit ยท Removing one person from every project at once