Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:git [27.04.2022 17:23. ] – django
+++ linux:git [15.01.2023 19:16. ] (aktuell) – [Git Index] django
@@ Zeile 1: / Zeile 1: @@
 ====== Verteilte Versionsverwaltung für Programmcode und Dokumente mit Hilfe von Git ======
-{{:linux:git_logo.png?nolink&150 |Bild: Git Logo}}
+{{:linux:git_logo.png?nolink&150|Bild: Git Logo}}  \\
+\\
+Git ist ein freies und quelloffenes, verteiltes Versionskontrollsystem, welches Anfang 2005 von Linus Torvalds, dem Initiator und heutigen Maintainer des Linux-Kernels, entwickelt wurde. Mit Hilfe der verteilten Versionsverwaltung von lassen sich die Dateien eines Projektes einfach organisieren und an beliebiger Stelle erweitern, optimieren und deployen und so kann fast alles von kleinen bis zu sehr grossen Projekten schnell und effizient bearbeitet werden.
-Git ist ein freies und quelloffenes, verteiltes Versionskontrollsystem, welches Anfang 2005 von Linus Torvalds, dem Initiator und heutigen Maintainer des Linux-Kernels, entwickelt wurde. Mit Hilfe der verteilten Versionsverwaltung von lassen sich die Dateien eines Projektes einfach organisieren und an beliebiger Stelle erweitern, optimieren und deployen und so kann fast alles von kleinen bis zu sehr großen Projekten schnell und effizient bearbeitet werden.
+In einem verteilten System wie Git gibt es viele gleichwertige Instanzen des Repositorys, so dass jeder Entwickler über sein eigenes Repository verfügt. Der Austausch von Veränderungen ist flexibler und erfolgt nicht zwingend über einen zentralen Server. Bei einem zentralen System, wie z.B. Subversion, muss es einen zentralen Server geben, auf dem die Geschichte des Projekts gespeichert wird. Alle Entwickler müssen sich mit diesem Server verbinden, um die Versionsgeschichte einzusehen oder Änderungen vorzunehmen.
+===== Grundlagen =====
+==== Literatur ====
+Zum Einlesen was Git insbesondere leisten kann, welche Einsatzgebiete es gibt, welche Unterschiede es zu zu anderen Versionsverwaltungstools wie z.B. Subversion oder CVS bietet, eigenen sich unter anderem folgende hervorragende Bücher, die auch online zur Verfügung stehen.
+=== Pro Git von Apress ===
+[[ https://www.git-scm.com/book/de/v2/|{{:linux:progit2.png?nolink&150}}]]
+=== Das Git-Buch ===
+[[ http://gitbu.ch/|{{:linux:gitbuch_2nd.png?nolink&150|}}]]
+==== Git und seine Befehlsoptionen ====
+Einen schnellen Überblick über Git und seine Kommandos kann man mit Hilfe der Option ''%%--%%help'' zur Ansicht bringen.
+   $ git --help
+<code>usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
+           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           <command> [<args>]
+These are common Git commands used in various situations:
+start a working area (see also: git help tutorial)
+   clone             Clone a repository into a new directory
+   init              Create an empty Git repository or reinitialize an existing one
+work on the current change (see also: git help everyday)
+   add               Add file contents to the index
+   mv                Move or rename a file, a directory, or a symlink
+   restore           Restore working tree files
+   rm                Remove files from the working tree and from the index
+   sparse-checkout   Initialize and modify the sparse-checkout
+examine the history and state (see also: git help revisions)
+   bisect            Use binary search to find the commit that introduced a bug
+   diff              Show changes between commits, commit and working tree, etc
+   grep              Print lines matching a pattern
+   log               Show commit logs
+   show              Show various types of objects
+   status            Show the working tree status
+grow, mark and tweak your common history
+   branch            List, create, or delete branches
+   commit            Record changes to the repository
+   merge             Join two or more development histories together
+   rebase            Reapply commits on top of another base tip
+   reset             Reset current HEAD to the specified state
+   switch            Switch branches
+   tag               Create, list, delete or verify a tag object signed with GPG
+collaborate (see also: git help workflows)
+   fetch             Download objects and refs from another repository
+   pull              Fetch from and integrate with another repository or a local branch
+   push              Update remote refs along with associated objects
+'git help -a' and 'git help -g' list available subcommands and some
+concept guides. See 'git help <command>' or 'git help <concept>'
+to read about a specific subcommand or concept.
+See 'git help git' for an overview of the system.</code>
+Eine umfangreiche Dokumentation von Git liegt in Form vorinstallierter Manual-Pages vor, bei dem fast jedes Subkommando über eine eigene manpage verfügt. Die entsprechende Hilfeseiten erreicht man z.B. am Beispiel des Befehls **''git init''** über folgende Varianten:
+   $ man git-init
+   $ git init --help
+bzw.
+   $ git help status
+==== Vorbereitende Konfiguration ====
+Damit **Git** bei einem **''commit''** die Änderungen einem Urheber zuordnen kann, werden wir zunächst ein paar grundlegende Einstellungen vornehmen.
+   $ git config --global user.name "Michael Nausch"
+   $ git config --global user.email "django@nausch.org"
+Optional können wir, sofern ausser uns kein anderer Nutzer, Zugriff auf den Rechner hat, auch ein Passwort für spätere **''git push''** hinterlegen
+   $ git config --global user.password "0l1v3r157einec001350ck3!"
+Da wir auf unserer Linux-Admin Workstation unseren gewohnten Editor **''vim''** verwenden wollen, definieren wir diesen für **git**.
+   $ git config --global core.editor "vim"
+   $ git config --global color.ui auto
+   $ git config --list --show-origin
+<code>file:/home/django/.gitconfig    user.name=Michael Nausch
+file:/home/django/.gitconfig    user.email=django@nausch.org
+file:/home/django/.gitconfig    user.password=0l1v3r157einec001350ck3!
+file:/home/django/.gitconfig    core.editor=vim</code>
+   $ ls -alF ~/.gitconfig
+<code>-rw-rw-r-- 1 django django 139 Apr  6 17:24 /home/django/.gitconfig</code>
+   $ cat ~/.gitconfig
+<code>[user]
+	name = Michael Nausch
+	email = django@nausch.org
+	password = 0l1v3r157einec001350ck3!
+[core]
+	editor = vim
+</code>
+===== Git Beispielsprojekt - initiale Aufgaben =====
+==== Arbeitsverzeichnis / Entwicklungsumgebung anlegen ====
+Zunächst legen wir uns im Arbeitsverzeichnis ''Freifunk'' im Home-Verzeichnis unseres Users ein Verzeichnis für unser Projekt (Repository) an.
+   $ mkdir -p $HOME/Freifunk/ffmuc-offloader_rpb4
+Dieses Verzeichnis ist aktuell noch leer und ohne jedwede Inhalte.
+   $ ls -alF ~/Freifunk/ffmuc-offloader_rpb4
+<code>total 8
+drwxrwxr-x 2 django django 4096 Apr  6 17:15 ./
+drwxrwxr-x 4 django django 4096 Apr  6 17:15 ../</code>
+==== Erste Schritte mit Git ====
+Nun können wir unser Repository **''git''** bekannt machen und initialisieren.
+   $ git init ~/Freifunk/ffmuc-offloader_rpb4
+  Initialized empty Git repository in /home/django/Freifunk/ffmuc-offloader_rpb4/.git/
+Im entsprechenden Verzeichnis finden wir nun das Verzeichnis **''.git''**
+ ls -alF ~/Freifunk/ffmuc-offloader_rpb4
+<code>total 12
+drwxrwxr-x 3 django django 4096 Apr  6 17:33 ./
+drwxrwxr-x 4 django django 4096 Apr  6 17:15 ../
+drwxrwxr-x 7 django django 4096 Apr  6 17:33 .git/</code>
+   $ tree /home/django/Freifunk/ffmuc-offloader_rpb4/.git/
+<code>/home/django/Freifunk/ffmuc-offloader_rpb4/.git/
+├── branches
+├── config
+├── description
+├── HEAD
+├── hooks
+│   ├── applypatch-msg.sample
+│   ├── commit-msg.sample
+│   ├── fsmonitor-watchman.sample
+│   ├── post-update.sample
+│   ├── pre-applypatch.sample
+│   ├── pre-commit.sample
+│   ├── pre-merge-commit.sample
+│   ├── prepare-commit-msg.sample
+│   ├── pre-push.sample
+│   ├── pre-rebase.sample
+│   ├── pre-receive.sample
+│   └── update.sample
+├── info
+│   └── exclude
+├── objects
+│   ├── info
+│   └── pack
+└── refs
+    ├── heads
+    └── tags
+directories, 16 files</code>
+In diesem Verzeichnis verwaltet **git** intern unser Repository. Wir brauchen diesem in aller Regel keine besondere Beachtung schenken und vertrauen und verlassen uns da voll darauf, dass **git** hier alles nötige verwalten wird.
+Nun können wir mit der Option **''status''** den aktuellen Status unseres Verzeichnisses ansehen. Dazu wechseln wir zunächst in das zuvor angelegte Arbeitsverzeichnis.
+   $ cd ~/Freifunk/ffmuc-offloader_rpb4/
+Anschliessend fragen wir den Status ab.
+   $ git status
+<code>On branch master
+No commits yet
+nothing to commit (create/copy files and use "git add" to track)</code>
+Was genau teilt uns nun git hier mit? Nun zum einen weist ins git zum einen darauf hin, dass wir vor unserem ersten **commit** stehen **''No commits yet''** und zum anderen dass aktuell noch keinerlei Inhalte existieren **''nothing to commit''**, die git aktuell in einen commit einfliessen lassen könnte.
+<WRAP center round tip 80%>
+Git ist aber so nett und gibt uns auch gleich einen Hinweis, was wir als nächsten tun sollten um diesen Makel zu beheben: \\ \\
+//(create/copy files and use "git add" to track)// \\ \\ Wir sollen also Dateien erstellen oder kopieren und mit Hilfe des Befehls **''git add''** dann diesem Repo bzw. Git bekannt zu geben.
+</WRAP>
+==== Ansible: Directory Layout anlegen ====
+Da wir uns bei unserem Repository-Beispiel an den **[[http://docs.ansible.com/ansible/latest/playbooks_best_practices.html|Ansible's Best Practices]]** orientieren wollen, werden wir zunächst das **[[centos:ansible:first#ansibledirectory_layout|Ansible Directory Layout]]** anlegen.
+Dieses Verzeichnis-Layout werden wir nun einfach und schnell auf den Weg bringen. Hierzu verwenden wir die nachfolgend gezeigten zwei Befehle bzw. genauer gesagt die beiden Befehlsketten:
+   $ mkdir -p ~/Freifunk/ffmuc-offloader_rpb4/inventories/{production,staging}/{group_vars,host_vars} \
+              ~/Freifunk/ffmuc-offloader_rpb4/{library,module_utils,filter_plugins} \
+              ~/Freifunk/ffmuc-offloader_rpb4/roles/common/{tasks,handlers,templates,files,vars,defaults,meta,library,module_utils,lookup_plugin}
+   $ touch    ~/Freifunk/ffmuc-offloader_rpb4/inventories/{production,staging}/hosts.yml \
+              ~/Freifunk/ffmuc-offloader_rpb4/site.yml \
+              ~/Freifunk/ffmuc-offloader_rpb4/roles/common/{tasks,handlers,templates,files,vars,defaults,meta}/main.yml
+Somit haben wir nun in unserem Repository Verzeichnis die gewünschte Struktur, das **Ansible Directory Layout**:
+   $ tree ~/Freifunk/ffmuc-offloader_rpb4
+<code>/home/django/Freifunk/ffmuc-offloader_rpb4
+├── filter_plugins
+├── inventories
+│   ├── production
+│   │   ├── group_vars
+│   │   ├── hosts.yml
+│   │   └── host_vars
+│   └── staging
+│       ├── group_vars
+│       ├── hosts.yml
+│       └── host_vars
+├── library
+├── module_utils
+├── roles
+│   └── common
+│       ├── defaults
+│       │   └── main.yml
+│       ├── files
+│       │   └── main.yml
+│       ├── handlers
+│       │   └── main.yml
+│       ├── library
+│       ├── lookup_plugin
+│       ├── meta
+│       │   └── main.yml
+│       ├── module_utils
+│       ├── tasks
+│       │   └── main.yml
+│       ├── templates
+│       │   └── main.yml
+│       └── vars
+│           └── main.yml
+└── site.yml
+directories, 10 files</code>
+Rufen wir nun erneut den **''git status''** informiert uns nunmehr Git wie folgt:
+   $ git status
+<html><pre class="code">
+<font style="color: rgb(0, 0, 0)">On branch master
+No commits yet
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)</font>
+<font style="color: rgb(201, 0, 0)">	inventories/
+	roles/
+	site.yml
+</font>
+<font style="color: rgb(0, 0, 0)">nothing added to commit but untracked files present (use "git add" to track)</font>
+</pre>
+</html>
+<WRAP center round important 80%>
+Hmmm eigentlich komisch, da wir doch auch z.B. ein Verzeichnis haben wie dies hier: ''~/Freifunk/ffmuc-offloader_rpb4/filter_plugins''. Warum nur unterschlägt uns Git nun dieses Verzeichnis. Die Lösung finden wir in dem Hinweis **''Untracked files''**. Git erfasst erst einmal "nur Inhalte, genauer gesagt Dateien. Leere Verzeichnisse werden erst einmal ignoriert!
+</WRAP>
+Wir werden also, dem Vorschlag von Git die drei **rot** markierten Zeilen mit einm **''git add''** Git bekannt geben.
+   $ git add inventories/
+   $ git add roles/
+   $ git add site.yml
+Nun rufen wir erneut **''git status''** auf.
+<html><pre class="code">
+<font style="color: rgb(0, 0, 0)">On branch master
+No commits yet
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)</font>
+<font style="color: rgb(51, 145, 5)">	new file:   inventories/production/hosts.yml
+	new file:   inventories/staging/hosts.yml
+	new file:   roles/common/defaults/main.yml
+	new file:   roles/common/files/main.yml
+	new file:   roles/common/handlers/main.yml
+	new file:   roles/common/meta/main.yml
+	new file:   roles/common/tasks/main.yml
+	new file:   roles/common/templates/main.yml
+	new file:   roles/common/vars/main.yml
+	new file:   site.yml</font>
+</pre>
+</html>
+Nun ist es an der Zeit unseren ersten **Commit** um damit unsere Dateien Git zur Verwaltung anzuvertrauen; Git markiert die neu gefundenen Datei **grün** und markiert diese als ''new file:''. Dieser Commit wurde aber noch __nicht__ vollzogen, sondern erst nur vorbereitet! Git sammelt die so markierten Dateien im sog. **Index** und merkt sich intern so die Inhalte vor, die beim nächsten Commit mit einfliessen sollen.
+==== Unser erster Commit ====
+Nun ist es an der Zeit für unseren ersten initialen **''commit''**. Ein Commit manifestiert den Stand aller Dateien unseres Projekts fest definiertem Zeitpunkt und beinhalten u.a. folgende Metadaten:
+  * Name des Authors inkl. seiner eMail-Adresse,
+  * Name des Committers ebenfalls mit seiner eMail-Adresse,
+  * Erstellungsdatum, sowie das
+  * Datum des Commits.
+Wir rufen den Befehl ''git'' mit der Option ''commit''auf. Wir können Optional mit dem Parameter ''-m'' die sog. **Commit Message** mitgeben. Wir werden aber bereits bei unserem ersten Commit __nicht__ diese Option nutzen sondern den Commit nur mit ''git commit'' anstossen.
+<WRAP center round tip 80%>
+Warum machen wir das? Nun, wir gewöhnen uns am besten von vorne herein eine saubere strukturierte Arbeitsweise an. Dies hilft uns und anderen später wesentlich bei der Nachvollziehbarkeit der einzelnen Commits und deren Dokumentation!
+\\
+Am besten überlegen wir uns auch vorab, in welcher Sprache unsere Commit-Nachrichten verfasst werden sollen. Wer ist unser Publikum unser Kunde? Für private Projekte oder Projekten lokal agierender Gruppierungen bietet sind vermutlich Deutsch als grösster gemeinsamer Nenner an. Will man sein Projekt einem internationalen Publikum angedeihen lassen, wird vermutlich eher Englisch die gewählte Sprache sein. Ein Mischmasch ist sicherlich etwas was keinem so recht weiter helfen wird.
+Um Commit Nachrichten besser lesbar zu halten, haben sich folgende Rahmenbedingungen als praktikabel erwiesen:
+  - Sprache gemäss dem Zielpublikum/Einsatz wählen, entweder Deutsch oder Englisch aber kein Mischmasch
+  - Erste Zeile beinhalten eine Zusammenfassung (max. 50 Zeichen)
+  - zweite Zeile leer lassen
+  - Ab Zeile drei Beschreibung des Commits mit einer max. Zeilenlänge von 76 Zeichen
+Beim Verfassen der Commit-Beschreibung achten wir daher auf folgende Dinge:
+  - Wir erzwingen **__niemals__** leere Commit-Beschreibungen, ebenso wenig wie Kurzbeschreibungen //Bugfix, Fix, Update, Verbesserung// etc.pp.!
+  - Wir dokumentieren **//warum//** wir etwas ergänzt, gelöscht oder verändert haben und weisen auch darauf hin, welche Folgen diese Änderungen ggf. nach sich ziehen könnten/werden. **//Was//** genau verändert wurde brauchen wir __nicht__ extra zu beschreiben, da dies aus dem Diff angezeigt werden kann!
+  - Wir sind selbstkritisch und ehrlich und weisen ggf. darauf hin, wenn  wir der Meinung sind, dass ggf. noch weiterer Verbesserungs-/Optimierungs-/Korrekturbedarf besteht!
+</WRAP>
+Wir führen also nun unseren ersten commit durch und rufen den Git-Befehl ''commit'' auf.
+   $ git commit
+Da wir als Editor unseren Standard-Editor **''vim''** gewählt hatten, befinden wir uns nun im Vim-Editor uns sehen folgende Seite:
+<html><pre class="code">
+<font style="color: rgb(52, 224, 224)">
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+#
+# On branch </font><font style="color: rgb(226, 208, 164)">master</font>
+<font style="color: rgb(52, 224, 224)">#
+# Initial commit
+#
+# </font><font style="color: rgb(76, 173, 247)">Changes to be committed:</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">inventories/production/hosts.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">inventories/staging/hosts.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/defaults/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/files/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/handlers/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/meta/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/tasks/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/templates/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/vars/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">site.yml</font>
+<font style="color: rgb(52, 224, 224)">#</font>
+</pre>
+</html>
+Neben Hinweisen zur Vorlage sehen wir auch noch welche Änderungen commited werden sollen. Gemäss, unserer Vorüberlegungen zu den Commit-Nachrichten tragen wir nun in die erste Zeile eine kurze Zusammenfassung (Überschrift ein, die von einer Leerzeile gefolgt wird. Ab Zeile drei beschreiben wir dann, was genau wir geändert haben.
+<html><pre class="code">
+<font style="color: rgb(243, 210, 69)">Initialer Commit.</font>
+<font style="color: rgb(0, 0, 0)">Ansible Directory Layout angelegt.</font>
+<font style="color: rgb(52, 224, 224)">
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+#
+# On branch </font><font style="color: rgb(226, 208, 164)">master</font>
+<font style="color: rgb(52, 224, 224)">#
+# Initial commit
+#
+# </font><font style="color: rgb(76, 173, 247)">Changes to be committed:</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">inventories/production/hosts.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">inventories/staging/hosts.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/defaults/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/files/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/handlers/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/meta/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/tasks/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/templates/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">roles/common/vars/main.yml</font>
+<font style="color: rgb(52, 224, 224)">#       </font><font style="color: rgb(111, 245, 157)">new file</font><font style="color: rgb(76, 173, 247)">:</font>   <font style="color: rgb(132, 107, 148)">site.yml</font>
+<font style="color: rgb(52, 224, 224)">#</font>
+</pre>
+</html>
+Wir Verlassen nun unseren Editor **VIM** und ''git'' gibt noch eine Zusammenfassung des commits aus.
+<code>[master (root-commit) f5cd46e] Initialer Commit.
+files changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 inventories/production/hosts.yml
+ create mode 100644 inventories/staging/hosts.yml
+ create mode 100644 roles/common/defaults/main.yml
+ create mode 100644 roles/common/files/main.yml
+ create mode 100644 roles/common/handlers/main.yml
+ create mode 100644 roles/common/meta/main.yml
+ create mode 100644 roles/common/tasks/main.yml
+ create mode 100644 roles/common/templates/main.yml
+ create mode 100644 roles/common/vars/main.yml
+ create mode 100644 site.yml</code>
+Rufen wir nun den Status von Git erneut ab sehen wir, dass keine weiteren Dateien mehr anstehen, die eines commits bedürften.
+   $ git status
+  On branch master
+  nothing to commit, working tree clean
+Eine Zusammenfassung unseres gerade ausgeführten Commits können wir mit dem Befehl ''git show %%--%%shortstat'' abrufen.
+<html><pre class="code">
+<font style="color: rgb(161, 140, 4)">commit f5cd46ef0bbd7816edddefde79b2179de995e865 (</font><font style="color: rgb(21, 192, 228)">HEAD -> </font><font style="color: rgb(132, 190, 56)">master</font><font style="color: rgb(161, 140, 4)">)</font>
+<font style="color: rgb(0, 0, 0)">Author: Michael Nausch <django@nausch.org>
+Date:   Wed Apr 6 19:53:37 2022 +0200
+    Initialer Commit.
+    Ansible Directory Layout angelegt.
+files changed, 0 insertions(+), 0 deletions(-)
+</font>
+<font style="color: rgb(0, 0, 0)"></font>
+</pre>
+</html>
+Eine ausführlichere und detaillierte Aufstellung erhalten wir, wenn wir bei obigen Aufruf dir Option ''%%--%%shortstat'' weglassen.
+  $ git show
+<html><pre class="code">
+<font style="color: rgb(161, 140, 4)">commit f5cd46ef0bbd7816edddefde79b2179de995e865 (</font><font style="color: rgb(21, 192, 228)">HEAD -> </font><font style="color: rgb(132, 190, 56)">master</font><font style="color: rgb(161, 140, 4)">)</font>
+<font style="color: rgb(0, 0, 0)">Author: Michael Nausch <django@nausch.org>
+Date:   Wed Apr 6 19:53:37 2022 +0200
+    Initialer Commit.
+    Ansible Directory Layout angelegt.
+<b>diff --git a/inventories/production/hosts.yml b/inventories/production/hosts.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/inventories/staging/hosts.yml b/inventories/staging/hosts.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/defaults/main.yml b/roles/common/defaults/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/files/main.yml b/roles/common/files/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/handlers/main.yml b/roles/common/handlers/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/meta/main.yml b/roles/common/meta/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/tasks/main.yml b/roles/common/tasks/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/templates/main.yml b/roles/common/templates/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/roles/common/vars/main.yml b/roles/common/vars/main.yml
+new file mode 100644
+index 0000000..e69de29
+diff --git a/site.yml b/site.yml
+new file mode 100644
+index 0000000..e69de29</b></font>
+</pre>
+</html>
+Alternativ können wir uns beim Befehl ''show'' auch den **HEAD**, **master**, die **commit-ID** odcer Teile der **commit-ID** auswählen. Folgende Beispiele wären also gleichwertig.
+   $ git show HEAD
+   $ git show master
+   $ git show f5cd46ef0bbd7816edddefde79b2179de995e865
+   $ git show f5cd46
+==== Unser zweiter Commit ====
+Bei unserem Beispielprojekt haben wir für unser Ansible-Projekt ein Inventory definiert und angelegt.
+   $ tree inventories/production/
+<code>inventories/production/
+├── group_vars
+│   ├── gateway_keys
+│   ├── gateway_link_adresses
+│   ├── gateway_mesh_vpn_vxlan_ids
+│   ├── global_vars
+│   ├── vxlan_ids
+│   └── wireguard_ports
+├── hosts
+└── host_vars
+    └── rpb4-ol-a
+</code>
+   $ git tag -a v7.0
+<code>v7.0 - Redisign und aktualisiertes Git-Repository
+#
+# Write a message for tag:
+#   v7.0
+# Lines starting with '#' will be ignored.</code>
+   $ git log
+<code>commit 2be6d73d053d103e850af8e6507f8da8b7333bd7 (HEAD -> master, tag: v7.0)
+Author: Michael Nausch <django@nausch.org>
+Date:   Fri Apr 8 20:27:02 2022 +0200
+    Vorerst V7.0 fertig gestellt.
+    Erweiterung des playbocks um die angelegte role final. Hierfür die role
+    final angefügt, bei der letztendlich nur folgende Aufgabe erledigt wird:
+     - Reboot nach Abschluss des Baus unseres Offloaders.
+    Zu ignorierende Dateien in der Konfigurationsdatei .gitignore definiert,
+    sowie Lizenz und README-Datei für den Upload bei GitHub angefügt.
+    Da es aktuell Probleme mit der Installation und Konfiguration eines
+    OLE-Display von AZDelivery gibt, wurde die zugehörige Rolle aus früheren
+    Versionen erst einmal exkludiert. Diese Funktion wir in einem künftigen
+    neune Branch bzw. Version dann hoffentlich wieder nachgereicht - bitte
+    also noch um etwas Gelduld hierzu!
+...
+</code>
+=== Kürzere Commit-Hashes ===
+Bei einigen Git Befehlen ist die Angabe des Commit-Hashes wie z.B. ''2be6d73d053d103e850af8e6507f8da8b7333bd7 '' notwendig. Die Verwendung des vollständigen SHA1 Hash-Wertes kann mit unter als sehr umständlich betrachtet werden. Git benötigt nicht unbedingt den vollständigen Hash-wert, sondern kann auch nur mit den ersten Stellen des Hashes, sofern dieser eindeutig ist, arbeiten. Neben der individuellen manuellen Verkürzung des Hashes bietet Git auch die Möglichkeit einer Vereinfachung beim Arbeiten. Als Unterstützung bei der Handhabung für solche eindeutigen, kann ''git log'' auch wie folgt verwendet werden.
+   $ git log --abbrev-commit
+Git zeigt somit automatisch eine verkürzte siebenstellige eindeutige Länge an, die wir bei der Angabe der betreffenden Git Kommandos dann statt des vollständigen SHA1 Hashwertes verwenden können.
+=== kompremmierte verkürzte Git Logs ===
+   $ git log --oneline
+<code>2be6d73 (HEAD -> master, tag: v7.0) Vorerst V7.0 fertig gestellt.
+2239227 Neue role client-mesh angefügt.
+daf72d5 Neue role hostapd angefügt.
+fd7e5 Neue role ext-respondd angefügt.
+fd641 Neue role vxlan angefügt.
+b490b9 Neue role wireguard angefügt.
+fff5ac Neue role batman angefügt
+f780de1 Roles bereinigt und basic role angelegt.
+aadeb57 Ansible-Inventory für den Offloader angelegt.
+f5cd46e Initialer Commit.</code>
+Dieses doch schon etwas umfangreicheren Änderungen haben wir nun wie gewohnt **commited**.
+Um herauszufinden was genau nun verändert und hinzugefügt wurde sehen wir uns nun im Detail in unserem Projekt-Repository mit Hilfe von Git an.
+Zunächst einmal checken wir, wieviel Commits es bis jetzt gab. Dazu benutzen wir die Option ''%%--%%oneline'' beim Git-Befehl ''log''
+   $ git log --oneline
+<html><pre class="code">
+<font style="color: rgb(161, 140, 4)">316adae (</font><font style="color: rgb(21, 192, 228)">HEAD -> </font><font style="color: rgb(132, 190, 56)">master</font><font style="color: rgb(161, 140, 4)">)</font><font style="color: rgb(0, 0, 0)">Ansible-Inventory für den Offloader angelegt</font>
+<font style="color: rgb(161, 140, 4)">f5cd46e </font><font style="color: rgb(0, 0, 0)">Initialer Commit.</font>
+</pre>
+</html>
+Es ist also "nur" ein neuer Commit mit dedr ID **''316adae''** welche der Author mit der Überschrift ''Ansible-Inventory für den Offloader angelegt'' versehen hat.
+Die genaue Beschreibung der einzelnen Commits lassen wir uns wie gewohnt mit **'' git log''** anzeigen.
+<html><pre class="code">
+<font style="color: rgb(161, 140, 4)">commit 316adae816a876e3858ec9bc30c7eee4f6a207a9 (</font><font style="color: rgb(21, 192, 228)">HEAD -> </font><font style="color: rgb(132, 190, 56)">master</font><font style="color: rgb(161, 140, 4)">)</font>
+<font style="color: rgb(0, 0, 0)">Author: Michael Nausch <django@nausch.org>
+Date:   Wed Apr 6 21:16:22 2022 +0200
+    Ansible-Inventory für den Offloader angelegt
+    Zur Erstellung eines Offloaders im Freifunk München Netz benötigen wir
+    ein Inventory. Dieses Inventory (ini-Style) beinhaltet neben Gruppen-
+    und Host-Definitionen allgemeine Parameter (Gruppen-Variablen) aus dem
+    Freifunk-München Netz, wie auch Nodespezifische Parameter, (Host-
+    Variablen) die den Offloader selbst beschreiben.
+    Der Nodebetreiber muss die Nodespezifischen Definitionen vor dem Starten
+    des Ansible Playbooks dann noch seinen Gegebenheiten vor Ort anpassen.
+    Nähere Informationen hierzu findet man in der zum Projekt passenden
+    Seite in Djangos WIKI:
+    https://dokuwiki.nausch.org/doku.php/centos:ansible:ffmuc-rpb4-ol
+</font>
+<font style="color: rgb(161, 140, 4)">commit f5cd46ef0bbd7816edddefde79b2179de995e865</font>
+<font style="color: rgb(0, 0, 0)">Author: Michael Nausch <django@nausch.org>
+Date:   Wed Apr 6 19:53:37 2022 +0200
+    Initialer Commit.
+    Ansible Directory Layout angelegt.</font>
+</pre>
+</html>
+Nun wollen wir aber doch mal ganz genau wissen, was der Author des Projekts denn wirklich alles abgeändert hat. Dazu benutzen wir wieder den Git-Befehl ''show''.
+   $ git show
+Wir befinden uns nun in einer Art "vim -R" Ansicht, in der wir wie gewohnt mit den Pfeil- und Bild-Tasten, oder z.B. mit ''G'' zum Ende der Seite und mit ''g#'' zum Anfang der Seite springen können. Mit der Taste ''q'' verlassen wir dann die Ansicht wieder zum Schluss.g
+<html><pre class="code">
+<font style="color: rgb(161, 140, 4)">commit 316adae816a876e3858ec9bc30c7eee4f6a207a9 (</font><font style="color: rgb(21, 192, 228)">HEAD -> </font><font style="color: rgb(132, 190, 56)">master</font><font style="color: rgb(161, 140, 4)">)</font>
+<font style="color: rgb(0, 0, 0)">Author: Michael Nausch <django@nausch.org>
+Date:   Wed Apr 6 21:16:22 2022 +0200
+    Ansible-Inventory für den Offloader angelegt
+    Zur Erstellung eines Offloaders im Freifunk München Netz benötigen wir
+    ein Inventory. Dieses Inventory (ini-Style) beinhaltet neben Gruppen-
+    und Host-Definitionen allgemeine Parameter (Gruppen-Variablen) aus dem
+    Freifunk-München Netz, wie auch Nodespezifische Parameter, (Host-
+    Variablen) die den Offloader selbst beschreiben.
+    Der Nodebetreiber muss die Nodespezifischen Definitionen vor dem Starten
+    des Ansible Playbooks dann noch seinen Gegebenheiten vor Ort anpassen.
+    Nähere Informationen hierzu findet man in der zum Projekt passenden
+    Seite in Djangos WIKI:
+    https://dokuwiki.nausch.org/doku.php/centos:ansible:ffmuc-rpb4-ol
+<br>
+<b>diff --git a/inventories/production/group_vars/gateway_keys b/inventories/production/group_vars/gateway_keys
+new file mode 100644
+index 0000000..8009916
+--- /dev/null
++++ b/inventories/production/group_vars/gateway_keys</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,6 @@</font>
+<font style="color: rgb(70, 122, 32)">+# aus https://github.com/freifunkMUC/site-ffm/blob/stable/domains/ "publickey"
++gw_publickey:
++  gw04: "TszFS3oFRdhsJP3K0VOlklGMGYZy+oFCtlaghXJqW2g="
++  gw05: "igyqOmWiz4EZxPG8ZzU537MnHhaqlwfa7HarB3KmnEg="
++  gw06: "pkRaUOoLuuHnUt9BEGeKrhF3OMYBPecc0iYkika6uhE="
++  gw07: "PcKkakZcTEx3LKh+G06Opb8/esg08aWK33A5/Ff1YXE="</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/group_vars/gateway_link_adresses b/inventories/production/group_vars/gateway_link_adresses
+new file mode 100644
+index 0000000..b57913e
+--- /dev/null
++++ b/inventories/production/group_vars/gateway_link_adresses</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,6 @@</font>
+<font style="color: rgb(70, 122, 32)">+# aus https://github.com/freifunkMUC/site-ffm/blob/stable/domains/ "link_address"
++gw_linklocal:
++  gw04: "fe80::27c:16ff:fec0:6c74"
++  gw05: "fe80::281:8eff:fef0:73aa"
++  gw06: "fe80::2a2:e4ff:fef9:2269"
++  gw07: "fe80::23b:d2ff:fe95:967f"</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/group_vars/gateway_mesh_vpn_vxlan_ids b/inventories/production/group_vars/gateway_mesh_vpn_vxlan_ids
+new file mode 100644
+index 0000000..57b843f
+--- /dev/null
++++ b/inventories/production/group_vars/gateway_mesh_vpn_vxlan_ids</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,15 @@</font>
+<font style="color: rgb(70, 122, 32)">+# https://ffmuc.net/wiki/doku.php?id=knb:rpb4_wg#berechnung_der_mesh_vpn_vxlan_id
++gw_vxlan_ids:
++  muc_cty:  3836090
++  muc_nord: 1920014
++  muc_ost:  12097488
++  muc_sued: 12815947
++  muc_west: 29149
++  uml_nord: 403289
++  uml_ost:  12645856
++  uml_sued: 12090508
++  uml_west: 935867
++  gauting:  4681119
++  freising: 4669918
++  welt:     4831583
++  augsburg: 2962115</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/group_vars/global_vars b/inventories/production/group_vars/global_vars
+new file mode 100644
+index 0000000..5175e72
+--- /dev/null
++++ b/inventories/production/group_vars/global_vars</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,2 @@</font>
+<font style="color: rgb(70, 122, 32)">+ansible_ssh_user: pi
++dtparam: "i2c_arm=on"/font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/group_vars/vxlan_ids b/inventories/production/group_vars/vxlan_ids
+new file mode 100644
+index 0000000..e1db8fd
+--- /dev/null
++++ b/inventories/production/group_vars/vxlan_ids</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,15 @@</font>
+<font style="color: rgb(70, 122, 32)">+# Die vxlan id berechnet sich aus dem domain_seed: https://ffmuc.net/wiki/doku.php?id=knb:rpb4_wg#mesh_per_vxlan1
++vxlan_ids:
++  muc_cty:  10758607
++  muc_nord: 15521492
++  muc_ost:  2948862
++  muc_sued: 8599288
++  muc_west: 7318933
++  uml_nord: 5705961
++  uml_ost:  4892713
++  uml_sued: 16544703
++  uml_west: 16677749
++  gauting:  16175732
++  freising: 12937858
++  welt:     16306234
++  augsburg: 10700201</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/group_vars/wireguard_ports b/inventories/production/group_vars/wireguard_ports
+new file mode 100644
+index 0000000..874d184
+--- /dev/null
++++ b/inventories/production/group_vars/wireguard_ports</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,14 @@</font>
+<font style="color: rgb(70, 122, 32)">+wireguard_ports:
++  muc_cty:  40002
++  muc_nord: 40003
++  muc_ost:  40004
++  muc_sued: 40005
++  muc_west: 40006
++  uml_nord: 40007
++  uml_ost:  40008
++  uml_sued: 40009
++  uml_west: 40010
++  gauting:  40012
++  freising: 40013
++  welt:     40011
++  augsburg: 40014</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/host_vars/rpb4-ol-a b/inventories/production/host_vars/rpb4-ol-a
+new file mode 100644
+index 0000000..9f09905
+--- /dev/null
++++ b/inventories/production/host_vars/rpb4-ol-a</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,19 @@</font>
+<font style="color: rgb(70, 122, 32)">+# IP-Adresse unseres Raspberry in unserem eigenen lokalen Netzwerk
++# Alugehäuse ohne Lüfter und ohne Display
++# MAC: dc:a6:32:5c:46:07
++ansible_ssh_host: 192.168.0.23
++ansible_port: 22
++ansible_user: pi
++ansible_ssh_private_key_file: ~/.ssh/id_ed25519_freifunk
++#
++batman_adv_version:   "2020.4"
++ffmuc_segment:        "muc_ost"
++ffmuc_gateway:        "gw06"
++raspberry_hostname:   "ff_pliening_rpb4_ol_v6a"
++node_contact_address: "hier entlang => https://bit.ly/2VxGoXp"
++raspberry_latitude:   "48.198790640"
++raspberry_longitude:  "11.798020899"
++raspberry_wifi:       "nein"
++raspberry_clientvlan: "7"
++raspberry_meshvlan:   "8"
++raspberry_oled:       "nein"</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/hosts b/inventories/production/hosts
+new file mode 100644
+index 0000000..637a3af
+--- /dev/null
++++ b/inventories/production/hosts</b></font>
+<font style="color: rgb(0, 142, 125)">@@ -0,0 +1,7 @@</font>
+<font style="color: rgb(70, 122, 32)">+# Django : 2022-04-06
++
++# Definition einer Hostgruppe "ffmuc"
++[ffmuc]
++
++# Auflistung aller Hosts, die der vorgenannten Hostgruppe angehören.
++rpb4-ol-a</font>
+<font style="color: rgb(0, 0, 0)"><b>diff --git a/inventories/production/hosts.yml b/inventories/production/hosts.yml
+deleted file mode 100644
+index e69de29..00000
+</b></font></font></pre>
+</html>
+==== Git Index ====
+<uml>
+state "Working Directory / Tree " as workingtree
+workingtree :
+workingtree : Lokales Arbeitsverzeichnis
+workingtree : mit allen Verzeichnissen
+workingtree : und Dateien - unser lokaler
+workingtree : Arbeits- und Bearbeitungs-
+workingtree : bereich.
+workingtree :
+state "Staging - Index" as index
+index :
+index : Zwischenspeicher von Git,
+index : der zwischen dem Working tree
+index : und dem Repository steht.
+index : Auch bekannt unter dem Namen
+index : "Staging Area".
+index :
+state "Local Repository" as repo
+repo :
+repo : Speicher für alle commits,
+repo : also alle Änderungen mit
+repo : den zugehörigen commit-Daten,
+repo : also der vollständigen
+repo : Versionsgeschichte.
+repo :
+state "Remote Repository" as gitrepo
+gitrepo :
+gitrepo : remote Speicher für unser
+gitrepo : lokales Repository umd so
+gitrepo : mit anderen Personen oder
+gitrepo : auf anderen Geräten das
+gitrepo : Repository zu sharen.
+gitrepo :
+workingtree -right-> index : add
+index -left-> workingtree : reset
+index -right-> repo : commit
+repo  -right-> gitrepo : push
+gitrepo -left-> repo: fetch
+gitrepo -left-> repo: pull
+repo -left-> workingtree : reset[commit]
+gitrepo -left-> workingtree : pull
+</uml>
+Solange wir nicht mit einem **''commit''** die Daten aus Index __nicht__ in unser Repository übertragen, werden alle Änderungen die wir mit einem ''git add'' dem Index hinzufügen und mit ''reset'' wieder entziehen, lediglich im **Index** zwischengespeichert.
+Fragen wir nun den Status unser Umgebung ab.
+   $ git status
+  On branch main
+  Your branch is up to date with 'origin/main'.
+  nothing to commit, working tree clean
+Die Ausgabe **//working tree clean//** bedeutet hier nicht, dass der Index "leer" wäre, sondern dass der **''Working Tree''** und der **''Index''** synchron sind, also dass der **''Index''** im gleichen Zustand wie der **''Working Tree''** ist!
+Was passiert nun beim Aufruf von **''git diff''** wenn **''Working Tree''** und **''Index''** synchron sind?
+   $ git diff
+Ist die Ausgabe "leer" bedeutet dies, dass diese gleich sind, ein Versuch mit einem ''git commit'' fehlschlagen wird, da ja nichts im Zwischenspeicher/Index vorgemerkt siot, was in das **''Repository''** überführt werden könnte.
+   $ git commit
+  On branch main
+  Your branch is up to date with 'origin/main'.
+  nothing to commit, working tree clean
+Mit der Option ''--staged'' können wir und beim Befehl **''git diff''** den Unterschied zwischen unserem Index (Staging Area) und unserem **''Repository''** ausgeben lassen. Haben wir Änderungen im Index vorgemerkt würde dies den Unterschied zum aktuellen  ''HEAD'' sehen.
+Im Ausgangszustand, also wenn wir unsere Umgebung mit einem ''git init'' inital angelegt haben, oder nach einem durchgeführten ''git commit'' erzeugt t weder ein ''git diff'' noch ein ''git diff --staged'' eine Ausgabe.
+==== GitHub ====
+/* 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 */
+<code>Quick setup — if you’ve done this kind of thing before
+or
+Get started by creating a new file or uploading an existing file. We recommend every repository include a README, LICENSE, and .gitignore.
+…or create a new repository on the command line
+echo "# ffmuc-offloader_rpb4" >> README.md
+git init
+git add README.md
+git commit -m "first commit"
+git branch -M main
+git remote add origin https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git
+git push -u origin main
+…or push an existing repository from the command line
+git remote add origin https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git
+git branch -M main
+git push -u origin main
+…or import code from another repository
+You can initialize this repository with code from a Subversion, Mercurial, or TFS project.</code>
+https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
+/*
+<code>Stellen Sie sicher, dass die  Parameter-URL auf etwas wie:
+„https://<Ihr  Github-Benutzername>:<das soeben generierte  Token>@guthub.com/<der Pfad zum Repository, in das Sie verschieben  möchten>.git“ eingestellt ist.
+In der .git/config Datei im Git Projekt Verzeichnis:
+url = https://username_bei github:hier_token@github.com/home/Pfad_zum_Git_Projekt/z.B._website/.git  eintragen.
+(unter Linux).
+.Gehen Sie zuhttps://github.com/setting/token(wenn  Sie es vorziehen, durch das Menü zu navigieren, ist das Benutzer ->  Einstellungen -> Entwicklereinstellungen -> Persönliche  Zugriffstoken)
+. Klicken Sie auf „Neuen Token generieren“
+. Wählen  Sie die Bereiche aus.  Der benötigte Umfang heißt „repo“, also  überprüfen Sie dies unbedingt.  Wenn Sie mit dem Token etwas anderes  machen möchten, können Sie bei Bedarf auch andere Kontrollkästchen  aktivieren, aber nur damit "git push" funktioniert, würde dieser "repo"  -Bereich ausreichen.
+. Klicken Sie auf „Token generieren“
+. Öffnen Sie nun auf Ihrem Computer in dem Verzeichnis, in dem Sie den Code speichern, die Datei .git/config
+. Stellen  Sie sicher, dass die Parameter-URL auf etwas wie  siehe oben .git“ eingestellt ist.  Dh stell sicher, dass
+. Das Protokoll ist „https“, nicht „ssh“.  Die PATs funktionieren nicht mit ssh
+. Die URL enthält den Benutzernamen, unter dem Sie den Code pushen möchten
+. Die URL enthält das soeben generierte Token
+. Sobald  Sie Ihre .git/config aktualisiert haben, können Sie „git push“ erneut  ausführen und dieses Mal sollte es funktionieren (bis Github etwas Neues  implementiert, sehr sicher und nicht sehr gut erklärt).
+Quelle: andrey.mikhalchuk</code>
+*/
+   $ git remote add origin https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git
+   $ git branch -M main
+   $ git push -u origin main
+<code>Enumerating objects: 169, done.
+Counting objects: 100% (169/169), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (155/155), done.
+Writing objects: 100% (169/169), 41.24 KiB | 1.59 MiB/s, done.
+Total 169 (delta 25), reused 0 (delta 0)
+remote: Resolving deltas: 100% (25/25), done.
+To https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git
+ * [new branch]      main -> main
+Branch 'main' set up to track remote branch 'main' from 'origin'.</code>