Zweige¶

Übersicht¶

Die Zweige-Ansicht gibt Ihnen einen Überblick über die verschiedenen Zweige Ihres Repositorys.

Phasen¶

Odoo.sh bietet drei unterschiedliche Phasen für Ihre Zweige an: Produktion, Staging und Entwicklung.

Sie können die Phase eines Zweigs ändern, indem Sie ihn per Drag-and-drop in den Titel des Phasenabschnitts ziehen.

Produktion¶

Es handelt sich um den Zweig, der den Code enthält, auf dem Ihre Produktionsdatenbank läuft. Es kann nur einen Produktionszweig geben.

Wenn Sie einen neuen Commit in diesem Zweig durchführen, wird Ihr Produktionsserver mit dem Code der neuen Revision aktualisiert und anschließend neu gestartet.

Wenn Ihre Änderungen die Aktualisierung eines Moduls erfordern, z. B. eine Änderung in einer Formularansicht, und Sie möchten, dass diese automatisch durchgeführt wird, erhöhen Sie die Versionsnummer des Moduls in seinem Manifest (__manifest__.py). Die Plattform kümmert sich dann darum, die Aktualisierung durchzuführen, während die Instanz aus Wartungsgründen vorübergehend nicht verfügbar ist.

Diese Methode ist vergleichbar mit einem Upgrade des Moduls über das Apps-Menü oder über den Schalter -u in der Befehlszeile.

Falls die Änderungen in der Commit-Datei einen Neustart des Servers verhindern oder das Update der Module fehlschlägt, wird der Server automatisch auf die vorherige erfolgreiche Codeversion zurückgesetzt und die Datenbank wird so wiederhergestellt, wie sie vor dem Update war. Sie haben immer noch Zugriff auf das Protokoll des fehlgeschlagenen Updates, sodass Sie eine Fehlersuche durchführen können.

Die Demodaten werden nicht geladen, da sie nicht für die Verwendung in einer Produktionsdatenbank gedacht sind. Die Einheitstests werden nicht durchgeführt, da dies die Nichtverfügbarkeitszeit der Produktionsdatenbank während der Updates erhöhen würde.

Partner, die Testprojekte verwenden, sollten sich darüber im Klaren sein, dass ihr Produktionszweig sowie alle Staging-Zweige nach 30 Tagen automatisch auf die Entwicklungsstufe zurückgesetzt werden.

Staging¶

Staging-Zweige testen Ihre neuen Funktion mithilfe der Produktionsdaten ohne die tatsächliche Produktionsdatenbank mit Testdatensätzen zu gefährden. Sie erstellen Datenbanken, die neutralisierte Duplikate der Produktionsdatenbank sind.

Die Neutralisierung beinhaltet:

• Deaktivierung geplanter Aktionen. Wenn Sie die Aktionen testen möchten, können Sie sie manuell auslösen oder wieder aktivieren. Beachten Sie, dass die Plattform sie weniger oft auslöst, wenn niemand die Datenbank benutzt, um Ressourcen zu sparen.

• Deaktivierung ausgehender E-Mails, indem Sie sie mit einem Mailcatcher abfangen. Eine Schnittstelle zur Anzeige der von Ihrer Datenbank gesendeten E-Mails wird bereitgestellt. Auf diese Weise müssen Sie sich nicht um den Versand von Test-E-Mails an Ihre Kontakte kümmern.

• Einstellung von Zahlungsanbietern und Versandzustellern im Testmodus.

• Deaktivierung von IAP-Services

Die neueste Datenbank wird auf unbestimmte Zeit beibehalten. Ältere Datenbanken aus demselben Zweig werden möglicherweise gelöscht, um Platz für neue zu schaffen. Sie ist 3 Monate lang gültig, danach wird von Ihnen erwartet, dass Sie den Zweig neu erstellen. Wenn Sie in diesen Datenbanken Änderungen an der Konfiguration oder Ansicht vornehmen, sollten Sie diese dokumentieren oder direkt in die Module des Zweigs schreiben, indem Sie XML-Datendateien verwenden, die die Standardkonfiguration oder -ansichten überschreiben.

Die Einheitstests werden nicht ausgeführt, da sie in Odoo derzeit auf den Demodaten basieren, die nicht in die Produktionsdatenbank geladen werden. Wenn Odoo in Zukunft die Ausführung der Einheitstests ohne die Demodaten unterstützt, wird Odoo.sh die Ausführung der Tests auf Staging-Datenbanken in Betracht ziehen.

