Push-Commits und Veröffentlichung eines Branchs

• Überprüfen Sie Quelle und Ziel vor dem Push.
• Schneller Vorlauf eines Nur-Behind-Zweigs ohne Merge-Commit.
• Veröffentlichen Sie ein benanntes Feature und überprüfen Sie dessen Upstream.
• Unterscheiden Sie zwischen Ablehnung und verlorener Arbeit.

Beginnen Sie dort, wo Lektion 11 endete: Haupt-/H6 ausgecheckt, Ursprungs-/Haupt-/Server-H7 mit Leos Fußzeile, bereinigt, Haupt sechs gegenüber abgerufenen sieben Commits und 0/1. Feature F1 existiert nur lokal ohne Upstream.

Das Video wurde mit Git 2.52.0 und GitTree 2.0 auf Ubuntu 24.04 aufgenommen: Der Vorlauf, die Pushs und der Upstream wurden in der App durchgeführt; Die Vorher-Nachher-Kontrollen und der verweigerte Push liefen im Terminal. Auf macOS oder Windows wurde nichts ausgeführt, und Ubuntu ist das einzige aufgezeichnete Linux-System. Die Quell-Git-Ebene von GitTree ist 2.39.0.

GitTree fordert Sie auf, sich anzumelden; Der Free-Plan deckt hier dann jeden Schritt ab. Es ist kein Anbieterkonto, Pro-/Testversion, API-Anmeldeinformationen oder Internetdienst erforderlich. Ein lokaler nackter Ursprung ist nicht GitLab oder CI. Alle Identitäten verwenden example.com; Führen Sie diese Lektion niemals innerhalb einer Quellprüfung durch.

Nehmen Sie Mutationen entweder über GitTree oder den nativen Pfad an identischen Eingaben vor, nicht beide nacheinander. In beiden Fällen kann eine schreibgeschützte Überprüfung erfolgen. Jede als Terminalarbeit beschriebene Vorbereitung wird als native Vorbereitung bezeichnet und niemals als erfundene App-Funktion.

Push schlägt Aktualisierungen für ausgewählte Remote-Referenzen vor. Es handelt sich nicht um eine Sicherung jeder Datei, jedes nicht verfolgten Puffers oder Zweigs. Ein Ziel kann eine Aktualisierung auch dann ablehnen, wenn eine Netzwerkverbindung funktioniert.

Der eingehende H7 stammt von Haupt-/H6 ab. Ein schneller Vorlauf kann main zu diesem Nachkommen verschieben, ohne einen Merge-Commit zu erfinden. Diese eng gefasste Abstammungsoperation wird hier vorgestellt; Divergente Integration gehört zu späteren Lektionen des Kurses.

Durch das Veröffentlichen von Feature-/Preiskarten wird F1 an einen neuen Serverzweig gesendet. In GitTree wählt dieser Push nicht den Upstream aus: Sie legen ihn anschließend in derselben Zweigzeile fest. Es wechselt weder den aktuellen Zweig noch führt es seine Workflowkarten in den Hauptzweig ein. Ein erfolgreicher No-Op-Main-Push ist kein neuer Server-Commit.

Der explizite Schnellvorlauf ändert main/HEAD, index und work auf H7. Push ändert nach Erfolg nur die ausgewählte Serverreferenz und die lokale Nachverfolgung/Konfiguration; Nicht bereitgestellter Text wird nicht gespeichert. Remote Main muss Leos Commit beibehalten.

Verwenden Sie nach Lektion 11 das Original und holen Sie es im Hintergrund ab, um eine stabile Vorschau zu erhalten. Es wird keine neue Dateinutzlast oder kein neues Notebook hinzugefügt. Die absichtliche Zurückweisung hinter dem Hauptteil ist eine separate native Aufnahme und keine Anweisung zum Klicken auf die App „Force-Push“.

Palette: Befehl+Umschalt+P (Strg+Umschalt+P bei Ubuntu); Geben Sie den genau benannten Befehl ein und wählen Sie ihn aus. Benannte Ref-Aktionen verwenden das Kontextmenü dieser Zeile und keine argumentfreie Palettenverknüpfung.

