Introduction to Git and GitLab

Version control makes a project's changes, states, and relationships traceable. You distinguish the working directory, staging area, and repository and examine how Git references content as snapshots. A comparison with centralised systems such as SVN clarifies which tasks happen locally and how the distributed model prepares collaboration.

A repository needs a traceable identity and deliberately selected content. The DevNinjas Dojo, our cloud learning environment, supports installing Git, configuring user.name and user.email and initialising a repository; you then edit files and practise add and commit. With a .gitignore, you exclude generated files and discuss why secrets must stay outside version history regardless of that file.

A readable history connects changes with their context. You use log with formatting options, diff, and show to compare commits and working states and mark releases with tag. With blame, you trace the origin of individual lines while distinguishing technical attribution from the underlying reason for a change.

Branches separate working states, while a merge brings selected developments together again. You create and switch branches with branch and switch, compare fast-forward with 3-way merges, and read the resulting graph. You then create a controlled merge conflict and examine which domain decision Git cannot make during its resolution.

Remotes connect local histories with repositories available to a team. You clone a GitLab project, distinguish fetch, pull, and push, and trace remote-tracking branches in the commit graph. You then compare controlled integration with a forced push and derive rules for when rewriting shared history puts collaborators at risk.

Groups organise projects and can pass memberships and roles to subordinate areas. You configure a prepared group model, register an SSH key and a scoped personal access token, and assign roles at group and project level. With separate user profiles, you examine how credentials, scope, and inheritance jointly determine available actions.

Merge requests combine a change, discussion, and approval before integration. You open a merge request, assign reviewers, comment in the diff, and compare merge commits, squash, and fast-forward. You then configure the approval rules available in the lab and distinguish a documented decision from technically enforced approval conditions.

Protection emerges only from the interaction of precise branch rules, permissions, and approvals. You configure a protected branch, assign files through CODEOWNERS, and examine when code-owner approval becomes effective. You then inspect merge trains in the prepared instance and distinguish queued validation from a guarantee that changes are conflict-free.

Issues capture work, boards visualise states, and milestones group a shared period or goal. You use labels, weights, and time estimates, arrange issues on a board, and link one to a merge request with a closing reference. You then assess which project workflows GitLab represents and when a separate planning system remains useful.

Wikis and snippets address different forms of project-related knowledge. You structure wiki pages with GitLab Flavored Markdown, tables, task lists, and Mermaid diagrams and examine the wiki as its own Git repository. With snippets, you share bounded text or code extracts and compare both tools with documentation in the main repository.

Rebase, cherry-pick, and stash address different tasks when organising or interrupting work. You integrate changes with rebase, edit commits through interactive rebase, and transfer a selected change with cherry-pick. With stash, you park a work in progress and examine whether each tool changes only local or already shared history.

Recovery starts by asking whether a change is local or already shared. You locate lost commits with reflog, compare reset in soft, mixed, and hard modes, and examine the changed states. For published commits, you use revert and explain why a new inverse commit treats shared history differently from rewriting it.

Branching models distribute integration, releases, and hotfixes differently across branches and time. You compare Git Flow, GitHub Flow, and trunk-based development using team dependencies, release cadence, and automation level. For given scenarios, you design suitable protected-branch rules and explain why no model is determined by team size or tool choice alone.

A CI/CD pipeline translates versioned configuration into automated jobs on a runner. You read a .gitlab-ci.yml, define build and test stages, and add one job with scripts to each. In the lab, you trace execution and logs and distinguish this introduction from runner operations, deployment architecture, and comprehensive pipeline security.

To shorten recurring actions and navigation, you try keyboard shortcuts, quick actions in issues and merge requests, and selected glab commands. You then compare the search options available in the prepared instance; you include exact code search only if the feature is enabled there. Finally, you assess Git aliases, shell configuration, and personal GitLab settings by use case.