KAHIBARO
Discord Login Register ☰
☰

3.8. GitHub and GitLab

Table of Contents

Why Backend Developers Use GitHub and GitLab

As a backend developer, you will almost always store your code on a remote Git hosting platform. The two most popular options are GitHub and GitLab.

Both are built around Git, which you will already have learned as your version control system. Git works locally, on your machine. GitHub and GitLab act as:

You can think of them as "social networks for code" plus many development tools.

In this chapter, you will see what is common between GitHub and GitLab, and where they differ, especially from a backend beginner's perspective.

Common Features: Git Hosting Platforms

GitHub and GitLab provide very similar core features. Understanding these shared features helps you switch between them easily.

Repositories

A repository (repo) on GitHub or GitLab is the remote copy of your local Git repository.

Typical workflow:

  1. You have a local repo created with git init or cloned.
  2. You create a remote repo on GitHub or GitLab (usually via the website).
  3. You connect local and remote:
bash 
git remote add origin git@github.com:username/project-name.git
# or
git remote add origin git@gitlab.com:username/project-name.git
  1. You push your code:
bash 
git push -u origin main

From now on you can pull and push between your local repo and the remote.

Public vs Private Repositories

Both GitHub and GitLab support free private repositories for individuals.

Branches and Pull / Merge Requests

You already know Git branches. The hosting platforms add collaboration workflows on top.

Feature Branches

Common pattern:

  1. You create a branch locally:
bash 
git checkout -b feature/add-login
  1. You make changes and commit:
bash 
git commit -am "Add basic login endpoint"
  1. You push the branch:
bash 
git push -u origin feature/add-login

Now the branch exists on GitHub or GitLab and others can see it.

Pull Requests (GitHub) / Merge Requests (GitLab)

After you push a branch, you usually open a request to merge your changes into the main branch.

They are conceptually the same.

Inside a PR/MR you can:

This is central to team development and code quality.

Issues and Project Management

Both platforms support issues which are like tickets or tasks.

Examples:

You can:

For backend projects, issues help you organize:

Both platforms also provide more advanced project management tools such as boards and milestones, useful for larger teams.

Wikis and Documentation

Both GitHub and GitLab can provide a wiki section for each repository.

You can document:

Although for many backend projects you will use Markdown files inside the repo (like README.md and docs/ folder), the built-in wiki can be helpful for teams.

GitHub Overview

GitHub is the most widely used Git hosting platform, especially in open source and many companies.

Key Concepts

User Accounts and Organizations

On GitHub you have:

Repositories can live either:

For a backend developer:

Stars, Forks, and Watch

GitHub is very social, and you will interact with open source often.

Example workflow to contribute to an open source backend library:

  1. Fork the repo.
  2. Clone your fork.
  3. Create a branch, make changes, push.
  4. Open a Pull Request from your fork to the original project.

This is how you might contribute to Python libraries, FastAPI, or any backend tool.

GitHub Pages

GitHub can host static sites from a repo. This is useful to:

For backend documentation you might generate static docs (with tools like MkDocs or Sphinx) and serve them with GitHub Pages.

Creating and Connecting a Repository

Example: you want to put your first backend project on GitHub.

  1. Create a new repo on GitHub (via the website):
    • Name: task-manager-api
    • Choose public or private
    • Do not initialize with README if you already have one locally.
  2. On your local machine, in the project folder:
bash 
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin git@github.com:your-username/task-manager-api.git
git push -u origin main

Now your API project is visible on GitHub. Employers and collaborators can see your code structure, tests, and documentation.

GitHub Actions (Overview Only)

GitHub provides GitHub Actions, a built-in CI/CD system. You will use CI/CD in a later chapter, so here just understand:

You do not need details here, just know that GitHub can automatically test and deploy your backend when you push code.

GitLab Overview

GitLab is both a SaaS platform like GitHub (gitlab.com) and a self-hosted product you can run on your own servers. Many companies use GitLab for its integrated toolset.

Hosted vs Self-Hosted

You can use:

Self-hosting is very common in organizations that want full control over their code and CI infrastructure, which is often important for backend systems with sensitive data.

Namespaces, Groups, and Projects

GitLab uses:

A project in GitLab is similar to a repository in GitHub.

Examples:

Groups can also contain subgroups, which can help organize a microservices backend into separate projects.

Merge Requests and Code Review

In GitLab you open Merge Requests (MRs) to merge branches.