1. Überprüfen Sie auf der Hauptseite die tatsächliche Quelle/das tatsächliche Ziel und die 0/1-Zählungen. Schieben Sie im kanonischen Take nicht zuerst den älteren Main.
2. Klicken Sie in der Remote-Gruppe des Seitenbereichs mit der rechten Maustaste auf origin/main → Merge origin/main into main. Wählen Sie in Record it as Fast-forward only und dann Merge. Erwarten Sie die Hauptlinie bei H7 mit Leos Fußzeile, einem übergeordneten Element und einer geraden Linie im Diagramm.
3. Führen Sie die folgenden Abstammungs-/Clean-Readbacks aus. Wenn der Hauptwert abweicht, brechen Sie ab, anstatt einen Neuschreibmodus auszuwählen.
4. Klicken Sie im Hauptmenü auf die Symbolleiste Push. Der Hinweis lautet „Alles war bereits auf dem neuesten Stand.“: Dies ist kein neuer Commit.
5. Öffnen Sie unter „Lokal“ den Ordner feature und klicken Sie mit der rechten Maustaste auf pricing-cards → Push feature/pricing-cards. Bei einer Fernbedienung gibt es keinen Dialog: Der Hinweis lautet „Funktions-/Preiskarten an Ursprungs-/Funktions-/Preiskarten weitergeleitet.“
6. Der Push hat keinen Upstream gesetzt (der Zweig hatte keinen). Klicken Sie mit der rechten Maustaste auf dieselbe Zeile → Upstream → Set Upstream…, wählen Sie in What should feature/pricing-cards track? origin/feature/pricing-cards und dann Track. Überprüfen Sie die Serverfunktion F1 und den Upstream.
7. Wählen Sie Haupt- und Feature-Graph-Beschriftungen ohne Auschecken aus; Bestätigen Sie, dass es sich weiterhin um unterschiedliche Tipps handelt und dass keine Zusammenführung erfolgt ist.
8. Lassen Sie den Hauptserver ausgecheckt, sauber und beide benannten Serverzweige überprüft. Wählen Sie nicht „Force Push…“ und veröffentlichen Sie nicht jede Referenz.

Für jeden gewöhnlichen Commit: Zusammenfassung ist der angegebene Betreff; Beschreibung leer; Vorheriges Commit ändern, Hooks überspringen, „Signiert von“ und „Anderer Autor“ hinzufügen, „Nach Commit verschieben“ und „Leeres Commit deaktivieren“ zulassen; keine Co-Autoren. Stellen Sie nur die benannten Dateien bereit und übernehmen Sie dann die Änderungen einmal in N Dateien (Datei für eine) oder alternativ Befehl+Eingabetaste. Warten Sie auf das tatsächliche Ergebnis. Eine Lektion, die explizit Änderungen vornimmt, ändert nur die angegebene Option.

Aus der Originaldemo, native Alternative:

git rev-list --left-right --count main...origin/main
git merge --ff-only --quiet origin/main
git push --quiet origin main
git push --quiet --set-upstream origin feature/pricing-cards
git rev-list --left-right --count main...origin/main
git rev-parse --abbrev-ref 'feature/pricing-cards@{upstream}'
git symbolic-ref --short HEAD
git status --short

Erste Zählung0/1; Schnellvorlauf und Leise drücken den Ausgang 0. Die letzten Rücklesevorgänge werden in der folgenden Reihenfolge ausgegeben:

0	0
origin/feature/pricing-cards
main

Der Status ist still. Vergleichen Sie Server/lokale Haupt- und Feature-SHAs unabhängig voneinander mit git ls-remote --heads origin; Variablen-IDs müssen mit den vorgesehenen lokalen Tipps übereinstimmen. Separate Pre-Fast-Forward-Negativaufnahme: git push --quiet origin mainexited1 mit dem eigentlichen Diagnoseauszug:

 ! [rejected]        main -> main (non-fast-forward)

