Introduction to Git and GitLab

Why don't professional teams simply work with shared folders or file copies? This module clarifies the problem version control solves and why Git became the industry standard. You understand the three states (Working Directory, Staging Area, Repository) and see how Git stores changes as snapshots rather than diffs. By the end you know how Git works internally and how it differs from centralized systems like SVN.

Hands-on from the first minute: you install Git, configure user.name and user.email and create your first repository with git init. Then you go through the complete commit cycle: create files, stage with git add and save with git commit. You set up a .gitignore to exclude build artifacts and secrets, and understand why a clean .gitignore saves time from the start.

A repository without a readable history is barely better than a backup folder. You work with git log (and its formatting options), git diff and git show to compare changes between commits. With git tag you mark releases, and git blame shows you line by line who introduced which change and when. By the end you navigate the history confidently and find what you need quickly.

Branches are the tool that lets teams work on features in parallel without blocking each other. You create feature branches with git branch and git switch, work in isolation and bring changes together with git merge. You see the difference between fast-forward and 3-way merge in practice. Finally you deliberately provoke a merge conflict and resolve it step by step.

Local repositories alone are not enough once you work in a team. You connect your local repository to a GitLab remote, clone existing projects with git clone and synchronize changes with git push, git pull and git fetch. When is pull the right choice, when is fetch plus manual merge better? You see how remote tracking branches work and why git push --force is dangerous in a team.

GitLab is more than a Git server. You create projects and groups, understand the role structure from Guest to Owner and configure who can see and change what. For authentication you set up SSH Keys and Personal Access Tokens. Then you enable signed commits with SSH or GPG so GitLab marks verified commits with a green badge. In many organizations commit signing is now mandatory. Finally you see how groups inherit permissions to all contained projects, and set up a project structure that works for a team with multiple repositories.

The Merge Request is the centerpiece of collaboration in GitLab. You create an MR from your feature branch, assign reviewers and run a code review discussion directly in the diff. Then you configure Approval Rules (how many approvals are required) and compare merge options: Merge Commit, Squash and Fast-Forward Merge. You see what a clean MR workflow looks like and why it measurably improves code quality.

Who is allowed to push directly to main? Ideally nobody. You configure Protected Branches that block direct pushes and only allow merges after approval. With the CODEOWNERS file you automatically assign reviewers whenever specific files or directories are affected. For teams with high merge frequency you set up Merge Trains: GitLab automatically tests merge requests against the current state of main and merges them in order, preventing conflicts from slipping through.

GitLab can replace your ticketing system. You create Issues with labels, weight and time estimates, organize them on Boards (Kanban-style) and group them into Milestones for release cycles. Then you link issues to merge requests so the associated issue closes automatically on merge. You see how labels and boards work together and where GitLab project management reaches its limits.

Project documentation belongs where the code lives. You create a Wiki directly in your GitLab project, structure it with Markdown pages and see that the wiki itself is a Git repository you can clone and edit locally. With Snippets you store and share reusable code fragments. To close: an overview of how to use GitLab Markdown with Mermaid diagrams, task lists and tables for technical documentation.

Three tools that change your daily Git workflow. With git rebase you integrate changes from main without extra merge commits, keeping the history linear. Interactive Rebase (git rebase -i) lets you squash, reorder or rename commits before creating a merge request. git cherry-pick selectively copies individual commits to another branch (e.g. hotfixes). And git stash parks work in progress when you need to switch branches on short notice.

Something went wrong? No reason to panic. You learn git reflog, which logs every HEAD change and lets you recover lost commits or accidentally deleted branches. Then you compare git reset in its three variants (--soft, --mixed, --hard) and understand when each variant is safe. For already pushed commits you use git revert, which undoes changes without rewriting shared history. By the end you have a repertoire that takes the fear out of Git mistakes.

Which branching strategy fits your team? You compare three common models: Git Flow with release and hotfix branches for traditional release cycles, GitHub Flow as a lean alternative with a single main branch and feature branches, and Trunk-Based Development for teams with continuous deployment. For each strategy you configure the matching protected branch rules in GitLab and discuss which model plays to its strengths at which team size and release cadence.

A preview of what our GitLab CI/CD Training covers in depth. You write a simple .gitlab-ci.yml with two stages (build and test), define jobs with scripts and watch GitLab execute the pipeline live. You understand what a GitLab Runner is and how shared runners work on gitlab.com. By the end you have a working pipeline and know where the entry point to CI/CD lies.

Small tricks with big impact. You speed up your daily work with:

• keyboard shortcuts for faster navigation and Quick Actions in issues and merge requests (e.g. /assign, /label, /close)
• the GitLab CLI (glab) for tasks directly from the terminal
• current GitLab features like the Merge Request Homepage for more efficient reviews and Exact Code Search for cross-project search

To close, you create a personal checklist: which Git aliases, shell configurations and GitLab settings to implement on your first day back in the project.