Entwicklung¶

Entwicklungszweige erstellen neue Datenbanken unter Verwendung der Demodaten, um die Einheitstests auszuführen. Die installierten Module sind die, die in Ihren Zweigen enthalten sind. Sie können diese Liste der zu installierenden Module in Ihren Projekteinstellungen ändern.

Wenn Sie einen neuen Commit in einem dieser Zweige durchführen, wird ein neuer Server mit einer von Grund auf neu erstellten Datenbank und der neuen Revision des Zweigs gestartet. Die Demodaten werden geladen und die Einheitstests werden standardmäßig ausgeführt. Dadurch wird sichergestellt, dass Ihre Änderungen keine der getesteten Funktionen beeinträchtigen. Wenn Sie möchten, können Sie die Tests deaktivieren oder die Ausführung bestimmter Tests mit benutzerdefinierten Stichwörtern in den Einstellungen des Zweigs erlauben.

Ähnlich wie bei den Staging-Zweigen werden die E-Mails nicht versendet, sondern von einem Mailcatcher abgefangen und geplante Aktionen werden nicht ausgelöst, solange die Datenbank nicht in Gebrauch ist.

Die Datenbanken, die für Entwicklungszweige erstellt werden, sind für eine Lebensdauer von etwa drei Tagen vorgesehen. Danach können sie automatisch und ohne vorherige Ankündigung gelöscht werden, um Platz für neue Datenbanken zu schaffen.

Ihre Zweige zusammenführen¶

Sie können Ihre Zweige ganz einfach zusammenführen, indem Sie sie per Drag-and-drop ineinander verschieben.

Wenn Sie die Änderungen Ihrer Entwicklungszweige mit den Produktionsdaten testen möchten, können Sie entweder:

• den Entwicklungszweig mit Ihrem Staging-Zweig zusammenführen, indem Sie ihn per Drag-and-drop in den gewünschten Staging-Zweig ziehen,

• den Entwicklungszweig per Drag & Drop auf den Titel des Staging-Bereichs ziehen, um ihn zu einem Staging-Zweig zu machen.

Wenn Ihre neuesten Änderungen bereit für die Produktion sind, können Sie Ihren Staging-Zweig per Drag-and-drop in Ihren Produktionszweig ziehen, um Ihre neuesten Funktionen zusammenzuführen und in der Produktion einzusetzen.

Wenn Sie sich trauen, können Sie auch Ihre Entwicklungszweige in Ihrem Produktionszweig zusammenführen. Das bedeutet lediglich, dass Sie die Validierung Ihrer Änderungen mit den Produktionsdaten über einen Staging-Zweig überspringen.

Sie können Ihre Entwicklungszweige ineinander und Ihre Staging-Zweige ineinander einmischen.

Natürlich können Sie auch git merge direkt auf Ihrem Arbeitsplatz verwenden, um Ihre Zweige zusammenzuführen. Odoo.sh wird benachrichtigt, wenn neue Revisionen in Ihren Zweigen durchgeführt wurden.

Wenn Sie einen Staging-Zweig im Produktionszweig zusammenführen, wird nur der Quellcode zusammengeführt: Alle Konfigurationsänderungen, die Sie in den Staging-Datenbanken vorgenommen haben, werden nicht auf die Produktionsdatenbank übertragen.

Wenn Sie Konfigurationsänderungen in Staging-Zweigen testen und diese in der Produktion anwenden möchten, müssen Sie entweder:

• die Konfigurationsänderungen in XML-Datendateien schreiben, die die Standardkonfiguration oder -ansichten in Ihren Zweigen überschreiben, und dann die Version Ihres Moduls in seinem Manifest (__manifest__.py) erhöhen, um das Update des Moduls auszulösen, wenn Sie Ihren Staging-Zweig in Ihrem Produktionszweig zusammenführen. Dies ist die beste Lösung für eine bessere Skalierbarkeit Ihrer Entwicklungen, da Sie die Git-Versionierungsfunktionen für alle Ihre Konfigurationsänderungen verwenden und somit Ihre Änderungen nachverfolgen können.

• sie manuell von Ihrer Staging- in Ihre Produktionsdatenbank übertragem, indem Sie sie kopieren und einfügen.

Reiter¶

Historie¶

