git/Glossar.md

# Glossar

Hier werden die wichtigsten Schlüsselbegriffe in Git kurz erläutert. 

**Branch**:

In Git ist ein Branch (Zweig) ein separater Entwicklungsstrang innerhalb eines [Git-Repositorys](#Repository (Repo)). Er ermöglicht es, parallel an unterschiedlichen Funktionen, Fehlerbehebungen oder anderen Änderungen zu arbeiten, ohne den Hauptentwicklungszweig (main) zu beeinträchtigen. Branches isolieren Änderungen, sodass diese unabhängig vom Hauptentwicklungszweig oder anderen Branches vorgenommen und getestet werden können. Das ist besonders nützlich für die Entwicklung neuer Features oder das Experimentieren mit neuen Ideen. Ein neuer [Branch](#Branch) kann erstellt werden, um an einer bestimmten Aufgabe zu arbeiten. Nach Abschluss der Arbeit kann dieser Branch wieder in den Hauptzweig (oft "main" oder "master" genannt) oder in einen anderen Branch zusammengeführt (gemergt) werden. Branches ermöglichen es mehreren Personen, gleichzeitig an verschiedenen Funktionen oder Fehlerbehebungen zu arbeiten, ohne sich gegenseitig zu stören. Änderungen in einem Branch können vor dem Mergen überprüft und getestet werden, was die Qualität des Codes verbessert und das Risiko von Fehlern reduziert. Branches erleichtern es, auf frühere Versionen des Codes zurückzugreifen oder alternative Entwicklungen zu verfolgen. Die [Commits](#Commits) in Git bauen aufeinander auf und bilden dabei eine verkettete "Liste". Diese "Liste" nennt man auch Branch (Entwicklungszweig).

**Commit**:

Ein Commit in Git ist eine Änderung, die in einem [Repository](#Repository) vorgenommen wurde. Es repräsentiert einen bestimmten Zustand des Codes zu einem bestimmten Zeitpunkt und ermöglicht es, den Fortschritt der Arbeit zu dokumentieren und nachzuverfolgen. Änderungen können zurückverfolgt und untersucht werden, was bei der Fehlersuche und beim Verständnis der Entwicklungshistorie hilft. In einem Team können mehrere Personen parallel arbeiten und ihre Änderungen zusammenführen. Man kann zu jedem vorherigen Zustand des Projekts zurückkehren, um Änderungen zu überprüfen oder alte Versionen wiederherzustellen.

**Fork**:

In Git ist ein Fork eine persönliche Kopie eines [Repositorys](#Repository-(Repo)), einschließlich seiner gesamten Historie und Branches. Ein Fork ermöglicht es Benutzer:innen, ein Projekt zu kopieren und eigenständige Änderungen daran vorzunehmen, ohne die ursprüngliche Version zu beeinflussen. Forks werden häufig verwendet, um an Open-Source-Projekten mitzuarbeiten. Benutzer:innen können in ihrem Fork unabhängig Änderungen vornehmen, neue Features entwickeln oder Bugs beheben. Änderungen, die in einem Fork vorgenommen werden, können durch [Pull Requests](#Pull-Request) dem ursprünglichen [Repository](#Repository) vorgeschlagen werden. Wenn die Änderungen akzeptiert werden, können sie in das Quell-Repository integriert werden. Forks ermöglichen es, zu Open-Source-Projekten beizutragen, ohne direkten Zugriff auf das Quell-Repository zu benötigen. Entwickler:innen können neue Ideen ausprobieren oder experimentelle Features entwickeln, ohne das Hauptprojekt zu beeinträchtigen. Forks erleichtern die parallele Entwicklung und Zusammenarbeit in Teams, insbesondere bei großen Projekten.

**Issue**:

Ein Issue in Git ist ein Instrument zur Nachverfolgung von Aufgaben, Fehlern, Verbesserungen oder Diskussionen. Issues sind besonders hilfreich für die Organisation und Verwaltung von Projekten, insbesondere in großen Teams oder Open-Source-Communities. Sie bieten eine strukturierte Möglichkeit, Probleme zu dokumentieren, zu diskutieren und ihre Lösung zu verfolgen. Ein Issue enthält eine detaillierte Beschreibung des Problems oder der Aufgabe. Dies kann Text, Screenshots, Code-Snippets oder Links zu relevanten Ressourcen umfassen. Der Titel des Issues sollte kurz und prägnant sein, um den Kern des Problems oder der Aufgabe sofort ersichtlich zu machen. Mehr dazu erfährst du [hier](https://git.rpi-virtuell.de/Comenius-Institut/git/src/branch/main/einf%C3%BChrung-issues.md).

**Label**: 

Ein Label in Git wird zur Organisation und Kategorisierung von [Issues](#Issues) und [Pull Requests](#Pull-Request) verwendet. Es ermöglicht Aufgaben, Fehler oder Feature-Anfragen schnell zu identifizieren und zu priorisieren. [Labels] können farbcodiert und mit benutzerdefinierten Bezeichnungen versehen werden, um verschiedene Aspekte eines Projekts darzustellen. Sie bieten eine flexible und visuelle Methode zur Organisation und Priorisierung von Aufgaben und unterstützen die effektive Zusammenarbeit im Team. Mehr dazu erfährst du [hier](https://git.rpi-virtuell.de/Comenius-Institut/git/src/branch/main/Lables-und-Tags.md).

**Mergen**:

In Git bedeutet "Mergen" das Zusammenführen von Änderungen aus verschiedenen Branches in einen gemeinsamen Branch. Dabei werden mehrere Code-Teile oder Unterprojekte zu einem Ganzen zusammengefügt. Änderungen sollten nur dann gemergt werden, wenn sie tatsächlich abgeschlossen sind, um nachträglichen Überarbeitungsaufwand zu vermeiden und eine saubere und konsistente Versionshistorie zu gewährleisten. Bei Unsicherheiten empfiehlt es sich daher, einen [Pull Request](#Pull-Request) als Reviewprozess einzuführen und sich dadurch Feedback von anderen einzuholen. 

**Pull Request**:

Ein Pull Request (PR) ist ein Antrag, um Änderungen, die in einem separaten Branch eines Repositories vorgenommen wurden, in einen anderen [Branch](#Branch) (meistens den Hauptbranch, wie main oder master) zu integrieren. Der PR ermöglicht es, die vorgeschlagenen Änderungen zu überprüfen, Feedback zu geben und die Änderungen vor der Integration zu diskutieren. Dazu wird zunächst ein neuer Branch, um an einer neuen Funktion, einem Bugfix oder einer Verbesserung zu arbeiten. Die notwendigen Änderungen werden im neuen Branch vorgenommen und anschließend committet. Nach Abschluss der Änderungen öffnet der Entwickler einen Pull Request. Der PR enthält eine Beschreibung der vorgenommenen Änderungen und den Zweck dieser Änderungen. Andere Teammitglieder oder Reviewer prüfen den Pull Request, geben Feedback, diskutieren die Änderungen und können zusätzliche [Commits](#Commit) vorschlagen. Kommentare und Diskussionen erfolgen direkt im Pull Request. Nach der Genehmigung durch die Reviewer wird der Pull Request gemergt und die Änderungen in den Zielbranch integriert. PRs dienen somit als Dokumentation für der vorgenommenen Änderungen und soll die Zusammenarbeit fördern. Jede Änderung ist nachvollziehbar und kann überprüft werden.

**Pull**:

In Git wird der Befehl "pull" verwendet, um Änderungen von einem entfernten [Repository](#Repository) (also auf Plattformen wie Github, GitLab, Forgejo) in das lokale Repository zu holen und diese Änderungen in den aktuellen [Branch](#Branch) zu integrieren. Dadurch wird sichergestellt, dass man immer mit der neuesten Version des Codes arbeitet. Das ist aber eher für Entwickler:innen relevant. 

**Push**:

In Git bedeutet "push" das Hochladen von lokalen Änderungen, die du in deinem lokalen [Repository](#Repository) vorgenommen hast, auf ein entferntes Repository (also auf Plattformen wie Github, GitLab, Forgejo). Dieser Befehl dient dazu, um lokale Änderungen mit anderen zu teilen oder als Backup zu sichern. Das ist aber eher für Entwickler:innen relevant. 

**Release**:

In Git bedeutet ein "Release" eine spezifische Version des Codes, die als stabil und bereit für den Einsatz markiert wurde. Releases werden oft in Verbindung mit der Versionsverwaltung verwendet. Ein Release beginnt normalerweise mit dem Setzen eines Tags auf einen bestimmten [Commit](#commit) im [Repository](#Repository). Ein Release stellt einen bestimmten Stand des Projekts dar, der als stabil betrachtet wird und oft zum Bereitstellen oder Deployen verwendet wird. Entwickler und Benutzer können diesen spezifischen Stand leicht identifizieren und darauf zugreifen, um sicherzustellen, dass sie eine getestete und freigegebene Version verwenden. Es hilft dabei, wichtige Meilensteine und stabile Versionen des Projekts zu kennzeichnen und zu verteilen.

**Repository (Repo)**:

Ein Repository (Deutsch: Repositorium, kurz: Repo) ist ein Aufbewahrungsort, an dem Code und dazugehörige Dateien einschließlich ihres Revisionsverlaufs gespeichert werden können (quasi wie ein Archiv). Repositorys können mehrere Projektmitarbeitende haben und können entweder öffentlich für alle sichtbar oder privat, also nur für einen beschränkten Nutzerkreis sichtbar sein.

**Revision**:

In Git bezieht sich eine Revision (oder Revision ID) auf einen bestimmten Zustand des [Repositories](#Repository) zu einem bestimmten Zeitpunkt. Jede Revision ist durch einen [Commit](#Commit) identifiziert. Revisionen sind essenziell für das Nachverfolgen von Änderungen, das Verwalten von Versionen und das Navigieren durch die Historie eines Projekts.

**Tag**:

Ein Tag in Git ist ein benannter Referenzpunkt in der Historie eines [Repositories](#Repository). Tags werden verwendet, um spezielle [Commits](#Commit) zu markieren, wie beispielsweise Versionen von [Releases](#Release). Tags sind hilfreich, um spezifische Punkte in der Entwicklungsgeschichte leicht wiederzufinden und darauf zuzugreifen. Mehr dazu erfährst du [hier](https://git.rpi-virtuell.de/Comenius-Institut/git/src/branch/main/Lables-und-Tags.md).