Version Control with Git

Introduction

Version control helps you record, compare, share, and recover changes to project files. In software and IT workplaces, it gives a team a traceable history of what changed, who changed it, and why. Git is a distributed version control system: every normal clone contains the project files and the repository history, so much of your work can happen locally before you synchronize with a remote repository.

This aiMOOC is designed for apprentices, trainees, and vocational students who are learning software development, web development, IT administration, automation, data work, or another digital profession. You will learn Git as a practical workplace tool rather than as a collection of commands to memorize.

Fehler beim Erstellen des Vorschaubildes:

By the end of the course, you should be able to create and clone repositories, inspect changes, stage and commit selected work, use branches, combine work with merges, synchronize with remotes, contribute through a review workflow, resolve simple conflicts, and choose safer recovery actions when mistakes happen. You should also be able to explain why teams use Git and how good Git habits improve communication and quality.

Workplace example: Imagine that you are an apprentice helping maintain a small service-booking application. One trainee updates the customer form, another fixes a calculation, and a supervisor reviews both changes. Without version control, people can overwrite each other's work or lose track of which copy is current. With Git, each change can be recorded as a commit, developed on a branch, reviewed, and integrated into the shared project.

Why Version Control Matters at Work

A version control system records changes to files over time. This makes it possible to compare versions, identify when a problem appeared, return to an earlier state, and coordinate work between people. Git is useful far beyond programming source code. Teams also use it for configuration files, documentation, infrastructure definitions, scripts, test files, and other project assets.

In vocational practice, the technical history is also a communication history. A clear commit can show what task was completed and why. A branch can separate unfinished work from stable work. A pull request can create a place for feedback before a change enters the main line. These practices support teamwork, accountability, and continuous improvement.

Git is not the same thing as GitHub. Git is the version control system that runs locally and can work with many hosting services. GitHub is one platform that hosts Git repositories and adds collaboration features such as issues, pull requests, reviews, and automated checks. Other organizations may use different hosting platforms while still using Git.

Centralized and Distributed Thinking

In a centralized version control system, the main history is typically stored on a central server. Git uses a distributed model. A normal clone contains a complete local repository with project history. You can inspect history, create branches, and commit locally even when you are temporarily offline. A remote repository is then used to share and synchronize work with others.

This does not mean that workplace projects have no central meeting point. Teams often agree on one remote repository as the shared source for collaboration, review, automation, and releases. The difference is that Git's local repository remains a full working repository rather than only a thin client.

The Git Mental Model

Git becomes easier when you understand where changes are at each stage. Think of four connected places: your working directory, the staging area, your local repository, and one or more remote repositories.

Datei:Git data flow simplified.svg

The working directory contains the files you currently edit. The staging area, also called the index, is where you select the changes that should go into the next commit. The local repository stores committed snapshots and history. A remote repository is another Git repository, often on a server, that you can use to exchange commits with teammates.

A commit is best understood as a recorded project snapshot with metadata and links to its history. Git identifies commits using cryptographic object IDs. In everyday work you usually use shortened commit IDs, branch names, tags, or relative references instead of typing full object IDs.

The Basic Change Cycle

A practical local cycle is: edit files, inspect the changes, stage the intended changes, review what is staged, and commit the result. Then repeat.

git status
git diff
git add README.md
git diff --staged
git commit -m "Explain installation procedure"

git status tells you which files are untracked, modified, or staged. git diff shows unstaged changes. git add stages selected content for the next commit. git diff --staged lets you review the exact staged changes. git commit records the staged snapshot in your local repository.

Workplace habit: Stage deliberately. In a professional repository, git add . can accidentally include temporary files, generated output, or sensitive material. Selecting files or hunks gives you more control over what your commit actually says.

Datei:Git operations.svg

The diagram above shows common Git data movements. Some diagrams and older tutorials use git checkout for several different jobs. Modern Git also provides git switch for changing branches and git restore for restoring file content, which can make intent clearer for learners.

Getting Ready to Use Git

Before working on a repository, check that Git is installed.

git --version

Configure the name and email that should be attached to your commits. In a workplace, use the identity required by your organization.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

You can inspect your configuration with:

git config --list

Configuration has several scopes. Global settings apply to your user account on the computer, while repository-local settings can override them for one project. This is useful when you need different identities or settings for different organizations.

Creating a New Repository

To start version control in an existing project directory:

cd workshop-project
git init
git status