Eine Übersicht Ihrer Zweighistorie:

• Die Meldungen der Commits und deren Autoren,

• Die unterschiedlichen Ergeinisse, die mit der Plattform verbunden sind, wie Phasenänderungen, Datenbankimporte, Back-up-Wiederherstellungen.

Für jedes Ereignis wird in der oberen rechten Ecke ein Status angezeigt. Er kann Informationen über den laufenden Vorgang in der Datenbank (Installation, Update, Back-up-Import …) oder dessen Ergebnis (Feedbacks zu Tests, erfolgreicher Back-up-Import …) enthalten. Wenn ein Vorgang erfolgreich war, können Sie über die Schaltfläche Verbinden auf die Datenbank zugreifen.

Mails¶

Dieser Reiter enthält den Mail-Catcher. Er zeigt eine Übersicht über die von Ihrer Datenbank gesendeten E-Mails an. Der Mail-Catcher ist für Ihre Entwicklungs- und Staging-Zweige verfügbar, da die E-Mails Ihrer Produktionsdatenbank wirklich versendet werden, anstatt abgefangen zu werden.

Shell¶

Ein Shell-Zugriff auf Ihren Container. Sie können grundlegende Linux-Befehle ausführen (ls, top) und eine Shell für Ihre Datenbank öffnen, indem Sie psql eingeben.

Sie können mehrere Reiter öffnen und sie per Drag-und-drop anordnen, um das Layout nach Ihren Wünschen zu gestalten, z. B. nebeneinander.

Editor¶

Eine integrierte Online-Entwicklungsumgebung (Integrated Development Environment, IDE) zur Bearbeitung des Quellcodes. Sie können auch Terminals, Python-Konsolen und sogar Odoo-Shell-Konsolen öffnen.

Sie können mehrere Reiter öffnen und sie per Drag-und-drop anordnen, um das Layout nach Ihren Wünschen zu gestalten, z. B. nebeneinander.

Überwachung¶

Dieser Link enthält unterschiedliche Überwachungsmetriken des aktuellen Builds.

Sie können in jedem Diagramm zoomen, den Zeitraum ändern oder eine bestimmte Metrik auswählen. Anmerkungen in den Diagrammen helfen Ihnen dabei, sich auf Änderungen im Build zu beziehen (Datenbankimport, Git-Push usw.).

Protokolle¶

Ein Viewer, um Ihre Serverprotokolle einzusehen.

Verschiedene Protokolle sind verfügbar:

• install.log: Die Protokolle der Datenbankinstallation. In einem Entwicklungszweig sind die Protokolle der Tests inbegriffen.

• pip.log: Die Protokolle der Installation von Python-Abhängigkeiten.

• odoo.log: Die Protokolle der laufenden Server.

• update.log: Die Protokolle der Datenbankupdates.

• pg_long_queries.log: Die Protokolle der psql-Abfragen, die einen ungewöhnlichen Zeitaufwand einnehmen.

Wenn die neuen Zeilen in den Protokollen hinzugefügt werden, werden Sie automatisch angezeigt. Wenn Sie nach unten scrollen, scrollt der Browser automatisch mit, wenn eine neue Zeile hinzugefügt wird.

Sie können das Abrufen der Protokolle unterbrechen, indem Sie auf die entsprechende Schaltfläche in der oberen rechten Ecke der Ansicht klicken. Der Abruf wird nach 5 Minuten automatisch gestoppt. Sie können ihn über die Wiedergabe-Schaltfläche erneut starten.

Back-ups¶

Eine Liste der zum Download und zur Wiederherstellung verfügbaren Back-ups, die Möglichkeit, ein manuelles Back-up durchzuführen und eine Datenbank zu importieren.

Odoo.sh erstellt täglich Back-ups der Produktionsdatenbank. Es speichert 7 tägliche, 4 wöchentliche und 3 monatliche Back-ups. Jedes Back-up umfasst den Datenbank-Dump, den Dateispeicher (Anhänge, binäre Felder), Protokolle und Sitzungen.

Es werden keine Back-ups für Staging- und Entwicklungsdatenbanken durchgeführt. Sie können jedoch zu Testzwecken ein Back-up der Produktionsdatenbank in Ihren Staging-Zweigen wiederherzustellen oder Daten, die versehentlich aus der Produktionsdatenbank gelöscht wurden, manuell wiederherzustellen.

