generated from Comenius-Institut/Vorlage-OER-Communities
Compare commits
No commits in common. "bd9ddeab5989a23de64472bb81324d5657377cd2" and "ff9855be6b4e2cb012e08d68104cc1ca87f4b63f" have entirely different histories.
bd9ddeab59
...
ff9855be6b
55
Glossar.md
55
Glossar.md
|
|
@ -1,55 +0,0 @@
|
||||||
# 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).
|
|
||||||
|
|
@ -1,30 +1,3 @@
|
||||||
# Was sind Labels, was sind Tags und wie unterscheiden sie sich?
|
# Was sind Labels, was sind Tags und wie unterscheiden sie sich?
|
||||||
|
|
||||||
Hier erfährst du, was Labels und Tags sind, was der Unterschied ist und wie du sie hinzufügen und z.B. in Issues einbinden kannst.
|
Hier erfährst du, was Labels und Tags sind, was der Unterschied ist und wie du sie hinzufügen und z.B. in Issues einbinden kannst.
|
||||||
|
|
||||||
## Was sind Labels?
|
|
||||||
|
|
||||||
Labels sind in der Regel Begriffe, die in Issue-Systemen von Git verwendet werden. Sie helfen dabei, Issues und Pull-Requests zu kategorisieren und zu organisieren. Labels können z.B. zur Markierung des Status ("bug", "enhancement", "question") oder zur Priorisierung ("high priority", "low priority") verwendet werden. Labels sind nützlich für die Verwaltung und das Filtern von Tickets, um den Überblick über den Projektfortschritt zu behalten und spezifische Arten von Arbeiten zu identifizieren.
|
|
||||||
|
|
||||||
### Wie erstelle ich Labels?
|
|
||||||
|
|
||||||
Unter "Issues" findest du links in der oberen Ecke den Reiter "Labels". Wenn du dort draufklickst, werden dir vorhandene Labels angezeigt sowie die Anzahl von Issues, die ihnen jeweils zugeordnet sind und kannst rechts auf den roten Button "Label erstellen" klicken, um ein neues Label anzulegen:
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Über "Bearbeiten" können Labels nachträglich geändert werden.
|
|
||||||
|
|
||||||
## Was sind Tags?
|
|
||||||
|
|
||||||
Tags in Git sind Referenzen, die spezifische, meist wichtige Commits in der Repository-Historie markieren. Sie werden meist verwendet, um wichtige Meilensteine in der Projektentwicklung zu markieren, wie z.B. Releases (Version 1.0, Version 2.0). Tags sind somit eher als Referenzen zu verstehen, die auf bestimmte Zeitpunkte im Git-Verlauf verweisen.
|
|
||||||
|
|
||||||
### Wie erstelle ich Tags?
|
|
||||||
|
|
||||||
Tags sind verbunden mit Releases, also Veröffentlichungen. Wenn du einen Tag erstellen möchtest, muss also gleichzeitig auch ein neues Release angelegt werden, auf welches sich der Tag bezieht oder ein vorhandenes Release ausgewählt werden. Dabei kann es sich auch um ein geplantes Vorhaben, also Pre-Release im Entwurfsstatus handeln. Gleichzeitig wird der Tag verbunden mit einem Branch und den Inhalten, die damit erstellt wurden. Durch diese Markierung / Tagging wird deutlich, dass sich diese Inhalte auf das bestimmte Release beziehen. In der Regel werden Tags als Versionierungen mit v1 oder version 1 (entsprechend bei nachfolgenden Versionen weiter durchnummeriert, z.B. v2, v3, vx) bezeichnet. Sobald der Tag erstellt ist, kannst du unten auf "Tag erstellen" klicken:
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Was ist der Unterschied zwischen Labels und Tags?
|
|
||||||
|
|
||||||
Zusammengefasst sind Tags ein Werkzeug zur Markierung wichtiger Punkte in der Commit-Historie, während Labels dazu dienen, Aufgaben und Tickets innerhalb von Projekten zu kategorisieren und zu priorisieren. Beide Konzepte sind essenziell, um große und komplexe Projekte zu verwalten, spielen jedoch in unterschiedlichen Bereichen des Arbeitsprozesses eine Rolle.
|
|
||||||
|
|
||||||
|
|
|
||||||
28
gitgraph.md
28
gitgraph.md
|
|
@ -1,28 +0,0 @@
|
||||||
# Gitgraph mit Mermaid
|
|
||||||
|
|
||||||
https://mermaid.js.org/syntax/gitgraph.html
|
|
||||||
|
|
||||||
## 3 Commits auf Main
|
|
||||||
```mermaid
|
|
||||||
gitGraph
|
|
||||||
commit id: "1. Commit"
|
|
||||||
commit id: "2. Commit"
|
|
||||||
commit id: "3. Commit"
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
## Branch Entwicklung
|
|
||||||
```mermaid
|
|
||||||
gitGraph
|
|
||||||
commit id: "1. Commit"
|
|
||||||
commit id: "2. Commit"
|
|
||||||
branch Entwicklung
|
|
||||||
checkout Entwicklung
|
|
||||||
commit id: "3. Commit"
|
|
||||||
commit id: "4. Commit"
|
|
||||||
checkout main
|
|
||||||
merge Entwicklung id: "Merge Request"
|
|
||||||
commit id: "Merge Commit"
|
|
||||||
commit id: "5. Commit"
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
@ -1,19 +0,0 @@
|
||||||
# Vereinbarungen zur Zusammenarbeit mit Git
|
|
||||||
|
|
||||||
Hier werden Vereinbarungen und Absprachen für die gemeinsame offene und effektive Zusammenarbeit mit Git festgehalten.
|
|
||||||
|
|
||||||
## Netiquette
|
|
||||||
|
|
||||||
**Du-Ermutigung:** Für die offene Zusammenarbeit braucht es ein respektvolles Miteinander und flache Hierarchien. Daher möchten wir dazu einladen, euch grundsätzlich zu duzen. Teamintern können natürlich auch andere Absprachen getroffen werden.
|
|
||||||
|
|
||||||
**Fehlerkultur:** Wir verstehen uns als lernende Organisation und möchten zum freien Ausprobieren und zum eigenständigen Machen einladen ohne Angst davor, etwas falsch zu machen. Vermeintliche Fehler und Irrtümer gehören dazu und helfen uns dabei, unsere Arbeitsabläufe und -prozesse zu verbessern.An vielen Stellen gibt es kein richtig oder falsch, sondern verschiedene Wege und Lösungen. Lasst uns gemeinsam Fehler machen und beheben und schauen, welche Arbeitsweisen sich für uns als praktikabel erweisen.
|
|
||||||
|
|
||||||
**Datenschutz:** Wir befinden uns im öffentlichen Raum: vertrauliche Absprachen und Informationen, Zugangsdaten oder persönliche Daten wie Namen, Adressen, Telefonnr. etc. müssen geschützt werden und dürfen hier nicht veröffentlicht werden!
|
|
||||||
|
|
||||||
**Selbstbestimmung statt Fremdzuweisung:** Personen können sich selbst als Zuständige zuweisen und entscheiden, ob sie ein Issue bearbeiten wollen oder nicht. Alternativ können in Issues durch @-Markierungen konkrete Personen in den Kommentaren angesprochen werden, die das Issue übernehmen oder unterstützen könnten. Diese können dann selbst entscheiden, ob sie sich dem Issue annehmen. Zuständigkeiten können auch teamintern besprochen und verteilt werden, bevor sie in Issues festgelegt werden. Damit nicht eine Person alle möglichen Issues zugewiesen bekommt, ohne die Kapazitäten zu haben, sollte die betreffende Person vorher gefragt werden, ob sie das Issue übernehmen möchte. Zuständige ohne vorherige Absprache festzulegen könnte als übergriffig empfunden wird. Deshalb verständigen wir uns darauf, Issues immer zu nehmen statt zu geben.
|
|
||||||
|
|
||||||
**Nachvollziehbarkeit:** Durch Git sollen Arbeitsschritte transparent und für andere nachvollziehbar gemacht werden. Dazu ist es wichtig, dass Titel, Beschreibungen oder auch die Bezeichnungen bzw Zuordnungen von Labels etc. so präzise sind, dass auch andere, die nicht direkt involviert sind, verstehen, was gemeint ist. Insbesondere in Issues sollten Aufgaben so formuliert sein, dass deutlich wird, wer was bis wann zu tun hat.
|
|
||||||
|
|
||||||
**Feedbackkultur:** Damit Arbeitsprozesse vorankommen, Inhalte weiterentwickelt oder Fragen beantwortet werden können, braucht es euer Feedback. Bitte beachtet, dass eure Rückmeldungen gerne offen und direkt, aber immer konstruktiv sind.
|
|
||||||
|
|
||||||
**Reviewverfahren:** Mitarbeit ist erlaubt und ausdrücklich erwünscht! Dennoch hat es vermutlich niemand gerne, wenn andere einfach die Inhalte verändern. Aus Respekt möchten wir daher nahelegen, einen eigenen Branch für die Änderungen anzulegen und dann einen Pull Reuqest zu erstellen (siehe Dok zu Branch + PR -> muss noch erstellt werden). Das erscheint zwar umständlich zu sein, ist aber eine Wertschätzung gegenüber der Urheberin / des Urhebers, da sie/er dann entscheiden kann, ob die Änderungen angenommen werden sollen oder nicht und nicht vor vollendete Tatsachen gesetzt wird oder die Änderungen rückgängig machen muss.
|
|
||||||
Loading…
Reference in a new issue