GitHub vom Anfänger zum Profi: Ein umfassender Leitfaden

Wenn du mit GitHub Geld verdienen willst, ist der direkteste Weg nicht kompliziert: Finde unter der Voraussetzung der Lizenzgenehmigung wertvolle Open-Source-Projekte, mache Deployment, deutsche Dokumentation und After-Sales zu einem Service und verkaufe die Auslieferung auf Plattformen wie Xianyu.

Was wirklich Geld bringt, ist die Fähigkeit zur Informationsfilterung und Umsetzung. Wenn du im KI-Bereich arbeiten, zu einem FDE (Full-Stack-Entwickler) wechseln oder dich in ein OPC (One Person Company) verwandeln möchtest, landen Code, Dokumentation, Versionen und Zusammenarbeit letztendlich auf GitHub.

Selbst wenn du kreativ arbeitest oder Inhalte erstellst, gibt es auf GitHub eine große Anzahl von Themenauswahl-Tools, Automatisierungsprojekten und Content-Produktionsprozessen. Sobald die Dateien zunehmen und KI Änderungen vornimmt, gerät ohne Git zur Versionsverwaltung schnell alles außer Kontrolle. Daher müssen Programmierer es lernen, aber auch Projektmanager und Content-Ersteller; es bestimmt, ob du eine Idee in ein verwaltbares, wiederverwendbares und auslieferbares Projekt verwandeln kannst.

Ich habe über einen halben Monat damit verbracht, diesen Artikel zu verfeinern und Git, GitHub, Commits, Branches, PRs und häufige Fehler von 0 auf 1 durchzugehen. Zukünftige Live-Übertragungen werden demselben Prozess folgen. Vor der offiziellen Übertragung mache ich dieses Tutorial zuerst als Open Source verfügbar. Du kannst es mit einem Lesezeichen versehen oder komplett durcharbeiten.

1. Git und GitHub: Wer verwaltet was?

Git ist ein Versionsverwaltungstool, das auf deinem Computer installiert ist. Im Offline-Modus kannst du trotzdem committen, den Verlauf ansehen, Branches erstellen und mergen. GitHub ist eine Remote-Repository- und Kollaborationsplattform; sie empfängt von Git gepushte Commits und bietet Issues, Pull Requests, Actions, Code-Reviews und Berechtigungsverwaltung.

Das am leichtesten zu Verwechselnde bei Git ist, dass dieselbe Änderung an vier verschiedenen Orten existieren kann. Die folgende Infografik unterteilt den Arbeitsbereich, die Staging-Area, das lokale Repository und das Remote-Repository in vier Ebenen.

Das Drücken von Speichern schreibt den Inhalt nur auf die Festplatte. git add ist für das Auswählen zuständig, git commit hinterlässt eine Version lokal, und git push sendet diese Commits an GitHub.

Überprüfe also vor dem Commit den Diff, führe ihn aus oder teste ihn; nach erfolgreichem Push gehst du zurück zur Webseite und überprüfst es noch einmal. So weißt du bei einem Problem sofort, auf welcher Ebene es gestoppt hat.

2. Bevor du anfängst: Bereite nur vier Dinge vor

Du benötigst Git, ein GitHub-Konto, einen Editor und ein Übungsprojekt. VS Code reicht als Editor aus, und das Projekt kann eine Webseite oder ein Markdown-Dokument sein.

Bestätige zuerst Git im Terminal:

1git --version

Diese Übung verwendet macOS und Git 2.49.0. Windows-Benutzer können Git Bash oder das integrierte Terminal von VS Code verwenden; die folgenden Git-Befehle sind identisch.

Als nächstes konfiguriere den Commit-Autor:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

Dies sind die Autoreninformationen, die in den Commit-Eintrag geschrieben werden; sie sind nicht für die Anmeldung bei GitHub zuständig. Wenn du es nur für das aktuelle Übungsprojekt konfigurieren möchtest, ersetze --global durch --local.

Der GitHub-Login ist eine separate Angelegenheit. Die Befehlszeile verwendet üblicherweise drei Methoden:

