[ English | Indonesia | 한국어 (대한민국) | español (México) | English (United Kingdom) | Deutsch | 中文 (简体, 中国) ]

Einrichten und Erlernen von GIT

Bemerkung

In diesem Abschnitt wird davon ausgegangen, dass Sie die Anleitung Konto-Setup abgeschlossen haben.

GIT

Was ist Git?

Git ist ein kostenloses und quelloffenes verteiltes Versionskontrollsystem, mit dem die OpenStack-Community Änderungen an Quellcode und Dokumentation verwaltet.

Git erlaubt es Ihnen:

Installation

Mac OS

  1. Gehen Sie zur Git Download-Seite und klicken Sie auf Mac OS X.

  2. Die heruntergeladene Datei sollte eine dmg in Ihrem Download-Ordner sein. Öffnen Sie diese dmg-Datei und folgen Sie den Anweisungen auf dem Bildschirm.

Wenn Sie den Paketmanager Homebrew verwenden, öffnen Sie ein Terminal und geben Sie ein:

brew install git

Linux

Für Distributionen wie Debian, Ubuntu oder Mint öffnen Sie ein Terminal und geben Sie ein:

sudo apt install git

For distributions like RedHat, Fedora or CentOS open a terminal and type:

sudo dnf install git

Für SUSE-Distributionen öffnen Sie ein Terminal und geben Sie ein:

sudo zypper in git

Windows

Windows Subsystem für Linux (WSL) ist in Windows 10 Anniversary Update oder höher (Build 1607+) verfügbar. Es besteht die Möglichkeit, moderne Linux-Betriebssysteme zu installieren und zu betreiben:

Alle gängigen Tools wie bash, git und SSH funktionieren sofort nach dem Auspacken.

Obwohl Git Download-Seite Windows Installationsbinärdateien anbietet, werden die meisten OpenStack-Entwicklungswerkzeuge (z.B. git-review) leider nicht gut in der Windows-Umgebung funktionieren.

Git konfigurieren

Sobald Sie Git installiert haben, müssen Sie es konfigurieren. Öffnen Sie Ihre Terminalanwendung und geben Sie die folgenden Befehle ein, indem Sie Ihren Vor-/Nachnamen und Ihre E-Mail-Adresse eingeben. So werden Ihre Beiträge identifiziert:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

Bemerkung

Verwenden Sie die gleiche E-Mail-Adresse, die bei der Einrichtung des Kontos verwendet wurde.

Git erlernen

You can use Git Immersion to work through tutorials for learning git.

Als Referenz verwenden Sie das Git Reference and Cheat Sheet.

Commit-Meldungen

Commit-Meldungen sind die ersten Dinge, die ein Reviewer sieht und werden als Beschreibungen im Git-Log verwendet. Sie liefern eine Beschreibung der Historie der Änderungen in einem Repository. Commit-Nachrichten können nach dem Zusammenführen des Patches nicht mehr geändert werden.

Format:

  • Summenzeile

  • Leere Zeile

  • Body

  • Leere Zeile

  • Footers

Bemerkung

Footers should be entered one per line with no empty lines between them.

Summenzeile

Die Summenzeile beschreibt kurz den Inhalt des Patches. Die Zeichenbeschränkung beträgt 50 Zeichen. Die Summenzeile sollte nicht mit einem Punkt enden. Wenn die Änderung zum Zeitpunkt der Übertragung noch nicht abgeschlossen ist, starten Sie die Commit-Nachricht mit WIP.

Body

Der Body enthält die Erklärung des zu lösenden Problems und warum es behoben werden sollte, die Beschreibung der Lösung und zusätzliche optionale Informationen, wie es die Code-Struktur verbessert, oder Verweise auf andere relevante Patches, zum Beispiel. Die Zeilen sind auf 72 Zeichen begrenzt. Die Stelle sollte alle wichtigen Informationen im Zusammenhang mit dem Problem enthalten, ohne davon auszugehen, dass der Leser die Ursache des Problems versteht oder Zugang zu externen Seiten hat.

Footers

Footers are lines in the final paragraph of a commit message, used to link the change to other tools.

The following footer is required:

  • The Change-Id line is a unique hash describing the change, which is generated automatically by a Git commit hook when you initially save a commit message. This should not be changed when rebasing a commit following review feedback, since it is used by Gerrit, to track versions of a patch. It won’t appear when you’re editing a new commit message for the first time, but if you commit --amend later you will see it.

StoryBoard specific footers:

  • Task: 1234: the number of the task in Storyboard implemented by the change. This will auto update the task to ‚Review‘ status and assign it to you when you push the patch.

  • Story: 1234567: the number of the story in Storyboard to which the task being implemented belongs. This will post a comment on the story with a link to your patch.

Launchpad specific footers:

  • Closes-Bug: #123456789: use Closes-Bug if the commit is intended to fully fix and close the bug being referenced. Use the Launchpad ID of the bug for the number; Gerrit automatically creates a link to the bug.

  • Partial-Bug: #123456789: use Partial-Bug if the commit is only a partial fix and more work is needed. Use the Launchpad ID of the bug for the number; Gerrit automatically creates a link to the bug.

  • Related-Bug: #12456789: use Related-Bug if the commit is merely related to the referenced bug. Use the Launchpad ID of the bug for the number; Gerrit automatically creates a link to the bug.

  • Partial-Implements: Use this footer if the change partially implements a Launchpad blueprint. Use the name of the blueprint as an ID.

  • Implements: Use this footer if the change fully implements a Launchpad blueprint. Use the name of the blueprint as an ID.

The following footers are optional; however, their use is recommended if they are applicable to the patch:

  • The DocImpact footer contains a comment about why the change impacts documentation. Put DocImpact on a line by itself. Use this footer to indicate that documentation is either contained in the patch or has documentation impact. When this footer is included in a commit message, Gerrit creates a bug for the project affected by the change for task tracking, or move to the openstack-api-site as needed.

  • The APIImpact footer contains a comment about why the change impacts a public HTTP API. Put APIImpact on a line by itself. Use this footer to indicate that the patch impacts a public HTTP API. When this footer is included in a commit message, the API_Working_Group can use it to help find relevant reviews.

  • The SecurityImpact footer is used to indicate that a change has security implications and should be reviewed by the OpenStack Security Group.

  • The UpgradeImpact footer contains a comment about why the change impacts upgrades. It is used to indicate that a change has upgrade implications for those doing continuous deployment or N to N+1 upgrades. Also consider updating the ‚Upgrade Notes‘ section in the release notes for the affected project.

  • The Depends-On: <gerrit-change-url> footer is used to refer to a change the current one depends on. Use the permalink of the change.