Die vollständige Diagnose nennt die gemessene lokale Datei-URL und Git-Hinweise. Bei dieser Ablehnung hat sich kein Fernreferent geändert; Fälschen Sie die URL nicht und reparieren Sie sie nicht mit Gewalt.

Where you end: Haupt-Schnellvorlauf zu H7 und immer noch ausgecheckt/bereinigt; Der Hauptserver bleibt H7. Feature F1 wird jetzt als Origin/Feature/Pricing-Cards veröffentlicht und verfolgt; main und feature wurden nicht zusammengeführt.

• Veröffentlichen Sie das aktuelle Hauptelement, wenn Sie das benannte Feature meinten.
• Eine Weigerung, die nur hinterherhinkt, als Erlaubnis zu behandeln, Leo zu überschreiben.
• Angenommen, das Push-Set hat den Upstream der Funktion festgelegt oder die Einstellung hat irgendetwas zusammengeführt: Die App benötigt den separaten Schritt „Upstream festlegen…“.

Rufen Sie nach der Ablehnung die Abstammung/das Ziel ab und überprüfen Sie sie, bevor Sie es erneut versuchen. Für diese exakte Hinterher-Eingabe verwenden Sie den expliziten Schnellvorlauf. Für einen Remote-Push gibt es kein generisches App-Rückgängigmachen; eine eventuelle spätere Fernkorrektur koordinieren.

Beantworten Sie jede Frage und lesen Sie dann, warum. Mit „erforderlich“ gekennzeichnete Fragen zählen zum Abschluss der Lektion.

1. Frage 1 von 6

   Frage 1 von 6

   Was bewirkt die Veröffentlichung von F1?

   Wählen Sie eine Antwort.

   Erstellt den ausgewählten Remote-Zweig

   Speichert nicht verfolgte Puffer

   Führt F1 mit main zusammen

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Welche Fakten gelten nach dem kanonischen Erfolg?

   Wählen Sie jede zutreffende Antwort aus.

   Die Funktion verfügt über einen eigenen Upstream

   HEAD wurde automatisch auf die Funktion umgeschaltet

   Main bleibt H7

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   Schneller Vorlauf von Haupt/H6 zu Nachkomme H7: neues Merge-Commit?

   Wählen Sie eine Antwort.

   F1 verschwindet

   Ja, zwei Eltern

   Nein

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6Erforderlich

   Eingabe ändern: Altes H6 vor der Ausrichtung über Server H7 schieben.

   Wählen Sie eine Antwort.

   Ohne Gewalt abgelehnt

   Server spult sicher zurück

   Der Kurs erfordert Kraft

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6

   Push sagt schon aktuell. Wird F1 veröffentlicht?

   Wählen Sie eine Antwort.

   Nur wenn die benannte Serverreferenz überprüft wird

   Niemals

   Immer

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Welche endgültigen Beweise werden benötigt?

   Wählen Sie jede zutreffende Antwort aus.

   Funktionieren Sie vorgelagert und reinigen Sie die Hauptkasse

   Allein ein grüner Knopf

   Passende Server-/lokale Tipps

   Antwort prüfen

Beweisen Sie die Gleichheit von Haupt-/Server-H7, Gleichheit von Feature/Server-F1, Feature-Upstream, unveränderten Haupt-Checkout und sauberen Status. In einer separaten Alt-Hauptkopie können Sie die Ablehnung vorhersagen und beobachten, ohne H7 zu verlieren.

• Überprüfen Sie das genaue Ziel.
• Integrieren Sie einen reinen Nachkommen explizit.
• Veröffentlichen Sie einen Zweig, ohne ihn zusammenzuführen.

• Die Änderung eines Teamkollegen abrufen, ohne Ihre Seite zu ersetzen (Lektion 11)
• Verbinden Sie eine Fernbedienung, ohne sie mit einem Upstream zu verwechseln (Lektion 10)
• Laden Sie GitTree herunter

Drücken – دفع; Zweig veröffentlichen – نشر فرع; stromaufwärts – الفرع المتتبَّع; Schnellvorlauf – تقديم سريع.