Die Liste enthält die Back-ups, die auf dem Server aufbewahrt werden, auf dem Ihre Produktionsdatenbank gehostet wird. Dieser Server bewahrt Back-ups nur einen Monat lang auf: 7 tägliche und 4 wöchentliche Back-ups.

Besondere Back-up-Server bewahren dieselben Back-ups auf, sowie 3 zusätzliche monatliche Back-ups. Um eines dieser monatlichen Back-ups wiederherzustellen oder herunterzuladen, kontaktieren Sie uns bitte.

Wenn Sie einen Commit zusammenführen, der die Version eines oder mehrerer Module (in __manifest__.py) oder deren verknüpfte Python-Abhängigkeiten (in requirements.txt) aktualisiert, führt Odoo.sh automatisch ein Back-up durch (in der Liste mit dem Typ „Update“ gekennzeichnet), da entweder der Container durch die Installation neuer Pip-Pakete verändert wird oder die Datenbank selbst durch das danach ausgelöste Modul-Update verändert wird. In diesen beiden Fällen führen wir ein Back-up durch, da dies möglicherweise zu Problemen führen könnte.

Wenn Sie einen Commit zusammenführen, der nur einige Codeänderungen ohne die oben erwähnten Modifikationen vornimmt, wird von Odoo.sh kein Back-up erstellt, da weder der Container noch die Datenbank verändert werden und die Plattform dies als sicher genug betrachtet. Als zusätzliche Vorsichtsmaßnahme können Sie natürlich manuell ein Back-up erstellen, bevor Sie größere Änderungen an Ihren Produktionsquellen vornehmen, für den Fall, dass etwas schief geht (diese manuellen Back-ups sind etwa eine Woche lang verfügbar). Um Missbrauch zu vermeiden, beschränken wir die manuellen Back-ups auf 5 pro Tag.

Die Funktion Datenbank importieren akzeptiert Datenbankarchive im Format, zur Verfügung gestellt von:

• dem Standard-Odoo-Datenbankmanager (verfügbar für On-premise-Odoo-Server unter /web/database/manager)

• dem Odoo-Online-Datenbankmanager,

• der Schaltfläche zum Herunterladen von Odoo.sh-Back-ups dieses Back-ups-Reiters,

• der Schaltfläche zum Herunterladen eines Odoo.sh-Dumps in der Builds-Ansicht.

Upgrade¶

Verfügbar für Produktions- und Staging-Zweige für gültige Projekte.

Einstellungen¶

Hier finden Sie eine Reihe von Einstellungen, die nur für den aktuell ausgewählten Zweig gelten.

Verhalten bei neuem Commit

Für Entwicklungs- und Staging-Zweige können Sie das Verhalten des Zweigs beim Erhalt eines neuen Commits ändern. Standardmäßig erstellt ein Entwicklungszweig einen neuen Build und aktualisiert ein Staging-Zweig den vorherigen Build (siehe Produktionsphase). Dies ist vor allem dann nützlich, wenn die Funktion, an der Sie arbeiten, eine bestimmte Einrichtung oder Konfiguration erfordert, damit Sie sie nicht bei jedem Commit erneut manuell einrichten müssen. Wenn Sie für einen Staging-Zweig einen neuen Build wählen, wird bei jedem Commit eine neue Kopie des Produktions-Builds erstellt. Ein Zweig, der von Staging auf Entwicklung zurückgestellt wird, wird automatisch auf „Nichts tun“ gesetzt.

Modulinstallation

Wählen Sie die Module, die automatisch für Ihre Entwicklungs-Builds installiert werden sollen.

• Nur meine Module installieren installiert nur die Module des Zweigs. Dies ist die Standardoption. Die Untermodule werden ausgeschlossen.

• Vollständige Installation (alle Module) installiert die Module des Zweigs, die in den Untermodulen enthaltenen Module und alle Standardmodule von Odoo. Bei der vollständigen Installation ist die Test-Suite deaktiviert.

• Eine Liste von Modulen installieren installiert die Module, die in der Eingabe direkt unter dieser Option angegeben sind. Die Namen sind die technischen Namen der Module und müssen durch Kommata getrennt sein.

Wenn die Tests aktiviert sind, kann die Standard-Odoo-Modul-Suite bis zu 1 Stunde dauern. Diese Einstellung gilt nur für Entwicklungs-Builds. Staging-Builds duplizieren den Produktions-Build und der Produktions-Build installiert nur die Basis.

