27 wichtige Tipps für Git- und GitHub-Benutzer

Während Git-Benutzer Dutzende von Anleitungen zur Auswahl haben und GitHub eine Reihe eigener Anleitungen anbietet, ist es immer noch nicht einfach, eine Sammlung nützlicher Tipps für Entwickler zu finden, die intelligenter mit Git und GitHub arbeiten möchten. Lassen Sie uns das beheben.

Für diejenigen unter Ihnen, die mit Git oder GitHub nicht vertraut sind, bieten die nächsten Absätze genügend Hintergrundinformationen, um die Tipps zu verstehen. Wir werden am Ende dieses Artikels ungefähr ein Dutzend nützliche Ressourcen auflisten.

Git ist ein verteiltes Versionskontrollsystem, das ursprünglich von Linus Torvalds im Jahr 2005 für und mit Hilfe der Linux-Kernel-Community geschrieben wurde. Ich bin nicht hier, um Sie auf Git zu verkaufen, also erspare ich Ihnen das Spiel darüber, wie schnell und klein und flexibel und beliebt es ist, aber Sie sollten das wissen, wenn Sie ein Git-Repository klonen (kurz „Repo“). Sie erhalten den gesamten Versionsverlauf auf Ihrem eigenen Computer, nicht nur einen Schnappschuss von einem Zweig gleichzeitig.

Git wurde als Befehlszeilentool gestartet, was seinem Ursprung in der Linux-Kernel-Community entspricht. Sie können weiterhin die Git-Befehlszeile verwenden, wenn Sie möchten, müssen dies aber nicht. Insbesondere wenn Sie GitHub als Host verwenden, können Sie den kostenlosen GitHub Desktop-Client unter Windows oder Mac verwenden. Auf der anderen Seite funktioniert die Git-Befehlszeile für jeden Host und ist auf den meisten Mac- und Linux-Systemen vorinstalliert.

Nur Sie können entscheiden, ob Sie sich mit der Befehlszeile oder einem nativen Client mit grafischer Benutzeroberfläche am wohlsten fühlen. Wenn Sie eine GUI mögen, sollten Sie zusätzlich zum GitHub-Client (Windows und Mac) SourceTree (Windows und Mac, kostenlos), TortoiseGit (nur Windows, kostenlos) und Gitbox (nur Mac, 14,99 USD) in Betracht ziehen. Oder Sie können einen Editor oder eine IDE verwenden, die Git intern unterstützt (siehe Tipp Nr. 11).

Git / GitHub-Tipp Nr. 1: Klonen Sie fast alles

Es gibt viele interessante Projekte von GitHub und anderen öffentlichen Git-Repositories, die Sie frei auf Ihren eigenen Computer klonen können. Warum willst du das tun? Ein Grund ist, etwas über Codierungsstil, -praxis und -werkzeuge in einer Sprache von Interesse zu lernen, einschließlich des Kommentierungsstils für das Festschreibungsprotokoll (siehe Tipp Nr. 4). Ein zweiter Grund ist zu erfahren, wie ein bestimmtes Projekt seine Ziele erreicht. Ein dritter Grund, falls die Lizenzierung dies zulässt und für Ihre Zwecke sinnvoll ist, besteht darin, das Projekt in Ihr eigenes Unternehmen oder Produkt einzubeziehen. Überprüfen Sie die Lizenz übrigens noch einmal, damit Sie später nicht auf Compliance-Probleme stoßen.

Die Definition von git cloneaus der Handbuchseite:

Klont ein Repository in ein neu erstelltes Verzeichnis, erstellt Remote-Tracking-Zweige für jeden Zweig im geklonten Repository (sichtbar mit git branch -r) und erstellt und checkt einen anfänglichen Zweig aus, der aus dem derzeit aktiven Zweig des geklonten Repositorys gegabelt wird.

Nach dem Klonen git fetchaktualisiert eine Ebene ohne Argumente alle Remote-Tracking-Zweige, und eine git pullohne Argumente führt zusätzlich den Remote-Master-Zweig in den aktuellen Master-Zweig ein, falls vorhanden.

Git / GitHub-Tipp Nr. 2: Häufig ziehen

Eine der einfachsten Möglichkeiten, sich mit Git (und in der Tat mit jedem Versionskontrollsystem) selbst in Unordnung zu bringen, besteht darin, zuzulassen, dass Dateien nicht mehr synchron sind. Wenn Sie git pullhäufig sind, halten Sie Ihre Kopie des Repos auf dem neuesten Stand und haben die Möglichkeit, Ihren geänderten Code mit den Änderungen anderer zusammenzuführen, während das Zusammenführen leicht zu verstehen und durchzuführen ist - idealerweise, wenn es so einfach ist, dass es möglich ist automatisch durchgeführt werden. Eine Folge dieses Tipps ist, Ihren Projektstatus zu beobachten. Viele Git-Clients zeigen Ihnen automatisch an, wann Sie ein Update durchführen müssen, um auf dem neuesten Stand zu bleiben.

Git / GitHub-Tipp Nr. 3: Früh und häufig festlegen