• GitHub CLI, Autorisierung über den Browser mit gh auth login;
• HTTPS, Verwendung eines Personal Access Token oder eines Credential Managers;
• SSH, Hinzufügen eines öffentlichen Schlüssels zu GitHub und spätere Authentifizierung über den Schlüssel.

Anfänger können GitHub CLI oder HTTPS wählen. Bei HTTPS, wenn das Terminal nach einem Passwort fragt, gib den Token ein; normale Kontopasswörter sind nicht mehr gültig. Schreibe den Token nicht in Befehle, Remote-URLs, READMEs, Chats oder Screenshots.

3. Keine Eile mit init: Bestätige zuerst, wo sich das Terminal tatsächlich befindet

Diese Übung beginnt mit einer einfachen Webseite. Sie kann im Browser geöffnet werden, hat aber noch keine Git-Historie.

Es gibt drei Dateien im Projekt:

1index.html
2style.css
3.gitignore

Wähle in VS Code "Ordner öffnen" aus, klicke nicht nur auf eine einzelne HTML-Datei. Führe dann im integrierten Terminal aus:

1pwd
2ls

pwd zeigt das aktuelle Verzeichnis an, und ls listet Dateien auf. Fahre erst fort, nachdem du index.html und style.css siehst.

Diese Überprüfung wirkt albern, verhindert aber die lästigste Art von Unfall: Jemand führt git init auf dem Desktop, in Dokumenten oder sogar im Benutzerverzeichnis aus und führt dann git add . aus, wodurch Tausende irrelevanter Dateien in die Staging-Area gelangen. Git ist nicht kaputt; das Verzeichnis war falsch.

4. Was macht git init?

Initialisiere nun das Repository:

1git init -b main
2git status --short

git init -b main erstellt ein .git-Verzeichnis im aktuellen Ordner und benennt den anfänglichen Branch main. .git ist ein verstecktes Verzeichnis, in dem Informationen wie Commits, Branches, Staging-Areas und Remote-Adressen gespeichert werden. Die Projektdateien bleiben an Ort und Stelle; Git beginnt ab diesem Moment, sie zu beobachten.

Das ?? im Screenshot zeigt nicht verfolgte Dateien an. Die Dateien existieren, aber Git hat noch nicht entschieden, ob es sie aufzeichnen soll.

Um das Stammverzeichnis des Repositorys zu bestätigen, kannst du Folgendes ausführen:

1git rev-parse --show-toplevel

Die Ausgabe sollte der aktuelle Projektordner sein. Wenn fatal: not a git repository angezeigt wird, überprüfe zuerst das Verzeichnis und dann, ob git init ausgeführt wurde.

5. Der erste Commit: Behalte einen zuverlässigen Startpunkt

Das Projekt wurde noch nicht geändert, warum also zuerst committen? Weil alle nachfolgenden Änderungen einen vergleichbaren Startpunkt benötigen. Öffne zuerst die Webseite in einem Browser, um zu bestätigen, dass der Titel, die Karten und der Registrierungsbereich angezeigt werden; verkleinere das Fenster, um zu sehen, ob es bei mobiler Breite horizontales Scrollen gibt.

Sieh dir dann .gitignore an. Der diesmal verwendete Inhalt ist:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore dient dazu, Schlüssel, Logs, Abhängigkeiten und Build-Artefakte auszuschließen. Es wirkt hauptsächlich auf Dateien, die noch nicht verfolgt werden. Wenn ein Schlüssel bereits committed wurde und du ihn später zu .gitignore hinzufügst, existiert dieser Verlauf immer noch; die eigentliche Handhabung umfasst auch das Widerrufen oder Rotieren des Schlüssels.

Beginne mit dem Auswählen von Dateien für den ersten Commit:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

Das A im Status steht für Added (Hinzugefügt) und zeigt an, dass die Datei in die Staging-Area gelangt ist. git diff --cached --stat sagt dir, wie viele Dateien du für den Commit vorbereitest und ungefähr wie viele Zeilen geändert wurden. Um den spezifischen Inhalt zu sehen, führe Folgendes aus:

1git diff --cached

Commite nach der Bestätigung:

1git commit -m "chore: Initialize campus AI recruitment page"
2git log --oneline
3git status