git init creates the hidden .git directory that contains the repository data. Do not casually delete or edit the contents of .git; normal Git commands are the safe interface for managing that data.

Create or edit a file, stage it, and make the first commit:

git add README.md
git commit -m "Add project overview"

A useful first README.md can describe the project purpose, setup steps, responsible team, and basic usage. Good documentation helps a future trainee understand the repository without needing to ask who created it.

Cloning an Existing Repository

If a project already exists on a remote server, you normally clone it instead of running git init inside an empty folder.

git clone https://example.org/team/workshop-project.git
cd workshop-project
git status

A clone creates a local repository and working copy and normally configures the source repository as a remote named origin.

Datei:Git session.svg

Commits as Professional Records

A good commit should represent one logical change that another person can understand. Very large commits containing unrelated fixes, formatting, generated files, and new features are harder to review and harder to reverse safely.

A useful commit message is short, specific, and action-oriented. Compare these examples:

Less useful	More useful
Update	Validate empty customer names
Stuff	Add setup instructions for test database
Fix	Correct VAT rounding in invoice total
Changes	Rename service status labels for clarity

Before committing, ask: Does this snapshot contain only the work described by the message? If not, separate the changes or stage more carefully.

Inspecting History

Use the log to inspect previous commits.

git log
git log --oneline
git log --oneline --graph --decorate --all

A readable history helps you understand how a project evolved. In a workplace investigation, you may use history to find when a behavior changed, which branch introduced a feature, or which commit should be examined in more detail.

To inspect one commit:

git show COMMIT_ID

To compare two states:

git diff older_commit newer_commit

Branches: Safe Parallel Work

A branch is a movable name that points to a commit and provides a line of development. Branches let you work on a feature, fix, experiment, or documentation change without immediately changing the main branch.

Create and switch to a new branch with:

git switch -c feature/customer-search

Make your changes and commit normally:

git status
git add search.html search.js
git commit -m "Add customer search filter"

Switch back to the main branch with:

git switch main

If your project uses a different default branch name, substitute that branch name for main. Branch names should follow your team's conventions. Names such as feature/customer-search, fix/invoice-rounding, or docs/setup-guide can make the purpose visible at a glance.

Merging Branches

When work is ready to integrate, you can merge one branch into another. In a simple local workflow, switch to the target branch first and then merge the source branch.

git switch main
git merge feature/customer-search

If Git can combine the histories automatically, the merge completes. Depending on the history, Git may move the branch pointer forward or create a merge commit.

Datei:Git branches merge.svg

After a successful merge, a local feature branch that is no longer needed can be deleted:

git branch -d feature/customer-search

Deleting the branch name does not erase commits that are already reachable from the merged main history.

Merge Conflicts

A merge conflict occurs when Git cannot decide automatically how to combine competing changes, such as when two branches changed the same lines differently. A conflict is not a system failure. It is a signal that a person must decide what the final content should be.

A safe conflict-resolution process is to inspect git status, open each conflicted file, understand both versions, edit the file to the correct final result, test the result, stage the resolved file, and complete the merge.

git status
git add resolved-file.txt
git commit

Do not remove conflict markers blindly. Read the surrounding code or text, ask the relevant teammate when intent is unclear, and run appropriate tests before completing the merge.

Working with Remotes

A remote is a named reference to another repository. List configured remotes with:

git remote -v

A common remote name is origin, but the name has no special magic. Teams can configure more than one remote when their workflow needs it.

Three commands are central to synchronization:

Command	Main purpose	Workplace question
`git fetch`	Download remote commits and update remote-tracking references without automatically integrating them into your current branch	What changed on the server?
`git pull`	Fetch remote changes and integrate them into the current branch according to configuration and command options	Can I update my current branch from its upstream?
`git push`	Send local commits and reference updates to a remote	Can I share my committed work?

A careful trainee should know that pull does more than download. When you want to inspect remote changes before integration, git fetch gives you that separation.

First Push of a New Branch

After committing work on a new local branch, you can publish it to a remote:

git push -u origin feature/customer-search

The -u option sets the upstream relationship, so later git push and git pull commands can often work without repeating the remote and branch names.

Pull Requests and Code Review

On platforms such as GitHub, a pull request proposes that changes from one branch or fork be reviewed and merged into another branch. It gives collaborators a place to discuss the change, inspect the diff, run automated checks, request improvements, and approve the final result.