Ein Commit ist eine detaillierte Aktualisierung eines Projekts, die eine oder mehrere Änderungen an einer oder mehreren Dateien enthält. Stellen Sie sich das als Aufzeichnung einer abgeschlossenen Arbeitseinheit vor, die als logisches Ganzes auf das Projekt angewendet oder daraus entfernt werden kann. Übernehmen Sie jede logische Änderung, die Sie durchführen, noch bevor Sie sie testen. Commits gelten nur für Ihr lokales Repository. Siehe die Tipps Nr. 4 und 5 für Folgerungen zu diesem Tipp.

Die Definition von git commitaus der Handbuchseite:

Speichert den aktuellen Inhalt des Index in einem neuen Commit zusammen mit einer Protokollnachricht des Benutzers, in der die Änderungen beschrieben werden.

Git / GitHub-Tipp Nr. 4: Kommentieren Sie Ihre Commits so, wie andere sie kommentieren würden

Es gibt 10 Arten von Codierern: diejenigen, die ihre Commits kommentieren, und diejenigen, die dies nicht tun. (Alter Witz. Hinweis: Welche Basis benutze ich?)

Ich gebe frei zu, ein Stickler für gute Commit-Log-Nachrichten zu sein. Ich habe meine Repositorys so eingerichtet, dass für jedes Commit Nachrichten erforderlich sind, und es ist bekannt, dass ich verärgerte Nachtnachrichten versende, wenn Commits mit Protokollen in der Größenordnung von „xx“ landen. Wenn Sie der Entwickler sind, der der Meinung ist, dass (1) der Code für sich selbst sprechen sollte und (2) die Inline-Kommentare viel wichtiger sind als die Änderungsprotokolle, versuchen Sie, ein Repository zu klonen, das Sie noch nie gesehen haben, und identifizieren Sie das Das letzte Commit, das möglicherweise das zuletzt veröffentlichte Problem verursacht hat, ohne den gesamten Code zu lesen. Wie Sie sehen können, sind genaue Festschreibungsprotokolle doppelt so gut.

Git / GitHub-Tipp Nr. 5: Drücken Sie, wenn Ihre Änderungen getestet werden

Der schlimmste Git-bezogene Fehler, von dem ich jemals das Unglück hatte zu wissen, trat auf, als ein Outsourcing-Unternehmen von Subversion wechselte, seine Entwickler jedoch nicht über den Unterschied zwischen verteilter Quellcodeverwaltung und zentraler Quellcodeverwaltung schulte. Ungefähr einen Monat später entwickelte das Projekt seltsame Fehler, die niemand aufzuspüren schien. Bei den täglichen Stand-up-Meetings protestierten die Entwickler, die für den Bereich der Anwendung verantwortlich waren, der sich schlecht benahm: „Ich habe das vor zwei Wochen behoben!“ oder beschuldigen Sie einen anderen Entwickler, sich nicht die Mühe gemacht zu haben, die Änderungen zu übernehmen, die er so sorgfältig eingecheckt hat.

Irgendwann hat jemand das Problem identifiziert und allen Entwicklern beigebracht, wie und wann sie pushihre Commits ausführen sollen: Kurz gesagt, wann immer die Commits in einem lokalen Build erfolgreich getestet werden. Anschließend führte das Unternehmen ein zweitägiges Zusammenführungsfest durch, bevor es das aktualisierte, integrierte Produkt erstellen und bereitstellen konnte.

Git / GitHub-Tipp Nr. 6: Frei verzweigen

Einer der größten Vorteile von Git gegenüber einigen anderen Versionskontrollsystemen besteht darin, dass das Zusammenführen normalerweise gut funktioniert, zumindest teilweise, weil Git automatisch den besten gemeinsamen Vorfahren für eine Zusammenführung auswählt. Die meisten Softwareentwickler müssen häufiger mit der Erstellung von Zweigen in ihren Projekten beginnen. Es sollte ein routinemäßiges tägliches Ereignis sein und nicht Gegenstand eines angstvollen All-Hands-Strategietreffens. Es ist wahrscheinlich, dass die Zusammenführung keine unüberwindbaren Probleme aufwirft, wenn das Zweigstellenprojekt abgeschlossen, akzeptiert und bereit ist, in das Hauptprojekt einzusteigen.

Ich weiß, dass dies einige Anpassungen erfordert, insbesondere wenn Sie in einem Unternehmen stecken geblieben sind, das die Quellcodeverwaltung mit CVS durchführt. Aber probieren Sie es aus. Es ist viel besser, als wenn Kunden versehentlich Ihren unvollendeten experimentellen Code sehen, wenn das Trunk-Projekt aufgrund eines fehlerhaften Fehlers veröffentlicht werden muss. (In diesem Artikel wird das grundlegende Verzweigen und Zusammenführen gut erläutert.)

Git / GitHub-Tipp Nr. 7: Vorsichtig zusammenführen

Während Zusammenführungen mit Git normalerweise gut funktionieren, können gelegentlich Schwierigkeiten auftreten, wenn Sie sie ohne nachzudenken ausführen. Schritt eins besteht darin, sicherzustellen, dass Sie keine nicht festgeschriebenen Änderungen haben. Von der git mergeHandbuchseite:

Bevor Sie Änderungen von außen anwenden, sollten Sie Ihre eigene Arbeit in einen guten Zustand bringen und sich vor Ort engagieren, damit sie bei Konflikten nicht überlastet wird. Siehe auch git-stash.

Siehe auch Tipp Nr. 8.

Auch wenn während eines nach Süden geht git merge, sind Sie nicht abgespritzt:

Wenn Sie eine Zusammenführung versucht haben, die zu komplexen Konflikten geführt hat, und neu beginnen möchten, können Sie mit wiederherstellen git merge —abort.

Der Folgebefehl für git mergelautet normalerweise git mergetool, vorausgesetzt, Sie möchten eine GUI zum Zusammenführen verwenden. Wenn Sie die Old-School - Methode bevorzugen würden, können Sie die Dateien in Konflikt mit Ihrem Lieblings - Programmeditor bearbeiten, vollständig entfernen Sie die <<<<<<<, =======und >>>>>>>Linien, speichern Sie die geänderten Dateien und git addjede Datei , die Sie festgelegt.

Git / GitHub-Tipp Nr. 8: Verstecken Sie sich, bevor Sie die Zweige wechseln

Der Workflow eines Softwareentwicklers ist selten linear. Benutzer haben die Galle, Fehler zu melden, Manager haben die Kühnheit, andere Tickets als die zu priorisieren, an denen Sie gearbeitet haben, und Sie können Ihre Meinung über das, was Sie tun möchten, selbst ändern.

Dort befinden Sie sich mit drei Dateien, die für eine Veröffentlichung festgeschrieben wurden, und einer vierten Datei in einem geänderten, aber nicht funktionierenden Zustand. (Der git statusBefehl sagt Ihnen alles, wenn Sie sich nicht daran erinnern, wo Sie waren.) Plötzlich müssen Sie an einer Fehlerbehebung in einer Produktionsversion arbeiten. Sie müssen die Filialen sofort wechseln, können dies aber nicht. Ihr Arbeitsverzeichnis ist schmutzig und Sie haben zwei Stunden Arbeit, die Sie nicht verlieren möchten.

Geben Sie ein git stash. Voilà! Jetzt haben Sie alle Ihre Änderungen in einem WIP-Zweig (work in progress) gespeichert und können von Ihrem sauberen Verzeichnis zum Produktionszweig wechseln. Wenn Sie damit fertig sind, wechseln Sie zurück zu Ihrem Standort git stash apply.

Git / GitHub-Tipp Nr. 9: Verwenden Sie Gists, um Snippets und Pasten zu teilen

GitHub-Gists - gemeinsam genutzte Codefragmente - sind keine Git-Funktion, verwenden jedoch Git. Alle Gists sind Git-Repositories, und GitHub Gist erleichtert das Teilen. Sie können Gist nach Thema, Programmiersprache, Gabelstatus und Sternstatus nach öffentlichen Gists durchsuchen. Sie können auch geheime Zusammenfassungen erstellen und diese per URL freigeben.

Git / GitHub-Tipp Nr. 10: Entdecken Sie GitHub

Viele interessante Open Source-Projekte haben Repositories auf GitHub. Explore GitHub bietet eine Suchoberfläche, um einige von ihnen zu finden. Meistens ist es jedoch einfacher, ein paar Buchstaben des Projektnamens in das Suchfeld einzugeben, um die Repos zu finden. Geben Sie beispielsweise jqoder backoder ein ang, um drei der wichtigsten Open Source-JavaScript-Frameworks zu finden.

Git / GitHub-Tipp Nr. 11: Beitrag zu Open Source-Projekten

Warum nicht einen Beitrag dazu leisten, solange Sie Open Source-Projekte durchsuchen? Es ist nicht so schwer, wie Sie vielleicht denken, und Sie werden viel lernen. Sie können beispielsweise das Projekt jquery / jquery (jQuery Core) klonen und README.MD durchsuchen. In der Nähe der Spitze sehen Sie:

Im Sinne der Open-Source-Softwareentwicklung fördert jQuery immer den Beitrag von Community-Code. Lesen Sie diese wichtigen Richtlinien für Beiträge sorgfältig durch, bevor Sie mit dem Schreiben von Code beginnen ...

Darauf folgen drei Links. Mit dem ersten der drei können Sie ziemlich schnell loslegen. Nicht jedes Open-Source-Projekt legt den Plan so klar dar, aber alle versuchen es.

Verstehe den Unterschied zwischen einem Mitwirkenden und einem Committer. Ein Mitwirkender hat die erforderlichen Vereinbarungen unterzeichnet und einen Beitrag für das Projekt bereitgestellt. Ein Committer ist befugt, den angebotenen Beitrag tatsächlich zum Projekt-Repository zu übertragen. Da es zu Verzögerungen kommt, während ein Committer Ihren Beitrag testet und Sie Ihren Hauptzweig nicht binden möchten, sollten Sie Ihre Änderungen in einem anderen Zweig vornehmen (siehe Tipp Nr. 6), bevor Sie eine Pull-Anfrage senden (siehe Tipp Nr. 6) 16).