Skip to content

Commit 45c2834

Browse files
veitveit
committed
📝 Add Git’s data model
1 parent 964c16d commit 45c2834

File tree

2 files changed

+277
-34
lines changed

2 files changed

+277
-34
lines changed

‎docs/productive/git/advanced/internals.rst‎

Lines changed: 46 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -2,21 +2,51 @@
22
..
33
.. SPDX-License-Identifier: BSD-3-Clause
44
5-
Git's Datenbank-Interna
6-
-----------------------
5+
Datenmodell
6+
===========
7+
8+
Ihr werdet Git besser nutzen können, wenn ihr das Datenmodell verstanden habt.
79

810
.. seealso::
9-
* `Commits are snapshots, not diffs
10-
<https://github.blog/open-source/git/commits-are-snapshots-not-diffs/>`_
11-
* Git’s database internals
12-
13-
* `Part I: packed object store
14-
<https://github.blog/open-source/git/gits-database-internals-i-packed-object-store/>`_
15-
* `Part II: commit history queries
16-
<https://github.blog/open-source/git/gits-database-internals-ii-commit-history-queries/>`_
17-
* `Part III: file history queries
18-
<https://github.blog/open-source/git/gits-database-internals-iii-file-history-queries/>`_
19-
* `Part IV: distributed synchronization
20-
<https://github.blog/open-source/git/gits-database-internals-iv-distributed-synchronization/>`_
21-
* `Part V: scalability
22-
<https://github.blog/open-source/git/gits-database-internals-v-scalability/>`_
11+
Git’s database internals
12+
13+
* `Part I: packed object store
14+
<https://github.blog/open-source/git/gits-database-internals-i-packed-object-store/>`_
15+
* `Part II: commit history queries
16+
<https://github.blog/open-source/git/gits-database-internals-ii-commit-history-queries/>`_
17+
* `Part III: file history queries
18+
<https://github.blog/open-source/git/gits-database-internals-iii-file-history-queries/>`_
19+
* `Part IV: distributed synchronization
20+
<https://github.blog/open-source/git/gits-database-internals-iv-distributed-synchronization/>`_
21+
* `Part V: scalability
22+
<https://github.blog/open-source/git/gits-database-internals-v-scalability/>`_
23+
24+
Git verwaltet vier Arten von Daten:
25+
26+
Objekte
27+
-------
28+
29+
.. include:: ../glossary.rst
30+
:start-after: start-object
31+
:end-before: end-object
32+
33+
Referenzen
34+
----------
35+
36+
.. include:: ../glossary.rst
37+
:start-after: start-refs
38+
:end-before: end-refs
39+
40+
Index
41+
-----
42+
43+
.. include:: ../glossary.rst
44+
:start-after: start-index
45+
:end-before: end-index
46+
47+
Reflog
48+
------
49+
50+
.. include:: ../glossary.rst
51+
:start-after: start-reflog
52+
:end-before: end-reflog

‎docs/productive/git/glossary.rst‎

Lines changed: 231 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -7,27 +7,72 @@ Git-Glossar
77

88
.. glossary::
99

10+
Blob
11+
Ein Blob-Objekt enthält den Inhalt einer Datei.
12+
13+
Bei jedem Commit speichert Git den gesamten Inhalt jeder Datei, den ihr
14+
geändert habt, als Blob. Wenn ihr beispielsweise einen Commit habt, der
15+
zwei Dateien in einem Repository ändert, erstellt dieser Commit zwei
16+
neue Blobs, sodass Commits selbst in sehr großen Repositories relativ
17+
wenig Speicherplatz beanspruchen.
18+
1019
Branch
1120
Zweig
12-
Ein Zweig ist eine Entwicklungslinie. Der letzte Commit auf einem Zweig
13-
wird als Spitze des Zweiges bezeichnet, der durch einen ``head``
14-
referenziert wird und der sich weiterbewegt, wenn weitere Entwicklungen
15-
auf dem Zweig vorgenommen werden. Ein einzelnes Git-Repository kann eine
16-
beliebige Anzahl von Zweigen haben, aber ihr :term:`Working Tree` ist
17-
nur mit einem von ihnen verbunden – dem *aktuellen* oder
18-
*ausgecheckten* Zweig – und :term:`HEAD` zeigt auf diesen Zweig.
21+
Ein Zweig ist eine Entwicklungslinie. Der letzte :term:`Commit` auf
22+
einem Zweig wird als Spitze des Zweiges bezeichnet, der durch einen
23+
:term:`HEAD` referenziert wird und der sich weiterbewegt, wenn weitere
24+
Entwicklungen auf dem Zweig vorgenommen werden. Ein einzelnes
25+
Git-Repository kann eine beliebige Anzahl von Zweigen haben, aber ihr
26+
:term:`Working Tree` ist nur mit einem von ihnen verbunden – dem
27+
*aktuellen* oder *ausgecheckten* Zweig – und :term:`HEAD` zeigt auf
28+
diesen Zweig.
1929