A common team workflow is: create a branch, make small commits, push the branch, open a pull request, respond to review, let automated checks run, and merge only when the team criteria are satisfied.

Datei:Basic git branching workflow (GitLab).svg

Different organizations use different repository hosts and review rules. The underlying professional skills transfer: isolate work, record understandable changes, ask for review, react constructively to feedback, and integrate only when quality checks are satisfied.

Review as a Learning Tool

If you are an apprentice, code review is not only a gate. It is a structured way to learn workplace standards. A reviewer may ask you to rename a variable, add a test, explain a decision, split a large change, or improve documentation. Treat the discussion as part of the technical work.

When reviewing someone else's change, focus on the work rather than the person. Ask specific questions, explain risks, and suggest testable improvements. A professional review comment should help the author make a better change.

Ignoring Files and Protecting Secrets

Not every file in a project should be tracked. A .gitignore file describes intentionally untracked files and directories that Git should ignore. Typical examples include generated build output, local editor files, dependency caches, and local environment files that should not be committed.

Example:

build/
*.log
.env

A .gitignore rule does not remove a file that Git already tracks. If a sensitive value such as a password, token, or private key has been committed, adding that file to .gitignore is not enough.

Never commit secrets. Use your organization's approved secret-management method. If a real credential is accidentally committed, immediately follow your workplace incident process and revoke or rotate the credential. Cleaning repository history may also be necessary, but changing history can affect every collaborator and should be coordinated carefully.

Before each commit, inspect the staged diff:

git diff --staged

This simple habit can catch accidental secrets, debug output, unrelated files, and unfinished edits before they enter history.

Undoing and Recovering Safely

Git offers several ways to correct mistakes, but they have different effects. Choose based on whether the change is uncommitted, committed locally, or already shared.

Situation	Safer starting point	Why
You edited a tracked file but want to discard the uncommitted edit	`git restore FILE`	Restores working-tree content from the index by default
You staged a file by mistake	`git restore --staged FILE`	Removes it from the staging area while keeping the working-tree edit
You need to undo a bad commit that is already shared	`git revert COMMIT_ID`	Creates a new commit that reverses the selected commit instead of rewriting shared history
You need to inspect recent reference movements after a local mistake	`git reflog`	Often helps you find commits that are no longer visible from a branch name

Commands that rewrite or discard history, especially git reset --hard, can destroy uncommitted work or move branch references in ways that confuse collaborators. Do not copy a destructive command from a forum without understanding what it will change.

Rebasing is another useful but more advanced operation. It replays commits onto a new base and can create a cleaner linear history, but it rewrites commit identities. Follow your team's policy and avoid rebasing commits that other people already depend on unless the team has explicitly coordinated it.

A Vocational Git Workflow

The following workflow fits many training projects and small workplace tasks.

Stage	What you do	Evidence you can show
Understand the task	Read the ticket or requirement and clarify the expected result	A clear goal and acceptance criteria
Update your base	Synchronize your local view of the shared project	`git status` and current branch
Create a branch	Isolate the task from the main line	A meaningful branch name
Work in small steps	Edit, test, inspect diffs, stage selected changes, and commit	Focused commits and passing tests
Share the branch	Push to the team remote	A remote branch
Request review	Open a pull request and explain what changed	Reviewable diff and description
Improve	Respond to comments and update the branch	Additional commits or revised code
Integrate	Merge after required reviews and checks pass	Updated main branch

Datei:GitWorkflow.svg

Workplace Scenario: Repair Ticket Tracker

You are assigned a ticket: Prevent blank customer names in the repair intake form. A sensible workflow could be:

git switch main
git pull
git switch -c fix/blank-customer-name

You modify the validation and add or update a test. Then you inspect your work:

git status
git diff

Stage only the intended files and review the staged diff:

git add src/customer-form.js tests/customer-form.test.js
git diff --staged

Commit with a message that states the purpose:

git commit -m "Reject blank customer names"

Publish the branch:

git push -u origin fix/blank-customer-name

Then open a pull request, explain how you tested the change, respond to review comments, and merge only when your team's checks are satisfied.

Common Beginner Problems

Symptom	Likely cause	First action
Git says there is nothing to commit	Your changes may not be saved, may be ignored, or may already be committed	Run `git status` and inspect the file
A file does not appear in status	A `.gitignore` rule may match it	Check ignore rules before changing anything
Push is rejected	The remote branch may contain work you do not have, or permissions may block the push	Read the full message and fetch remote changes
You are on the wrong branch	You switched branches earlier or opened the wrong repository	Run `git status` and `git branch`
A merge stops with conflicts	Git needs a human decision for overlapping changes	Run `git status` and resolve each conflicted file carefully
A secret was committed	Sensitive data entered repository history	Revoke or rotate the credential and follow the organization's security process