Typical backend team workflow:

  1. Developer creates a feature branch:
    • feature/add-user-roles
  2. Developer pushes branch to GitLab.
  3. Developer opens a Merge Request:
    • Source branch: feature/add-user-roles
    • Target branch: main or develop
  4. CI pipeline runs tests.
  5. Reviewer checks code, adds comments, and approves.
  6. MR is merged.

The process is almost identical to GitHub Pull Requests, but the terminology is different.

GitLab CI/CD (Overview Only)

GitLab has built-in CI/CD configured with a .gitlab-ci.yml file in your repo.

Like GitHub Actions, GitLab CI/CD can:

You will explore CI/CD in a dedicated chapter, but for now understand that GitLab is very strong in this area and many backend teams prefer it because everything is integrated.

GitHub vs GitLab: Practical Comparison for Backend Work

From a beginner backend developer point of view, both platforms can do almost everything you need. However, each has strengths.

High-Level Comparison

Feature / AspectGitHubGitLab
Popularity (open source)Very high, default for many OSS projectsUsed by many companies, less for public OSS
Account typeUser + OrganizationsUser + Groups + Subgroups
Self-hostingGitHub Enterprise (paid, less common for hobby)Very common, free Community Edition available
Pull / Merge requestsPull RequestsMerge Requests
CI/CDGitHub ActionsGitLab CI/CD (very integrated)
Project managementProjects (classic and new), issues, milestonesBoards, epics, issues, milestones, advanced PM
Integration with external appsVery large ecosystemGood integration, especially around DevOps

When You Might Prefer GitHub

Many companies also use GitHub internally, so learning GitHub is very useful.

When You Might Prefer GitLab

As a developer, you do not need to choose one forever. You can and probably will use both during your career.

Hosting Your First Backend Project

Let us walk through an example backend project and how you would use GitHub and GitLab in practice. This example is language and framework agnostic.

Example Project: "Notes API"

You build a simple REST API that:

Structure Locally

Your local folder might look like:

text 
notes-api/
  app/
    __init__.py
    main.py
    models.py
    routes.py
  tests/
    test_notes.py
  requirements.txt
  README.md
  .gitignore

You initialize Git, commit, and everything works locally.

Publishing to GitHub

  1. Create a new repo on GitHub, notes-api.
  2. Add it as a remote and push as shown earlier.

Now on GitHub you can:

Later, you can add a basic GitHub Actions workflow such as:

yaml 
# .github/workflows/tests.yml
name: Run tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - run: pytest

Whenever you push, tests run automatically.

Publishing to GitLab

If you instead (or also) want to use GitLab:

  1. Create a project on GitLab, notes-api.
  2. Add the GitLab URL as another remote, or host there only.
bash 
git remote add gitlab git@gitlab.com:your-username/notes-api.git
git push -u gitlab main

On GitLab you might add a minimal CI file:

yaml 
# .gitlab-ci.yml
stages:
  - test
test-backend:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

Now, every push to GitLab triggers tests there.

You could even use both GitHub and GitLab remotes if needed:

bash 
git remote -v
# origin  git@github.com:your-username/notes-api.git
# gitlab  git@gitlab.com:your-username/notes-api.git

Then:

bash 
git push origin main
git push gitlab main

This is not common for production systems but can be useful if you want redundancy or use GitHub for portfolio and GitLab for CI.

Practical Tips for Beginners

Commit Messages and PR/MR Titles

Clear messages and request titles help maintain backend projects.

Examples of good commit messages:

Examples of good PR/MR titles:

These make code history and reviews easier.

Protecting Main Branch

On both GitHub and GitLab you can protect your main branch so you:

This is important for backend stability, especially once your API is deployed to production. Broken code in main can break real users.

Using Issues to Plan Backend Work

Break work into small, clear issues.

Example set of issues for a new feature:

  1. "Design database schema for tags"
  2. "Add models and migrations for tags"
  3. "Add CRUD endpoints for tags"
  4. "Add tests for tags API"
  5. "Update API documentation for tags"

Each issue can map to a branch and a PR/MR. This structure scales well as your backend grows.

Important Concepts to Remember

Key Points About GitHub and GitLab

  • Both provide remote Git repositories, collaboration, and CI/CD integration.
  • Use branches and Pull Requests / Merge Requests instead of committing directly to main.
  • Choose public repos for portfolio and open source, private repos for proprietary or sensitive code.
  • GitHub is dominant in open source and hiring visibility. GitLab is very strong for integrated DevOps and self-hosting.
  • Use issues and project features to organize backend tasks and bugs.

By understanding GitHub and GitLab early in your backend journey, you prepare yourself to work effectively in almost any modern development team.

Views: 7

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3441 / 24h
Impressum / Imprint
Datenschutz / Data Policy