Ein Commit kann als Projektschnappschuss mit Autor, Zeit, Beschreibung und übergeordnetem Commit verstanden werden. ffdf4ff ist die Kurzversion dieses Commit-Hashs; die Verwendung im aktuellen Repository kann die Version genau lokalisieren.

feat, fix, docs, style, chore sind übliche Commit-Typen, keine zwingende Git-Syntax. Wichtiger als das Präfix ist die darauf folgende Beschreibung: was getan wurde, welches Objekt geändert wurde und warum.

6. Der zweite Commit: Behandle KI-Änderungen als Entwürfe zur Überprüfung

Als nächstes füge der Seite einen Button "Registrierungsmethode anzeigen" hinzu. Wenn ich KI-Programmiertools verwende, schreibe ich Grenzen in den Prompt:

1Only modify index.html, add a "View Registration Method" link below the introduction text,
2linking to #apply within the page. Do not modify style.css, do not execute Git commits.
3Tell me which file was modified when finished.

Manuelle Änderung ist auch einfach:

1<a class="cta" href="#apply">View Registration Method</a>

Die KI sagt, es sei fertig, aber commite noch nicht. Führe Folgendes aus:

1git status --short
2git diff -- index.html
3git diff --check

git diff zeigt Änderungen im Arbeitsbereich an, die noch nicht gestaged wurden. Grünes + ist eine hinzugefügte Zeile, rotes - ist eine gelöschte Zeile. git diff --check hat keine Ausgabe, was darauf hindeutet, dass keine offensichtlichen Formatierungsprobleme wie nachgestellte Leerzeichen gefunden wurden; es wird nicht für dich überprüfen, ob der Button anklickbar ist.

Gehe zurück zum Browser und aktualisiere, klicke auf den Button und verkleinere dann das Fenster. Die Seite sollte zum Registrierungsbereich scrollen, und der Button und die Karten sollten auf schmalen Bildschirmen immer noch normal sein.

Commite erst, nachdem der Test bestanden ist:

1git add index.html
2git diff --cached
3git commit -m "feat: Add registration entry for quick viewing of application methods"
4git log --oneline -2

An diesem Punkt gibt es zwei klare Versionen im Repository: die Startseite und den Registrierungsbutton. Wenn der Button später Probleme hat, kannst du direkt den Commit finden, der ihn hinzugefügt hat.

Übrigens, unterscheide die beiden Diffs:

1git diff             # Unterschied zwischen Arbeitsbereich und Staging-Area
2git diff --cached    # Unterschied zwischen Staging-Area und dem letzten Commit

Wenn git diff keine Ausgabe hat, wurde die Datei möglicherweise nicht gespeichert oder bereits gestaged oder committed. Das sequenzielle Überprüfen von git status, git diff --cached und git log ist zuverlässiger, als wiederholt git add . einzugeben.

7. Branches: Hinterlasse einen Testplatz für unsichere Änderungen

Der Button fügt nur eine Zeile hinzu, das Risiko ist also gering. Das gesamte Theme von Lila auf Orange zu ändern, könnte gut aussehen oder geschmacklos wirken; diese Art von Änderung eignet sich für einen Branch.

1git switch -c experiment/warm-theme
2git branch --show-current

Ein Branch ist konzeptionell ein Name, der auf einen bestimmten Commit zeigt. Wenn ein neuer Branch zum ersten Mal erstellt wird, zeigt er auf denselben Commit wie main, daher sind die Dateien exakt gleich. Erst wenn der experimentelle Branch neue Commits generiert, divergieren die beiden Linien.

Im Diagramm zeigt das blaue main immer noch auf den zweiten Commit, während das orange experiment bereits auf den dritten Commit zeigt. Das Projekt hat nicht zwei Dateisätze dupliziert; nur die Zeiger für die beiden Branchnamen haben sich geändert.

Ändere die Farbvariablen in style.css, aktualisiere die Seite zur Bestätigung und commite dann:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Try warm theme in experimental branch"
5git log --oneline --graph --decorate --all

HEAD zeigt an, wo du dich gerade befindest. Im Screenshot zeigt HEAD auf experiment/warm-theme, während main beim Button-Commit bleibt.