Professional rule: read Git's message before trying another command. Git often tells you what state the repository is in. Repeatedly running commands without understanding the state can make a small problem harder to diagnose.

Efficient Team Habits

Good Git practice is partly technical and partly organizational. Agree on branch naming, commit-message expectations, review rules, merge strategy, release tags, and who can update protected branches. Keep branches short-lived when possible so they do not drift far from the shared main line.

Integrate often enough to detect conflicts early. Write commits small enough to review. Link technical work to a ticket or requirement when your workplace uses one. Keep generated files and local settings out of history when appropriate. Never treat the repository as a place for passwords or access tokens.

Before you push, ask yourself three questions: Is my branch correct? Is my staged and committed content intentional? Have I tested the change at the level expected for this task?

Reliable Resources

The course is based on standard Git concepts and current official documentation. Use these resources when you need exact command behavior or deeper explanations.

Pro Git online book: Officially hosted, detailed explanations of Git basics, branching, remotes, distributed workflows, and tools.
Git reference documentation: Command-level documentation for your installed Git version.
GitHub Docs: About Git: Overview of version control, repositories, common commands, and collaboration.
GitHub Docs: Pull requests: Guidance for proposing, reviewing, and merging changes.
GitHub Docs: Ignoring files: Practical guidance for .gitignore.
GitHub Docs: Removing sensitive data: Security guidance for accidental credential or secret exposure.

Interactive Tasks

Quiz: Test Your Knowledge

What does a version control system primarily record? (Changes to files over time) (!Only passwords for a project) (!Only software installation dates) (!The screen brightness of a computer)

What is the purpose of the Git staging area? (To select changes for the next commit) (!To publish a website automatically) (!To delete all repository history) (!To replace the remote repository)

Which command records staged changes as a new local snapshot? (git commit) (!git status) (!git fetch) (!git branch)

Why do teams create branches? (To isolate lines of work) (!To remove the need for testing) (!To store passwords safely) (!To replace all commit messages)

What does git fetch do? (Downloads remote changes without automatically integrating them) (!Deletes the local repository) (!Creates a pull request) (!Rewrites every commit message)

What is a pull request used for in a team workflow? (To propose and review changes before integration) (!To install Git on a workstation) (!To hide all project history) (!To convert source code into passwords)

What should you do before committing staged work? (Review the staged diff) (!Delete the repository history) (!Share secret keys with teammates) (!Rename every file in the project)

What is usually a good way to undo a bad commit that is already shared? (Create a new reverting commit) (!Delete the remote server) (!Erase every local file) (!Rename the main branch randomly)

What does a merge conflict mean? (Git needs a human decision to combine competing changes) (!Git has permanently lost the repository) (!The computer cannot run any programs) (!Every branch has been deleted)

What should happen first if a real access token is accidentally committed? (Revoke or rotate the exposed credential) (!Add more copies of the token) (!Send the token to the whole team) (!Ignore the problem because the repository is private)

Memory Game

Repository	Project files together with their version history
Commit	Recorded snapshot of selected project changes
Branch	Named line of development that points through history
Staging area	Selection area for the next recorded snapshot
Remote	Another repository used for sharing and synchronization
Merge	Integration of histories from different lines of development
Clone	Local copy created from an existing repository
Pull request	Reviewable proposal to integrate one line of work into another

Drag and Drop

Match the correct terms.	Topic
Inspect repository state	Given item: git status
Stage a selected file	Given item: git add
Record staged work	Given item: git commit
Download remote updates	Given item: git fetch
Share local commits	Given item: git push

...

Crossword Puzzle

Repository	What stores a Git project's files and history?
Commit	What records a selected project snapshot?
Branch	What named line lets you develop work separately?
Merge	What operation combines lines of development?
Remote	What do you call another repository used for synchronization?
Staging	What area lets you select changes before a commit?

LearningApps

Cloze Text

Open-Ended Tasks

Easy