Test-Suite

Für Entwicklungszweige können Sie die Test-Suite aktivieren oder deaktivieren. Sie ist standardmäßig aktiviert. Wenn die Test-Suite aktiviert ist, können Sie sie einschränken, indem Sie Test-Stichwörter Test-Stichwörter angeben.

Odoo-Version

Nur für Entwicklungszweige können Sie die Version von Odoo ändern, wenn Sie aktualisierten Code testen oder Funktionen entwickeln möchten, während Ihre Produktionsdatenbank auf eine neuere Version aktualisiert wird.

Darüber hinaus haben Sie für jede Version zwei Optionen für das Code-Update.

• Sie können wählen, ob Sie automatisch von den neuesten Fehler-, Sicherheits- und Leistungsverbesserungen profitieren möchten. Die Quellen Ihres Odoo-Servers werden wöchentlich aktualisiert. Dies ist die Option „Neueste“.

• Sie können die Odoo-Quellen an eine bestimmte Revision anheften, indem Sie sie aus einer Liste von Daten auswählen. Revisionen laufen nach 3 Monaten ab. Sie werden per E-Mail benachrichtigt, wenn das Verfallsdatum näher rückt. Wenn Sie danach nichts unternehmen, werden Sie automatisch auf die neueste Revision gesetzt.

Benutzerdefinierte Domains

Hier können Sie zusätzliche Domains für den ausgewählten Zweig konfigurieren. Es ist möglich, andere <name>.odoo.com-Domains oder Ihre eigenen benutzerdefinierten Domains hinzuzufügen. Für Letzteres müssen Sie:

• den Domainnamen besitzen oder kaufen,

• den Domainnamen in dieser Liste hinzufügen,

• im Domainnamen-Manager Ihres Registers den Domainnamen mit einem CNAME-Datensatz konfigurieren, der auf den Domainnamen Ihrer Produktionsdatenbank eingestellt ist.

Zum Beispiel, um www.mycompany.com mit Ihrer Datenbank mycompany.odoo.com zu verknüpfen:

• fügen Sie in Odoo.sh www.mycompany.com in den benutzerdefinierten Domains Ihrer Projekteinstellungen hinzu.

• konfigurieren Sie in Ihrem Domainnamen-Manager (z. B. godaddy.com, gandi.net, ovh.com) www.mycompany.com mit einem CNAME-Datensatz mit dem Wert mycompany.odoo.com.

Reine Domains (z. B. mycompany.com) werden nicht akzeptiert:

• Sie können nur über A-Datensätze konfiguriert werden,

• A-Datensätze akzeptieren IP-Adressen nur als Wert,

• die IP-Adresse Ihrer Datenbank kann sich ändern, z. B. nach einem Upgrade, einem Hardwareausfall oder wenn Sie Ihre Datenbank in einem anderen Land oder auf einem anderen Kontinent hosten möchten.

Reine Domains könnten also aufgrund dieser Änderung der IP-Adresse plötzlich nicht mehr funktionieren.

Wenn Sie außerdem möchten, dass sowohl mycompany.com als auch www.mycompany.com mit Ihrer Datenbank zusammenarbeiten, gehört die Umleitung von mycompany.com auf www.mycompany.com zu den bewährten Verfahren für SEO (siehe Verwende für jedes Dokument nur eine URL-Version), um eine dominante URL zu haben. Sie können also einfach mycompany.com so konfigurieren, dass sie auf www.mycompany.com umgeleitet wird. Die meisten Domain-Manager verfügen über die Möglichkeit, diese Umleitung zu konfigurieren. Dies wird gemeinhin als Webumleitung bezeichnet.

HTTPS/SSL

Wenn die Umleitung korrekt eingerichtet ist, generiert die Plattform innerhalb einer Stunde automatisch ein SSL-Zertifikat mit Let’s Encrypt und Ihre Domain wird über HTTPS erreichbar sein.

Obwohl es derzeit nicht möglich ist, Ihre eigenen SSL-Zertifikate auf der Odoo.sh-Plattform zu konfigurieren, ziehen wir diese Funktion in Betracht, wenn genügend Nachfrage besteht.

SPF und DKIM-Konformität