Entscheide dich, das warme Theme zu behalten, wechsle zurück zu main und merge:

1git switch main
2git merge experiment/warm-theme

Hier tritt ein Fast-Forward auf, weil main während des Experiments keine neuen Commits hatte. Git bewegt den main-Zeiger direkt zum warmen Theme-Commit; die Änderungen wurden erfolgreich gemergt.

Gemergte Branches können sicher gelöscht werden:

1git branch -d experiment/warm-theme

Kleines -d überprüft, ob der Branch gemergt wurde. Großes -D löscht erzwungenermaßen, und Commits im Branch, die nicht gemergt wurden, könnten ihre Referenzen verlieren; verwende es nicht als täglichen Bereinigungsbefehl.

8. Konflikte sind nicht mysteriös; Git wagt es nur nicht, für dich zu wählen

Um Konflikte zu überprüfen, habe ich das Repository dupliziert. main änderte den Haupttitel in "Lass Campus-Kreativität von mehr Menschen gesehen werden", und der feature-Branch änderte dieselbe Zeile in "Verwandle eine Idee in ein wirklich nutzbares Werk". Git stoppte während des Merges:

Konfliktmarkierungen sind in drei Teile unterteilt:

1<<<<<<< HEAD
2Inhalt des aktuellen Branches
3=======
4Inhalt des zu mergenden Branches
5>>>>>>> feature/rewrite-heading

Die Behandlungsmethode besteht darin, die Datei zu bearbeiten, den endgültig gewünschten Text zu hinterlassen, die drei Markierungssätze zu löschen, zu testen und dann Folgendes auszuführen:

1git add index.html
2git commit

Wenn du es zu diesem Zeitpunkt nicht bearbeiten möchtest, kannst du den Merge abbrechen:

1git merge --abort

Ein Konflikt bedeutet, dass zwei Personen oder zwei Agents für dieselbe Stelle unterschiedliche Antworten gegeben haben und Git nicht selbst wählen kann.

9. Senden des lokalen Repositorys an GitHub

Das Projekt hat bereits eine lokale Historie; gehe jetzt zu GitHub, um ein Repository zu erstellen. Klicke auf das + in der oberen rechten Ecke, wähle "New repository" und fülle den Repository-Namen aus, zum Beispiel:

1campus-ai-demo

Für die erste Übung wird empfohlen, es auf Private zu setzen. Da lokal bereits eine README, .gitignore und Commit-Historie vorhanden sind, halte das neue GitHub-Repository leer; initialisiere auf der Webseite keine README, Lizenz oder .gitignore. Andernfalls haben lokal und remote jeweils ein Stück anfänglicher Historie, und der erste Push erfordert die Handhabung der Beziehung zwischen den beiden Seiten. Die offizielle GitHub-Anleitung "Adding locally hosted code" erinnert ebenfalls ausdrücklich daran.

Kopiere die HTTPS-Adresse:

1https://github.com/YourUsername/campus-ai-demo.git

Kehre zum Projektterminal zurück:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin ist ein Alias für die Remote-Adresse; es kann mit anderen Namen funktionieren, aber die Community nennt das Haupt-Remote üblicherweise origin. -u stellt eine Tracking-Beziehung zwischen lokalem main und origin/main her; nachfolgende Operationen führen normalerweise nur git push aus.

Das folgende Terminaldiagramm verwendete ein lokales Bare-Repository, um Push und Clone durchzuführen, daher wurde das vorhandene GitHub-Konto nicht geändert. Beim Wechsel zu GitHub ersetze einfach die Origin-URL; die Logik für Git zum Übergeben von Commits und Herstellen von Tracking-Beziehungen ist dieselbe.

Nachdem der eigentliche Push abgeschlossen ist, gehe zurück zur GitHub-Webseite und aktualisiere, um zu bestätigen, dass Dateien, README, Standard-Branch und Commit-Historie alle sichtbar sind. Die Erfolgsmeldung im Terminal ist eine Beweisebene, die Web-Überprüfung eine andere.

10. Ein GitHub-Repository zum ersten Mal lesen: Wie man diese Dinge auf der Seite liest