Git Status Diary: Create a small practice repository, make three different file changes, and write a short diary explaining what git status shows before staging, after staging, and after committing.
Commit Message Workshop: Write six commit messages for realistic workplace changes, then improve each message so that another trainee can understand the purpose without opening the files.
Repository Map: Produce a labeled image that explains the working directory, staging area, local repository, and remote repository, and add one example Git command to each connection.
Git Vocabulary Video: Record a two-minute video in which you explain repository, commit, branch, merge, and remote in your own words using one workplace example.

Standard

Branch Practice Project: Build a small text or code project with a main branch and two feature branches, make meaningful commits on each branch, merge them, and present the final history graph.
Peer Git Interview: Interview a classmate, trainer, developer, or system administrator about how their team uses Git, then summarize three workflow rules and explain why each rule exists.
Conflict Resolution Lab: Create a controlled merge conflict with a partner by editing the same lines on two branches, resolve it correctly, test the result, and document the decisions you made.
Pull Request Simulation: In a training repository, create a branch, push it, open a pull request, request peer review, respond to at least two review comments, and record what changed because of the review.

Advanced

Git Incident Analysis: Design a scenario in which a trainee commits a secret or uses a destructive command, then produce an incident response guide that separates immediate security actions, repository recovery, and team communication.
Workflow Comparison Study: Compare a short-lived feature-branch workflow with a trunk-based approach for a small vocational software team and write a justified recommendation based on review speed, conflict risk, testing, and training needs.
History Recovery Experiment: In a disposable repository, create several commits, move a branch reference in a controlled way, use git reflog to locate previous states, and produce a screen-recorded explanation of what you recovered and why.
Workplace Git Audit: Visit or observe a training lab, school IT project, apprenticeship team, or comparable development environment, map its Git workflow from task to merge, and propose three evidence-based improvements with attention to security and review quality.

Learning Assessment

Workflow Reasoning: Given a project with three trainees editing related files, design a Git workflow that minimizes accidental overwrites and explain when each person should branch, fetch, review, and merge.
Conflict Diagnosis: Analyze a supplied merge conflict, explain why Git could not resolve it automatically, produce the correct final file, and justify how you verified that neither contributor's intended behavior was lost.
Recovery Decision: Compare git restore, git revert, and a destructive history-rewriting command for three mistake scenarios and justify which action creates the lowest risk for shared work.
Security Transfer: Evaluate a repository that contains a tracked .env file and an exposed token, identify why .gitignore alone is insufficient, and propose a response that addresses both credential security and repository history.
Professional History Review: Review an unfamiliar commit history and pull request, identify evidence of good or weak collaboration practice, and recommend improvements to commit scope, messages, testing evidence, and review communication.
New Workplace Transfer: Imagine that your next employer uses Git with a different hosting platform and branching policy; explain which skills from this course transfer directly and which practices you would need to learn from the new team's rules.

Evidence of Learning

Important evidence should show not only that you remember commands, but that you can use Git responsibly in realistic work.

Evidence area	What successful learning looks like
Knowledge	You can explain repositories, working directories, staging, commits, branches, remotes, merging, pull requests, and the difference between Git and a hosting platform.
Practical skills	You can initialize or clone a repository, inspect changes, stage selectively, commit, branch, merge, synchronize with a remote, and resolve a simple conflict.
Quality habits	You review diffs, write focused commit messages, test before integration, follow branch and review conventions, and avoid committing secrets.
Products	Your evidence includes a working practice repository, readable history, branch graph, documented conflict resolution, review discussion, and a short workflow explanation.
Reasoning	You can choose between fetch, pull, merge, revert, restore, and other actions based on the repository state and the risk to collaborators.
Transfer	You can adapt the Git mental model and collaboration skills to a new employer, repository host, project type, or team workflow without assuming that every organization uses identical rules.

OERs on the Topic

The English Wikipedia article below provides an additional overview of Git, its history, design, and use. Compare its general explanation with the practical workplace focus of this course.

Linked Learning Areas

Version Control with Git

Git connects technical and professional learning. In Software development, it supports controlled change and teamwork. In Web development, it helps manage code, content, and deployment workflows. In Information technology, it supports configuration and automation work. In Cybersecurity, it reinforces careful handling of credentials and auditable change. In Project management, commits, branches, issues, and reviews can connect implementation work to planned tasks and acceptance criteria.

aiMOOC Projects

Diesen aiMOOC als Battle spielen: Englisch, Klasse 5-6, G-Niveau

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...

Frag mich zum aktuellen Lerninhalt oder wähle eine kurze Hilfe.

Textmodus bereit

Sprache