2030
Cache
2131
Veraltet für :term:`Index`.
2232

2333
Clone
2434
Klon
25-
Lokale Version eines Repository einschließlich aller Commits und
26-
Branches.
35+
Lokale Version eines Repository einschließlich aller :term:`Commits
36+
<Commit>` und :term:`Branches <Branch>`.
2737

2838
Commit
29-
Ein Snapshot des gesamten Git-Repository, komprimiert in einem `SHA
30-
<https://de.wikipedia.org/wiki/Secure_Hash_Algorithm>`_.
39+
Ein Commit ist ein Snapshot des gesamten Git-Repository, der durch einen
40+
`SHA <https://de.wikipedia.org/wiki/Secure_Hash_Algorithm>`_-Wert
41+
eindeutig identifiziert werden kann und mindestens die folgenden
42+
Angaben enthält:
43+
44+
* Verzeichnisstruktur aller Dateien dieser Version des Repositorys und
45+
Inhalt jeder Datei, gespeichert als :term:`Tree`-ID des obersten
46+
Verzeichnisses des Commits.
47+
* ID(s) des oder der übergeordneten Commits. Der erste Commit eines
48+
Repository hat keine übergeordneten Commits, reguläre Commits haben
49+
einen übergeordneten Commit, Merge-Commits haben zwei oder mehr
50+
übergeordnete Commits.
51+
* Autor und Zeitpunkt, zu dem der Commit erstellt wurde.
52+
* Committer und Zeitpunkt, zu dem der Commit committet wurde.
53+
* Commit-Nachricht
54+
55+
Beispiel:
56+
57+
.. code-block:: console
58+
59+
$ git cat-file -p main
60+
tree 47cc0283b10bd5e4e8a0d61537d13bba3bfad916
61+
parent 63825a43e213ef8a7904a8994976ac86284d32bd
62+
author veit <veit@cusy.io> 1770370977 +0100
63+
committer veit <veit@cusy.io> 1770370977 +0100
64+
65+
:memo: Add links to Python speed
66+
67+
Wie alle anderen Objekte können auch Commits nach ihrer Erstellung nicht
68+
mehr geändert werden. Wenn ihr also einen Commit mit ``git commit
69+
--amend`` ändern wollt, wird tatsächlich ein neuer Commit mit demselben
70+
Parent erstellt. Und auch wenn ihr euch einen Commit mit ``git show``
71+
anzeigen lasst, so wird das Diff zu diesem Zeitpunkt erst berechnet.
72+
73+
.. seealso::
74+
* `Commits are snapshots, not diffs
75+
<https://github.blog/open-source/git/commits-are-snapshots-not-diffs/>`_
3176

3277
Fork
3378
Kopie eines Repository auf :term:`GitHub` oder :term:`GitLab`, das einem
@@ -56,21 +101,57 @@ Git-Glossar
56101

57102
``HEAD``
58103
Der ``HEAD``-Zeiger repräsentiert euer aktuelles Arbeitsverzeichnis und
59-
kann mit ``git switch`` in verschiedene Zweige, Tags oder Commits
60-
verschoben werden.
104+
kann mit ``git switch`` in verschiedene :term:`Zweige <Zweig>`,
105+
:doc:`Tags <tag>` oder :term:`Commits <Commit>` verschoben werden.
61106

