1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="version-control" xml:lang="de">
<info>
<link type="guide" xref="index#general-guidelines"/>
<credit type="author copyright">
<name>Philip Withnall</name>
<email its:translate="no">philip.withnall@collabora.co.uk</email>
<years>2015</years>
</credit>
<include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>
<desc>Quellcode-Versionsverwaltung mit Git</desc>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Mario Blättermann</mal:name>
<mal:email>mario.blaettermann@gmail.com</mal:email>
<mal:years>2016, 2018</mal:years>
</mal:credit>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Christian Kirbach</mal:name>
<mal:email>christian.kirbach@gmail.com</mal:email>
<mal:years>2016, 2020</mal:years>
</mal:credit>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Stefan Melmuk</mal:name>
<mal:email>stefan.melmuk@gmail.com</mal:email>
<mal:years>2018</mal:years>
</mal:credit>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Tim Sabsch</mal:name>
<mal:email>tim@sabsch.com</mal:email>
<mal:years>2021</mal:years>
</mal:credit>
</info>
<title>Versionsverwaltung</title>
<synopsis>
<title>Zusammenfassung</title>
<p>Git ist das Versionskontrollsystem aller GNOME-Projekte. Auf dieser Seite nehmen wir an, dass Sie bereits gute praktische Erfahrungen mit git besitzen. Einführungsmaterialien finden Sie <link href="https://www.atlassian.com/git/tutorials/">hier</link>, ein Cheatsheet finden Sie außerdem <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">hier</link>.</p>
<list>
<item><p>Erstellen Sie atomare, reversible Commits. (<link xref="#guidelines-for-making-commits"/>)</p></item>
<item><p>Nehmen Sie alle Hintergründe in die Commit-Nachrichten auf, einschließlich Verweise auf Fehlerberichte und Spezifikationen. (<link xref="#guidelines-for-making-commits"/>)</p></item>
<item><p>Stecken Sie große Änderungen wie Umbenennungen in separate Commits. (<link xref="#guidelines-for-making-commits"/>)</p></item>
<item><p>Führen Sie Änderungen aus Feature-Branchen durch Rebasen zusammen. (<link xref="#use-of-git"/>)</p></item>
</list>
</synopsis>
<section id="use-of-git">
<title>Verwendung von Git</title>
<p>Die meisten GNOME-Repositories folgen diesen Regeln:</p>
<list>
<item><p>Keine erzwungenen Pushes. Mit Ausnahme von Branches mit dem <code>wip/</code>-Präfix (»Work in Progress«) darf der Commit-Verlauf nicht geändert werden, da sich Mitwirkende darauf verlassen.</p></item>
<item><p>Rebasen Sie Commits eher als Mergen, um die History linear zu halten (welcher einfacher zu folgen ist)</p></item>
<item><p>Arbeiten Sie im GNOME-git mit Feature-Branches (<code>wip/</code>-Präfix), rebasen Sie anschließend auf dem master-Branch und führen Sie die Änderungen mit einem fast-forward-Merge zusammen. Es hat sich ebenfalls bewährt, dass Sie Ihren Nutzernamen in der Form <code>wip/nickname/feature</code> zum Branch hinzufügen.</p></item>
<item><p>Verstecken Sie Ihre <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">Wurstherstellung</link>, indem Sie Commits vor dem Merge zusammenlegen (»squash«).</p></item>
</list>
</section>
<section id="guidelines-for-making-commits">
<title>Richtlinien für Commits</title>
<p>Commits sollten so klein wie möglich sein, aber nicht kleiner. Jeder Commit sollte ein einzelnes Problem adressieren und nur dazu unmittelbar relevante Änderungen enthalten. Die Commit-Nachricht sollte das Problem beschreiben, die Ursache erklären sowie die Lösung aufzeigen, sofern diese nicht offensichtlich ist. Bezieht sich der Commit auf einen Fehlerbericht, sollte in der letzten Zeile der Commit-Nachricht die vollständige URI des Berichts stehen. Ebenso sollte die Commit-Kennung (zu erhalten mittels <cmd>git log --oneline</cmd>) in den Fehlerbericht kopiert werden, sobald der Commit hochgeladen wurde.</p>
<p>Die Änderungen in jedem Commit sollten einfach zu lesen sein. Zum Beispiel sollten keine unnötigen Änderungen an den Leerzeichen oder Einrückungen enthalten sein. Große, mechanische Änderungen wie das Umbenennen einer Datei oder Funktion sollten in einem eigenen Commit separat von inhaltlichen Änderungen am Code in der Datei oder Funktion stattfinden, damit letztere nicht verloren gehen.</p>
<p>Die folgenden Prinzipien erklären die soeben aufgezeigten Ratschläge:</p>
<list>
<item><p>Jeder Commit überträgt das Repository von einem funktionierenden Zustand in einen anderen. Anderenfalls ist <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">Bisection</link> unmöglich.</p></item>
<item><p>Jeder Commit sollte in sich reversibel sein. Sollte sich später herausstellen, dass der Commit keine gute Idee war, sollte ein <cmd>git revert <var>commit ID</var></cmd> das Repository von einem funktionierenden Zustand in einen anderen übertragen.</p></item>
<item><p>Die Hintergründe jedes Commits und seine Beziehungen zu externen Ressourcen wie Spezifikationen und Fehlerberichten sollten klar sein. Ein Entwickler sollte noch ein Jahr später in der Lage sein zu verstehen, was ein anderer Entwickler gemacht hat, ohne sich durch alle Änderungen wühlen zu müssen.</p></item>
<item><p>Jeder Commit sollte einmalig geschrieben und dann vielfach gelesen werden können, von vielen Reviewern und künftigen Entwicklern.</p></item>
</list>
</section>
<section id="merging-procedure">
<title>Merge-Prozess</title>
<p>Um einen Feature-Branch namens <code>my-branch</code> in den master-Branch zu mergen, verwenden Sie die folgenden Befehle:</p>
<code mime="application/x-shellscript">
git checkout master
git pull
git checkout wip/<var>my-branch</var>
git rebase --interactive master
# Ensure the rebase is successful; test the changes
git checkout master
git merge wip/<var>my-branch</var>
git push
# wip/<var>my-branch</var> can now be deleted
git push origin :wip/<var>my-branch</var>
git branch -D wip/<var>my-branch</var></code>
</section>
<section id="external-links">
<title>Externe Links</title>
<list>
<item><p><link href="https://sethrobertson.github.io/GitBestPractices/">Git best practices</link></p></item>
<item><p><link href="https://help.github.com/categories/using-git/">Git FAQ</link></p></item>
<item><p><link href="https://www.atlassian.com/git/tutorials/">Atlassian git tutorial</link></p></item>
<item><p><link href="http://git-scm.com/docs/gittutorial">Offizielles Git-Tutorial</link></p></item>
<item><p><link href="https://try.github.io/">Interaktives Git-Tutorial</link></p></item>
<item><p><link href="http://www.git-tower.com/learn/">Tutorial zu git-tower</link></p></item>
</list>
</section>
</page>
|