Unten ist die echte Seite des offiziellen GitHub-Dokumentations-Repositorys, Screenshot vom 15. August 2026.

Wenn du ein Repository öffnest, sieh dir zuerst diese Stellen an:

• Code: Dateien, Verzeichnisse, Branches und Commits;
• Issues: Fehler, Anforderungen, Aufgaben und Diskussionen;
• Pull requests: Änderungen, die auf Überprüfung oder Merge warten;
• Actions: Automatisierte Tests, Builds und Deployments;
• Security: Sicherheitsrichtlinien und sicherheitsrelevante Funktionen;
• Insights: Beiträge, Traffic und Repository-Aktivität;
• README: Projektvorstellung und Nutzungseinstieg;
• LICENSE: Wie es verwendet, modifiziert und verteilt werden darf.

Wenn du ein unbekanntes Projekt liest, starre nicht zuerst auf die Stars. Beantworte zuerst fünf Fragen: Welches Problem löst es, wie läuft es, wovon hängt es ab, wird es kürzlich gewartet und was erlaubt mir die Lizenz zu tun. Stars spiegeln Aufmerksamkeit wider; sie überprüfen nicht Sicherheit, Kompatibilität oder Autorisierung für dich.

11. clone, fetch, pull, push: Verwechsle die vier Richtungen nicht

Ein Remote-Repository zum ersten Mal auf deinen Computer holen:

1git clone https://github.com/OWNER/REPO.git

Clone bringt Dateien, Commit-Historie und Remote-Konfigurationen zurück und benennt das Remote normalerweise automatisch origin. Das Herunterladen eines ZIPs gibt nur einen Schnappschuss der Dateien zu diesem Zeitpunkt, ohne vollständige Historie, und stellt keine Remote-Beziehung her.

Die drei danach häufig verwendeten Aktionen sind:

1git fetch origin   # Remote-Informationen herunterladen, ändert aktuelle Arbeitsdateien nicht
2git pull           # fetch und dann in den aktuellen Branch integrieren
3git push           # Lokale Commits an das Remote senden

Um zuerst zu sehen, was remote passiert ist, kannst du Folgendes tun:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Wenn du bestätigst, dass lokal keine Abweichung vorliegt und du nur Fast-Forward-Updates akzeptieren möchtest:

1git pull --ff-only

pull wird zuerst fetch ausführen und dann basierend auf der Konfiguration merge oder rebase durchführen. Teams sollten sich vor der ersten Zusammenarbeit auf die Integrationsmethode einigen und sich nicht auf force push verlassen, um Probleme bei Abweichungen zu glätten.

12. Vom persönlichen Repository zur GitHub-Zusammenarbeit

Ein Pull Request ist ein Merge-Vorschlag und der Ort, an dem die Zusammenarbeit stattfindet. Diskussionen, Code-Reviews und automatisierte Überprüfungen drehen sich alle um denselben Satz von Änderungen, und er wird erst nach Bestätigung in main gemergt.

Angenommen, das Issue lautet "Ereigniszeitbeschreibung hinzufügen", können lokale Operationen so durchgeführt werden:

1git switch -c feat/event-time
2# Seite ändern und testen
3git add index.html
4git commit -m "feat: Add event time description"
5git push -u origin feat/event-time

Nach dem Push fordert GitHub normalerweise zur Erstellung eines Pull Requests auf. Ein PR ist ein Merge-Vorschlag, der Beschreibungen, Commits, Dateiunterschiede, Kommentare, Reviews und automatisierte Überprüfungen anzeigt. Es wird nicht automatisch in main gelangen, nur weil es erstellt wurde.

Ein PR, den Leute bereit sind zu reviewen, sollte mindestens drei Dinge erklären: was geändert wurde, warum es geändert wurde und wie es zu überprüfen ist. Je fokussierter die Änderungen, desto einfacher ist es für Reviewer, Probleme zu erkennen.

Im selben Team, wenn du Schreibzugriff auf das Repository hast, kannst du einen PR direkt von einem Branch senden. Wenn du zu einem unbekannten Open-Source-Projekt beiträgst, ist die übliche Vorgehensweise, es zuerst auf dein eigenes Konto zu forken und dann deinen eigenen Fork zu klonen:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