62107
Index
63-
Eine Sammlung von Dateien mit Statusinformationen, deren Inhalt als
64-
Objekte gespeichert wird. Der Index ist eine gespeicherte Version eures
65-
:term:`Working Tree`.
108+
Staging Area
109+
110+
.. _start-index
111+
112+
Liste von Dateien und deren Inhalten, die als :term:`Blob` gespeichert
113+
sind. Mit ``git add`` könnt ihr Dateien zum Index hinzufügen oder den
114+
Inhalt einer Datei im Index aktualisieren.
115+
116+
Im Gegensatz zu einem :term:`Tree` ist der Index eine flache Liste von
117+
Dateien. Wenn ihr committet, konvertiert Git die Liste der Dateien im
118+
Index in einen Verzeichnisbaum und verwendet diesen Baum für den neuen
119+
Commit. Jeder Indexeintrag hat vier Felder:
120+
121+
#. Einer der folgenden vier Dateitypen:
122+
123+
* reguläre Datei
124+
* ausführbare Datei
125+
* symbolischer Link
126+
* gitlink (für Submodule)
127+
128+
#. Blob-ID der Datei oder Commit-ID des Submoduls
129+
#. Staging-Nummer, normalerweise ``0``. Bei einen Merge-Konflikt kann es
130+
jedoch auch mehrere Versionen desselben Dateinamens im Index geben.
131+
#. Dateipfad
132+
133+
.. _end-index
66134
67135
Merge-Request
68136
Ort zum Vergleichen und Diskutieren der in einem Branch eingeführten
69137
Änderungen mit Bewertungen, Kommentaren, Tests :abbr:`etc. (et cetera)`;
70138

71139
.. seealso::
72-
* :doc:`advanced/gitlab/merge-requests`.
73-
* :ref:`Merge- oder Pull-Requests <merge-pull-requests>`.
140+
* :doc:`advanced/gitlab/merge-requests`
141+
* :ref:`Merge- oder Pull-Requests <merge-pull-requests>`
142+
143+
Objekt
144+
145+
.. _start-object
146+
147+
Alle :term:`Commits <Commit>` und Dateien in einem Git-Repository werden
148+
als Git-Objekte gespeichert, die sich nach ihrer Erstellung nie mehr
149+
ändern und eine eindeutige ID haben, :abbr:`z. B. (zum Beispiel)`
150+
``133d35a8bd42b6d327e6676d916d656b65782312``. :abbr:`D. h. (Das heißt)`,
151+
dass ihr mit der ID eines Objekts jederzeit dessen Inhalt
152+
wiederherstellen könnt, solange das Objekt nicht gelöscht wurde.
153+
154+
.. _end-object
74155
75156
``origin``
76157
Das übliche Upstream-Repository. Die meisten Projekte haben mindestens
@@ -79,10 +160,142 @@ Git-Glossar
79160
Zweige mit dem Namen :samp:`origin/{NAME_OF_UPSTREAM_BRANCH}` geholt,
80161
die ihr mit ``git branch -r`` sehen könnt.
81162

