Skip to content

12. GitLab Introduction

git-local-remote

You will be provided with a repository for your team on the department’s GitLab instance -- not gitlab.com! You’ll receive the link via email sent to your student address.

Git is a version control system used to track changes in your code and collaborate with others. It lets you save snapshots of your project, go back to earlier versions, and work on different features without overwriting each other’s work.

  • Locally on your computer: You write code, track changes, and commit them locally -- not yet visible to your team mates.
  • On the server (code.fbi.h-da.de): You push your changes to the shared remote repository, so your team can access and collaborate on the latest version.

Install git bash, as you might need it for some cases. In general, I recommend github desktop.

file names like variable names

Use only a-zA-Z0-9-_ for paths and file names. Do not use whitespace, german chars or any other special chars -- see folder structure.

12.1 Getting Started with Your Repository

git cicle

The basic Git workflow starts with cloning the remote repository to your local machine (only once). Each time you begin working, you pull the latest changes from the remote repository to stay up to date. You then work locally, editing files and making changes on your computer. Once you are satisfied, you commit these changes with a clear message describing what you did. Finally, you push your commits to the remote repository so your team can access them. This cycle—pull, work, commit, push—is repeated regularly, always pulling first to avoid conflicts.

:video-camera: The video explains how to user github desktop for the following.

12.1.1 Cloning a Repository

To start working with a GitLab project, first clone it to your local machine: 

git clone https://gitlab.com/username/project-name.git
cd project-name
Here's that warning in English for a Git introduction:

clone to non-sync folder

Do not clone repositories into directories that are synchronized with cloud services like Google Drive, Dropbox, OneDrive, or similar.

Cloud sync services can interfere with Git's file management in several ways

  • They may lock files while syncing, preventing Git operations
  • Constant syncing can cause conflicts with Git's internal files
  • Performance issues due to the cloud service trying to sync Git's frequent file changes
  • Potential corruption of the Git repository structure

Instead, clone your repositories to a local directory (like /repos/h-da or C:\dev) and use Git's own remote repository features for backup and collaboration.

12.1.2 Staying Up-to-Date

Before starting work, always pull the latest changes from the remote repository: 

git pull origin main

12.1.3 Making Changes and Commits

commit

A good commit message should be

  • Clear and concise: Describe what the commit does.
  • Use imperative mood: "Add login function" instead of "Added login function"
  • Be specific: "Fix validation bug in email field" instead of "Fix bug"
  • Mention the issue number in your commit message — this automatically adds a comment to the referenced issue.
  • follow the structure of conventional commits
    • Summary
      • Type: feat, fix, docs, style, refactor, learn, orga
      • Scope: section of codebase, e.g. login
    • Description
      • #IssueNumber
      • Additional comments relevant for your team

Examples of good commit messages

  • feat: Add user authentication system with description #12
  • fix: Navbar alignment on mobile devices with description #13
  • refactor: Remove deprecated API endpoints with description #14

commit related changes

Group related changes into logical commits.

commit frequently

Make small, logical commits as you complete each part of your work. Always commit before breaks.

12.1.4 Git Commands

git status
Shows which files are modified, staged, or untracked.

git diff                   # See unstaged changes
git diff --staged          # See staged changes
git diff HEAD~1            # Compare with previous commit

git log                    # Full commit history
git log --oneline          # Condensed one-line format
git log -5                 # Show last 5 commits

git reset HEAD filename.txt    # Unstage a specific file
git reset HEAD                 # Unstage all files

git checkout -- filename.txt  # Discard changes to specific file
git checkout -- .             # Discard all unstaged changes

git reset --soft HEAD~1       # Undo commit, keep changes staged
git reset HEAD~1              # Undo commit, keep changes unstaged

12.1.5 Best Practices

  • Always pull before pushing to avoid conflicts
  • Commit working code, not broken or incomplete features
  • Use descriptive commit messages that explain the "why" not just the "what"
  • Push your commits regularly to back up your work
  • Review your changes with git diff before committing

This workflow will help you maintain a clean, understandable project history and collaborate effectively with your team.

12.2 Project Management with gitlab

Read git and markdown.