Hier gibt es normalerweise zwei Remotes:

1origin    Dein eigener Fork
2upstream  Das Repository des Originalautors

Synchronisiere das Originalprojekt:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Führe dann die Änderungen in einem neuen Branch durch, pushe zu deinem eigenen Fork und sende dann einen PR an upstream. Fork, Clone und Branch lösen drei verschiedene Dinge: Fork ist ein Satz Repository-Speicherplatz auf GitHub, Clone bringt das Repository lokal, und Branch ist eine Entwicklungslinie innerhalb eines Repositorys.

13. README und LICENSE bestimmen, ob andere es verwenden dürfen

Eine README sollte mindestens diese Fragen beantworten:

1. Was ist das Projekt;
2. Welches Problem löst es;
3. Wie installiert oder führt man es aus;
4. Wie weit ist es derzeit fertiggestellt;
5. Wo befinden sich die Hauptdateien;
6. Wer sind die Autoren, Materialien und Quellenangaben.

Wenn der Code läuft, aber die README vage ist, könntest du es selbst drei Monate später nicht mehr aufnehmen. Eine minimale README muss nicht hübsch sein; schreibe einfach das Projekt, die Ausführungsmethode und den Status klar.

Öffentliche Repositorys bedeuten auch nicht automatisch, dass eine Open-Source-Lizenz erworben wird. Die offizielle Lizenzierungserklärung von GitHub stellt klar: Wenn keine Lizenz vorhanden ist, gelten weiterhin die standardmäßigen Urheberrechtsregeln, und der Autor behält die Rechte zum Kopieren, Verteilen und Erstellen abgeleiteter Werke. Öffentlich bedeutet, dass andere es sehen und gemäß den Nutzungsbedingungen von GitHub forken können; um den Code in dein eigenes öffentliches oder kommerzielles Projekt zu übernehmen, musst du dir auch die LICENSE im Repository ansehen.

MIT, Apache-2.0, GPL usw. haben unterschiedliche Verpflichtungen. Bei kommerzieller Nutzung, Weiterverteilung oder gemischten Lizenzen lies die vollständige Datei und konsultiere bei Bedarf einen Fachmann; frage nicht einfach eine KI "Kann ich es für kommerzielle Zwecke verwenden?"

14. Nach einem Fehler: Bestimme, auf welcher Ebene sich die Änderung befindet

Das Mittel zur Reue sollte je nach Zustand gewählt werden.

Falsche Datei gestaged, aber Dateiinhalt behalten möchten:

1git restore --staged dateiname

Die letzte Commit-Nachricht war falsch und wurde noch nicht gepusht:

1git commit --amend -m "Neue Commit-Nachricht"

Ein Commit auf einem gemeinsam genutzten Branch muss rückgängig gemacht werden:

1git revert commit_hash

revert erzeugt einen neuen umgekehrten Commit, und die alte Historie bleibt sichtbar, was sich für Branches eignet, die bereits gepusht und von mehreren Personen verwendet werden.

git restore dateiname verwirft nicht committede Änderungen; git reset --hard bringt Commits, Staging-Area und Arbeitsbereich alle auf eine angegebene Position zurück; git push --force kann Remote-Commits überschreiben. Diese drei Arten von Operationen erfordern die Bestätigung des Ziels und ein Backup vor der Ausführung; behandle sie nicht als allgemeine Reparaturknöpfe in der Nullstufenphase.

15. Die acht häufigsten Fehler: In dieser Reihenfolge überprüfen

1. fatal: not a git repository

1pwd
2ls
3git status

Normalerweise ist das Verzeichnis falsch oder das aktuelle Projekt wurde noch nicht git init ausgeführt.

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

Überprüfe, ob die Datei gespeichert ist, ob du eine andere Kopie geändert hast und ob die Änderungen bereits committed wurden:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin KorrekteGitHubAdresse

5. src refspec main does not match any

Das Repository hat möglicherweise noch keinen Commit, oder der aktuelle Branch heißt nicht main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Überprüfe die Remote-URL, Repository-Besitz, Kontoberechtigungen und Authentifizierungsmethode. Sende den Token nicht an andere zur Fehlerbehebung.