Falls die Domain Ihrer Benutzer-E-Mail-Adressen SPF (Sender Policy Framework) oder DKIM (DomainKeys Identified Mail) verwendet, vergessen Sie nicht, Odoo in Ihren Domaineinstellungen als sendenden Host zu autorisieren, um die Zustellbarkeit Ihrer ausgehenden E-Mails zu erhöhen. Die Konfigurationsschritte werden in der Dokumentation zu SPF und DKIM erläutert.

Shell-Befehle¶

In der rechten oberen Ecke der Ansicht sind verschiedene Shell-Befehle verfügbar.

Jeder Befehl kann in die Zwischenablage kopiert werden, damit er in einem Terminal verwendet werden kann, und einige davon können direkt aus Odoo.sh verwendet werden, indem Sie auf die Schaltfläche Ausführen klicken. In diesem Fall wird der Benutzer in einem Pop-up aufgefordert, eventuelle Platzhalter wie <URL>, <PATH> … anzugeben.

Klonen¶

Laden Sie das Git-Repository herunter.

$ git clone --recurse-submodules --branch master git@github.com:odoo/odoo.git

Klont das Repository odoo/odoo.

• --recurse-submodules: Lädt die Untermodule Ihres Repositorys herunter. Untermodule, die in Untermodulen enthalten sind, werden ebenfalls heruntergeladen.

• --branch: Prüft einen bestimmten Zweig des Repositorys, in diesem Fall Master.

Die Schaltfläche Ausführen ist für diesen Befehl nicht verfügbar, da er für die Verwendung auf Ihren Rechnern gedacht ist.

Fork¶

Erstellen Sie einen neuen Zweig auf der Grundlage des aktuellen Zweigs.

$ git checkout -b feature-1 master

Erstellt einen neuen Zweig namens feature-1 auf der Grundlage des Zweigs master und prüft ihn dann.

$ git push -u origin feature-1

Lädt den neuen Zweig Feature-1 in Ihr Remote-Repository hoch.

Zusammenführen¶

Führen Sie den aktuellen Zweig in einem anderen Zweig zusammen.

$ git merge staging-1

Führt den Zweig staging-1 im aktuellen Zweig zusammen.

$ git push -u origin master

Lädt die Änderungen, die Sie soeben im master-Zweig hinzugefügt haben, in Ihr Remote-Repository hoch.

SSH¶

Einrichtung¶

Um SSH verwenden zu können, müssen Sie den öffentlichen SSH-Schlüssel Ihres Profils einrichten (falls dies noch nicht geschehen ist). Führen Sie dazu die folgenden Schritte aus:

1. Generate a new SSH key (Einen neuen SSH-Schlüssel generieren)

2. Copy the SSH key to your clipboard (Den SSH-Schlüssel in Ihre Zwischenablage kopieren) (nur den 1. Schritt anwenden)

3. Den kopierten Inhalt Ihrer Profil-SSH-Schlüssel einfügen und „Add“ (Hinzufügen) drücken.

   

4. Der Schlüssel sollte darunter erscheinen.

   

Verbindung¶

Um sich über ssh mit Ihren Builds zu verbinden, verwenden Sie den folgenden Befehl in einem Terminal:

$ ssh <build_id>@<domain>

Eine Abkürzung für diesen Befehl finden Sie im Reiter SSH in der oberen rechten Ecke.

Vorausgesetzt, Sie haben die richtigen Zugriffsrechte auf das Projekt, erhalten Sie SSH-Zugriff auf den Build.

Untermodul¶

Fügen Sie einen Zweig aus einem anderen Repository als Untermodul in Ihren aktuellen Zweig ein.

Mit Untermodulen können Sie Module aus anderen Repositorys in Ihrem Projekt verwenden.

Die Funktion Untermodule wird im Kapitel Untermodule dieser Dokumentation ausführlich beschrieben.

$ git submodule add -b master <URL> <PATH>

Fügt den Zweig master des Repositorys <URL> als Untermodul unter dem Pfad <PATH> in Ihrem aktuellen Zweig hinzu.

$ git commit -a

Setzte alle Ihre aktuellen Änderungen fest.

$ git push -u origin master

Lädt die Änderungen, die Sie soeben im master-Zweig hinzugefügt haben, in Ihr Remote-Repository hoch.

Löschen¶

Löschen Sie einen Zweig aus Ihrem Repository.

$ git push origin :master

Löscht den Zweig in Ihrem Remote-Repository.

$ git branch -D master

Löscht den Zweig in Ihrer lokalen Kopie des Repositorys.