163+
Referenz
164+
165+
.. _start-refs
166+
167+
Referenzen sind eine Möglichkeit, Commits einen Namen zu geben, der
168+
einfacher, zu merken ist. Git verwendet häufig ``ref`` als Abkürzung für
169+
solche Referenzen. Die wichtigsten Referenzen sind:
170+
171+
:samp:`.git/refs/heads/{BRANCHNAME}`
172+
Ein Branch bezieht sich auf die ID des neuesten Commits auf diesem
173+
Branch. Um die Historie der :term:`Commits <Commit>` auf einem
174+
:term:`Branch` abzurufen, beginnt Git bei der Commit-ID, auf die der
175+
Branch verweist, und sieht sich dann die übergeordneten Commits an.
176+
Referenzen können sich beziehen auf
177+
178+
* eine Objekt-ID, in der Regel eine Commit-ID
179+
* eine andere, *symbolische* Referenz
180+
181+
:samp:`.git/refs/tags/<{TAGNAME}`
182+
Ein Tag bezieht sich auf eine Commit-ID, eine Tag-Objekt-ID oder
183+
eine andere Objekt-ID.
184+
185+
``.git/HEAD``
186+
``HEAD`` ist der Ort, an dem Git euren aktuellen :term:`Branch`
187+
speichert. HEAD kann entweder
188+
189+
* eine symbolische Referenz auf euren aktuellen Branch sein,
190+
:abbr:`z.B. (zum Beispiel)` ``ref: refs/heads/main``.
191+
* eine direkte Referenz auf eine Commit-ID wenn es keinen aktuellen
192+
Branch gibt, also in einem *detached HEAD state*.
193+
194+
:samp:`.git/refs/remotes/{REMOTE}/{BRANCHNAME}`
195+
Ein Remote-Tracking-Branch bezieht sich auf eine Commit-ID. Mit
196+
``git fetch`` könnt ihr diese :abbr:`ggf. (gegebenenfalls)`
197+
aktualisieren und wenn ``git status`` ``Your branch is up to date
198+
with 'origin/main'`` ausgibt, bezieht es sich darauf.
199+
200+
``refs/remotes/{REMOTE}/HEAD`` ist eine symbolische Referenz auf den
201+
Standard-Zweig des Remote-Repositories.
202+
203+
.. _end-refs:
204+
205+
Reflog
206+
207+
.. _start-reflog
208+
209+
Jedes Mal, wenn ein :term:`Branch`, ein Remote-Tracking-Branch oder HEAD
210+
aktualisiert wird, aktualisiert Git ein Protokoll namens *Reflog* für
211+
diese Referenz. Jeder Eintrag des Reflog enthält:
212+
213+
* Commit-ID
214+
* Zeitstempel, zu dem die Änderung vorgenommen wurde
215+
* Protokollmeldung, :abbr:`z. B. (zum Beispiel)` ``commit`` oder
216+
``reset``
217+
218+
Reflogs protokollieren nur Änderungen, die in eurem lokalen Repository
219+
vorgenommen wurden. Sie werden jedoch nicht im :term:`Remote Repository`
220+
geteilt.
221+
222+
Ihr könnt euch ein Reflog mit :samp:`git reflog {REFERENZ}` anzeigen
223+
lassen, :abbr:`z. B. (zum Beispiel)`:
224+
225+
.. code-block:: console
226+
227+
$ git reflog
228+
133d35a (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: commit: :memo: Add links to Python speed
229+
63825a4 HEAD@{1}: reset: moving to @~
230+
...
231+
232+
.. _end-reflog
233+
82234
Remote Repository
83235
Gemeinsames Repository, :abbr:`z.B. (zum Beispiel)` auf :term:`GitLab`,
84236
zum Austausch von Änderungen in einem Team.
85237

238+
Tag-Objekt
239+
Tag-Objekte enthalten mindestens die folgenden Felder:
240+
241+
* ID des Objekts, auf das es verweist
242+
* Typ des Objekts, auf das es verweist
243+
* Tag-Nachricht
244+
* Tagger und Tag-Datum
245+
246+
Beispiel:
247+
248+
.. code-block:: console
249+
250+
$ git cat-file -p 24.3.0
251+
object aa366cc9af3497544338482f82bdeb21f1dd3c21
252+
type commit
253+
tag 24.3.0
254+
tagger Veit Schiele <veit@cusy.io> 1732086922 +0100
255+
256+
Tree
257+
Darstellung eines Verzeichnisses in Git und kann Dateien oder andere
258+
Bäume (also Unterverzeichnisse) enthalten. Für jedes Element im Baum
259+
listet er Folgendes auf:
260+
261+
* Dateiname
262+
* Dateityp:
263+
264+
* normale Datei
265+
* ausführbare Datei
266+
* symbolischer Link
267+
* Verzeichnis
268+
* gitlink (für Submodule)
269+
270+
* Objekt-ID mit dem Inhalt der Datei, des Verzeichnisses oder des
271+
gitlinks
272+
273+
Beispiel:
274+
275+
.. code-block:: console
276+
277+
$ git cat-file -p main^{tree}
278+
040000 tree 2f59a223f7dc767f4776e77762d208fa72bfd343 .dvc
279+
040000 tree 75833fd33271db55b6f1c96915f60f98a60b51a0 .github
280+
100644 blob 36d2dc5a5228cbf65b8cfe913565c9be49db1a3d .gitignore
281+
...
282+
$ git cat-file -p 2f59a223f7dc767f4776e77762d208fa72bfd343
283+
100644 blob 669784da1fe0818e9abb795f73b7faf393832f2e .gitignore
284+
100644 blob 0a66f9a9ab72e3a99994803de8337f523b1b93d0 config
285+
$ git cat-file -p 36d2dc5a5228cbf65b8cfe913565c9be49db1a3d
286+
# SPDX-FileCopyrightText: 2019 Veit Schiele
287+
#
288+
# SPDX-License-Identifier: BSD-3-Clause
289+
...
290+
291+
.. hint::
292+
Die erste Spalte eines Baum-Eintrags orientiert sich grob an den
293+
`Unix-Dateirechten
294+
<https://de.wikipedia.org/wiki/Unix-Dateirechte>`_, tatsächlich
295+
können mit Git jedoch Unix-Dateirechte verwaltet werden. Hierzu sind
296+
Erweiterungen, wie :abbr:`z.B. (zum Beispiel)`
297+
:doc:`advanced/etckeeper` erforderlich.
298+
86299
Trunk-Based Development
87300
TBD
88301
Git-Workflow mit kurzlebigen Themenzweigen, die schnell zum einem

0 commit comments

Comments
 (0)