7. rejected non-fast-forward

Es gibt Remote-Commits, die lokal nicht vorhanden sind. Rufe zuerst fetch auf und zeige die Unterschiede an; führe nicht einfach force push aus:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Führe git status aus, um UU-Dateien zu finden, bestimme manuell den endgültigen Inhalt, teste, dann add und commit; wenn du es vorerst nicht bearbeitest, git merge --abort.

Wenn ein Student oder Kollege einfach sagt „Git ist kaputt“, lass sie diese fünf Ausgaben liefern:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Füge dann das Betriebssystem, den vollständigen Befehl, der gerade ausgeführt wurde, und die vollständige Fehlermeldung hinzu. Die meisten Probleme lassen sich schnell einer der Ebenen zuordnen: Verzeichnis, Status, Identität, Remote-Adresse oder Berechtigung.

16. Im KI-Zeitalter ist Git eher ein Akzeptanzsystem

KI kann Befehle für dich eingeben, aber sie kann nicht automatisch wissen, welche Änderungen den Geschäftsabsichten entsprechen. Wenn ein Prompt 20 Dateien ändert und du dir den Diff nicht ansiehst, das Projekt nicht ausführst und nicht auf Schlüssel prüfst, wird Git diesen Schlamassel nur getreulich aufzeichnen.

Ein stabilerer Weg ist es, die Aufgabe einzugrenzen und den Menschen in die Akzeptanzposition zu bringen. Nachdem der Umfang, die Unterschiede, die Tests und die Schlüsselprüfungen alle bestanden sind, entscheidet der Mensch, ob diese Änderungen zu einem Commit werden können.

Wenn du KI Git bedienen lässt, gib auch Grenzen vor:

1Bitte überprüfe zuerst git status und git diff und fasse nur die aktuellen Änderungen zusammen.
2Verwerfe keine uncommitteten Inhalte, führe kein reset --hard, clean oder force push aus.
3Liefere nach Abschluss der Änderungen Überprüfungsergebnisse, führe keine automatischen Commits oder Pushs durch.

Ob du dir Befehle merken kannst, ist nicht mehr so wichtig. Du musst in der Lage sein, den Status zu lesen, zu wissen, was die KI bewegt hat, zu beurteilen, ob die Überprüfung ausreicht, und einen Stopp zu rufen, wenn gefährliche Operationen auftauchen.

17. Führe den gesamten Prozess noch einmal durch

1# 1. Standort bestätigen
2pwd
3ls
4
5# 2. Initialisieren
6git init -b main
7git status
8
9# 3. Erster Commit
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Projekt initialisieren"
13
14# 4. Ändern, prüfen, testen, erneut committen
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Registrierungseintrag hinzufügen"
20
21# 5. Branch-Experiment
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Mit warmem Theme experimentieren"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Mit GitHub verbinden
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Abschließende Überprüfung
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

Wenn du erklären kannst, welche Ebene jeder Befehl geändert hat, und du selbstständig ein falsches Verzeichnis, einen Staging-Fehler und einen Merge-Konflikt beheben kannst, ist GitHub nicht mehr nur eine Website zum Speichern von Code. Du bist bereits in der Lage, persönliche Projekte in Repositories zu verwandeln, die überprüft, auditiert und gemeinsam bearbeitet werden können.

Der nächste Schritt erfordert nicht, weiterhin Befehle zu sammeln. Finde ein echtes kleines Projekt und mache es 7 Tage lang: Führe jeden Tag nur eine kleine Änderung durch, sieh dir den Diff an, teste, committe und pushe dann zu GitHub. Die Commit-Historie wird diese Reihe von Dingen langsam zu deiner Arbeitsgewohnheit machen.

Ich bin Miles, ein KI-Algorithmus-Experte, der von einem großen Unternehmen zu FDE gewechselt ist. Ich habe Algorithmus-F&E, Optimierungsbereitstellung und Unternehmensschulungen durchgeführt. Folge mir @miles_mazy Gemeinsam wachsen, gemeinsam Geld verdienen.