Wie man das Leben mit Git einfacher macht (sowie eine Auswahl an Materialien zum tiefen Eintauchen)


Tree of Dragons II von surrealistguitarist

Für diejenigen, die Git jeden Tag benutzen, sich aber unsicher fühlen, das TeamMail.ru Cloud Solutions hat einen Artikel des Front-End-Entwicklers Shane Hudson übersetzt . Hier finden Sie einige Tricks und Tipps, die die Arbeit mit Git ein wenig erleichtern können, sowie eine Auswahl von Artikeln und Handbüchern für Fortgeschrittene.

Git erschien vor fast 15 Jahren. In dieser Zeit wandelte er sich von einem Außenseiter zu einem unbesiegbaren Champion. Heutzutage beginnen neue Projekte oft mit einem Team git init. Zweifellos ist dies ein wichtiges Werkzeug, das viele von uns täglich benutzen, aber oft ähnelt es Magie - hell, aber gefährlich.

Auf Habr wurden viele Artikel veröffentlicht, wie man mit Git anfängt, wie Git unter der Haube funktioniert und wie man die besten Verzweigungsstrategien beschreibt. Hier konzentrierte sich der Autor darauf, wie die Arbeit mit Git vereinfacht werden kann.

Wir bringen die Dinge in Ordnung


Git möchte Ihre Arbeit speichern, den Kontext wechseln - und etwas anderes tun. Dies kann eine Sicherung des Codes oder die Fähigkeit sein, mehrere verschiedene Funktionen asynchron zu entwickeln. Es wäre schrecklich, die zweite Version nur wegzuwerfen, weil in der ersten ein Fehler gefunden wurde. Es ist nicht weniger peinlich, Dateien mit Namen wie v1_final_bug_fixed zu speichern. Wie Sie wissen, führt dies zu einem völligen Durcheinander.

Wir alle wissen, dass das Leben viel einfacher wird, wenn unsere Updates ordentlich auf Git-Zweigen angeordnet sind, die Sie mit Kollegen teilen können. Aber oft treten Situationen auf, in denen Sie den Kontext ändern und dann zurückkehren - und Sie können nicht den richtigen Zweig finden. Gab es überhaupt ein Commit? Vielleicht ist er versteckt? Vielleicht ist das Commit nicht bestanden, jetzt sind alle in die falsche Filiale gegangen, und alles ist schlecht, und ich mache furchtbar schlechte Arbeit! Ja, alle waren da und hatten solche Zweifel. Es gibt Möglichkeiten, mit dieser Situation umzugehen.

Zweige nach Datum sortieren


Beim Sortieren nach Datum werden alle Ihre lokalen Niederlassungen beginnend mit der letzten angezeigt. Ziemlich alltäglich, aber es hat mir oft geholfen:

# To sort branches by commit date
git branch --sort=-committerdate

Vorheriger Thread


Was ist, wenn Sie nicht festgeschrieben haben, den Zweig wechseln und dann zum vorherigen zurückkehren möchten? Sie können es wahrscheinlich in der Liste der Zweige finden, wenn Sie eine Vorstellung von seinem Namen haben. Aber was ist, wenn es sich nicht um einen Zweig handelt, sondern um ein detached HEADbestimmtes Commit?

Es stellt sich heraus, dass es einen einfachen Ausweg gibt:

# Checkout previous branch
git checkout -

Der Operator -ist eine Abkürzung für Syntax @{-1}, mit der Sie zu einer beliebigen Anzahl von Kassen zurückkehren können. Also , wenn Sie zum Beispiel einen Zweig erstellt feature/thing-a, dann feature/thing-b, und dann bugfix/thing-cwird der Parameter @{-2}kehren Sie zu feature/thing-a:

# Checkout branch N number of checkouts ago
git checkout @{-N}

Informationen zu allen Branchen anzeigen


Das Flag vzeigt eine Liste aller Zweige mit der letzten Festschreibungskennung und Nachricht. Das Double vvzeigt auch die entfernten Upstream-Zweige an, gefolgt von den lokalen Zweigen:

# List branches along with commit ID, commit message and remote
git branch -vv

Datei suchen


Wir sind alle in diese Situation geraten: Irgendwie stellte sich heraus, dass eine Datei im falschen Zweig belassen wurde. Was zu tun ist? Alle Arbeiten wiederholen oder Code von einem Zweig in einen anderen kopieren? Nein, zum Glück gibt es eine Möglichkeit, eine bestimmte Datei zu finden.

Die Methode ist etwas seltsam, da git checkout -Sie zum vorherigen Zweig gelangen. Wenn Sie --beim Auschecken nach dem Filialnamen angeben, können Sie im Allgemeinen die gesuchte Datei angeben. Sie werden eine solche Funktion nicht ohne einen Hinweis erraten, aber es ist sehr praktisch, wenn Sie wissen:

git checkout feature/my-other-branch -- thefile.txt

Status löschen


Tomasz Lacoma twitterte über die Reduzierung der Emission git statusmithilfe von Flags -sbund fügte hinzu: "Seit vielen Jahren benutze ich Git, aber niemand hat mir davon erzählt." Es geht nicht nur darum, verlorene Dateien zu finden. Es gibt Zeiten, in denen die Vereinfachung des Problems das Anzeigen von Änderungen erleichtert.

Die meisten Git-Befehle haben diese Flags, daher sollten Sie lernen, wie Sie sie zum Anpassen Ihres Workflows verwenden:

# Usually we would use git status to check what files have changed
git status

# Outputs:
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: README.md

Untracked files:
(use "git add <file>..." to include in what will be committed)

another-file
my-new-file

# Using the flags -sb we can shorten the output
git status -sb

# Outputs:
## master
M README.md
?? another-file
?? my-new-file

Ganze Geschichte


Es gibt Zeiten, in denen etwas völlig schief gelaufen ist, z. B. haben Sie versehentlich inszenierte (vorbereitende) Änderungen verworfen, bevor Sie sie festschreiben. Wenn Sie git lognicht zum vorherigen Status zurückkehren können und keiner der oben genannten Tipps hilfreich ist, ist dies der Fall git reflog.

Alle Ihre Aktionen in Git, die den Inhalt durch Bezugnahme ändern HEAD@{}(zum Beispiel push/pull/branch/checkout/commit) fallen in die reflog (Referenz - Log). In der Tat ist dies die Geschichte all Ihrer Handlungen, egal in welchem ​​Zweig Sie sich befinden. Dies ist der Unterschied zu git log, der die Änderungen für einen bestimmten Zweig anzeigt.


Sie können git showmit der Commit-ID arbeiten - und die spezifische Änderung sehen. Wenn Sie danach gesucht haben, werden git checkoutSie in den gewünschten Zweig weitergeleitet oder können sogar eine bestimmte Datei auswählen, wie oben gezeigt:

# See the reference log of your activity
git reflog --all

# Look at the HEAD at given point from reflog
git show HEAD@{2}

# Checkout the HEAD, to get back to that point
git checkout HEAD@{2}

Bereiten Sie Dateien vor, bei denen das Commit verpasst wurde


In extremen Fällen git refloggibt es noch einen Trick , wenn es nicht hilft, Ihre Dateien zurückzubekommen (z. B. haben Sie einen Hard-Reset mit Zwischendateien durchgeführt).

Jede Änderung wird in Objekten gespeichert .git/objects, die mit Dateien im aktiven Projekt gefüllt sind, sodass es fast unmöglich ist, dies herauszufinden. Es gibt jedoch einen Git-Befehl namens git fsck, mit dem die Integrität (Vorhandensein beschädigter Dateien) im Repository überprüft wird. Wir können es mit einem Flag verwenden --lost-found, um nach allen Dateien zu suchen, die nicht mit einem Commit zusammenhängen. Solche Dateien werden als "Dangling Blob" bezeichnet.

Mit diesem Befehl können Sie auch "hängende Bäume" und "hängende Commits" finden. Wenn Sie möchten, können Sie die Flagge verwenden --dangling, aber den Vorteil--lost-found, dass es alle relevanten Dateien in einen Ordner extrahiert .git/lost-found. Höchstwahrscheinlich haben Sie in einem aktiven Projekt viele solcher "hängenden" Dateien. Git verfügt über einen Müllentsorgungsbefehl, der regelmäßig ausgeführt und entfernt wird.

Auf diese Weise --lost-foundwerden alle Dateien sowie die Uhrzeit und das Erstellungsdatum angezeigt, was die Suche erheblich erleichtert. Beachten Sie, dass jede einzelne Datei weiterhin separat ist, dh Sie können die Kasse nicht verwenden. Außerdem haben alle Dateien unverständliche Namen (Hash), sodass Sie die erforderlichen Dateien an einen anderen Speicherort kopieren müssen:

# This will find any change that was staged but is not attached to the git tree
git fsck --lost-found

# See the dates of the files
ls -lah .git/lost-found/other/

# Copy the relevant files to where you want them, for example:
cp .git/lost-found/other/73f60804ac20d5e417783a324517eba600976d30 index.html

Git in der Teamarbeit


Git allein zu verwenden ist eine Sache, aber wenn Sie in einem Team von Menschen arbeiten, normalerweise mit völlig unterschiedlichen Erfahrungen, Fähigkeiten und Werkzeugen, kann Git sowohl ein Segen als auch ein Fluch sein. Dies ist ein leistungsstarkes Tool, mit dem Sie dieselbe Codebasis gemeinsam nutzen, eine Codeüberprüfung durchführen und den Fortschritt des gesamten Teams überwachen können. Gleichzeitig müssen alle Mitarbeiter ein gemeinsames Verständnis für die Verwendung in der Teamarbeit haben. Unabhängig davon, worum es geht: Die Konvention, die Zweige zu benennen, die zugehörige Nachricht im Commit zu formatieren oder auszuwählen, welche Dateien in das Commit aufgenommen werden sollen, ist wichtig, eine gute Kommunikation sicherzustellen und sich auf die Verwendung dieses Tools zu einigen.

Es ist immer wichtig, Anfängern die Einfachheit des Onboarding zu gewährleisten und darüber nachzudenken, was passieren wird, wenn sie anfangen, Verpflichtungen einzugehen, ohne die vom Unternehmen festgelegten Grundsätze und Konventionen zu kennen. Dies ist nicht das Ende der Welt, aber es kann einige Verwirrung stiften und Zeit brauchen, um zu einem koordinierten Ansatz zurückzukehren.

Dieser Abschnitt enthält einige Empfehlungen, wie Sie die akzeptierten Vereinbarungen direkt in das Repository selbst integrieren, die maximale Anzahl von Aufgaben in Deklarationen automatisieren und ausgeben können. Im Idealfall beginnt jeder neue Mitarbeiter fast sofort im gleichen Stil wie der Rest des Teams zu arbeiten.

Die gleichen Zeilenenden


Standardmäßig verwendet Windows DOS-Zeilenenden \r\n(CRLF), während Mac und Linux UNIX-Zeilenenden \n(LF) verwenden, während ältere Versionen von Mac \rCR verwenden. Wenn das Team wächst, wird das Problem inkompatibler Zeilenenden wahrscheinlicher. Dies ist unpraktisch, sie brechen (normalerweise) den Code nicht, aber aufgrund dessen zeigen Commits und Pool-Anfragen verschiedene irrelevante Änderungen. Oft ignorieren die Leute sie einfach, weil es ziemlich mühsam ist, herumzulaufen und alle falschen Zeilenenden zu ändern.

Es gibt eine Lösung: Sie können alle Teammitglieder bitten, ihre lokalen Konfigurationen für die automatische Leitungsvervollständigung zu konfigurieren:

# This will let you configure line-endings on an individual basis
git config core.eol lf
git config core.autocrlf input

Natürlich müssen Sie sich für diese Tagung und einen Anfänger anmelden, was leicht zu vergessen ist. Wie geht das für das ganze Team? Gemäß dem Arbeitsalgorithmus prüft Git, ob eine Konfigurationsdatei im .git / config-Repository vorhanden ist, prüft dann die systemweite Konfiguration des Benutzers ein ~/.gitconfigund prüft dann die globale Konfiguration ein /etc/gitconfig.

All dies ist gut, aber es stellt sich heraus, dass keine dieser Konfigurationsdateien über das Repository selbst installiert werden kann. Sie können repository-spezifische Konfigurationen hinzufügen, diese gelten jedoch nicht für andere Teammitglieder.

Es gibt jedoch eine Datei, die tatsächlich im Repository festgeschrieben ist. Es heißt .gitattributes . Standardmäßig haben Sie es nicht. Erstellen Sie daher eine neue Datei und speichern Sie sie unter*.gitattributes*. Es legt Attribute für jede Datei fest. Beispielsweise können Sie git diff zwingen, Exif-Header aus Bilddateien zu verwenden, anstatt zu versuchen, den Unterschied in Binärdateien zu berechnen. In diesem Fall können wir einen Platzhalter verwenden, damit die Einstellung für alle Dateien funktioniert und tatsächlich als gemeinsame Konfigurationsdatei für den gesamten Befehl fungiert:

# Adding this to your .gitattributes file will make it so all files
# are checked in using UNIX line endings while letting anyone on the team
# edit files using their local operating system’s default line endings.
* text=auto

Automatisch ausblenden


Es ist üblich, kompilierte Dateien (z. B. node_modules/) zu .gitignore hinzuzufügen, damit sie lokal gespeichert und nicht in das Repository hochgeladen werden. Manchmal möchten Sie die Datei jedoch immer noch hochladen, sie jedoch nicht jedes Mal später in der Poolanforderung erfüllen.

In dieser Situation (zumindest auf GitHub) können Sie .gitattributes markierte Pfade hinzufügen linguist-generatedund sicherstellen, dass sich .gitattributes im Stammordner des Repositorys befindet. Dadurch werden die Dateien in der Poolanforderung ausgeblendet. Sie werden „minimiert“: Sie können die Tatsache der Änderung immer noch sehen, jedoch ohne den vollständigen Code.

Alles, was Stress und kognitive Belastung im Codeüberprüfungsprozess reduziert, verbessert die Qualität und verkürzt die Zeit.

Sie möchten beispielsweise Ressourcendateien (Asset) zum Repository hinzufügen, diese jedoch nicht ändern und später verfolgen, sodass Sie der Datei die folgende Zeile mit Attributen hinzufügen können:

*.asset linguist-generated

Verwenden Sie git Schuld häufiger


Harry Roberts ' Artikel "Kleine Dinge, die ich gerne mit Git mache" empfiehlt git blame( git praiseÜbersetzung zuweisen), einen Alias (Übersetzung aus der Übersetzung "Englisch") zuzuweisen , um dieses Team als positive Aktion zu empfinden. Das Umbenennen ändert natürlich nichts am Verhalten des Teams. Aber wenn in der Diskussion eine Funktion verwendet wird git blame, werden alle angespannt, und das tue ich natürlich auch. Es ist nur natürlich, das Wort Schuld (Schuld) als etwas Negatives wahrzunehmen ... aber das ist völlig falsch!

Eine leistungsstarke Funktion git blame (oder git praise, wenn Sie möchten) zeigt an, wer als letzter mit diesem Code gearbeitet hat. Wir werden ihn nicht beschuldigen oder loben, sondern nur die Situation klären. Es wird klarer, welche Fragen an wen gestellt werden müssen, was Zeit spart.

Es sollte git blamenicht nur als etwas Gutes präsentiert werden, sondern auch als Kommunikationsmittel, das dem gesamten Team hilft, das Chaos zu reduzieren und keine Zeit damit zu verschwenden, herauszufinden, wer was weiß. Einige IDEs, z. B. Visual Studio, aktivieren diese Funktion als Anmerkungen. Für jede Funktion sehen Sie sofort, wer sie zuletzt geändert hat (und daher mit wem Sie darüber sprechen können).

Analoge Git-Schuld für fehlende Dateien


Kürzlich habe ich einen Entwickler in unserem Team gesehen, der versucht herauszufinden, wer wann und warum eine Datei gelöscht hat. Es scheint, als könnte es hier helfen git blame, aber es funktioniert mit den Zeilen in der Datei und ist nutzlos, wenn die Datei fehlt.

Es gibt jedoch eine andere Lösung. Alte Gläubige git log. Wenn Sie das Protokoll ohne Argumente betrachten, wird eine lange Liste aller Änderungen im aktuellen Zweig angezeigt. Sie können eine Festschreibungskennung hinzufügen, um das Protokoll dieser bestimmten Festschreibung anzuzeigen. Wenn Sie jedoch angeben --(was wir zuvor für eine bestimmte Datei verwendet haben), können Sie ein Protokoll für eine Datei abrufen - auch für eine Datei, die nicht mehr vorhanden ist:

# By using -- for a specific file,
# git log can find logs for files that were deleted in past commits
git log -- missing_file.txt

Nachrichtenvorlage festschreiben


Commit-Nachrichten müssen häufig verbessert werden. Früher oder später kommen die Entwickler im Team zu diesem Schluss. Es gibt viele Möglichkeiten, sich zu verbessern. Sie können beispielsweise auf Fehlerkennungen aus einem internen Projektmanagement-Tool verweisen oder möglicherweise dazu ermutigen, mindestens einen Text anstelle einer leeren Nachricht zu schreiben.

Dieser Befehl muss jedes Mal manuell ausgeführt werden, wenn jemand das Repository klont, da Konfigurationsdateien nicht für das Repository festgeschrieben werden. Dies ist jedoch praktisch, da Sie eine allgemeine Datei mit einem beliebigen Namen erstellen können, der als Vorlage für Festschreibungsnachrichten fungiert:

# This sets the commit template to the file given,
# this needs to be run for each contributor to the repository.
git config commit.template ./template-file

Git für die Automatisierung


Git ist ein leistungsstarkes Automatisierungstool. Dies ist nicht sofort offensichtlich, aber denken Sie selbst: Er sieht alle Ihre Aktivitäten im Repository - plus die Aktivitäten anderer Teilnehmer - und verfügt über viele Informationen, die sehr nützlich sein können.

Git Hooks


Sehr oft sehen Sie, dass Teammitglieder während der Arbeit sich wiederholende Aufgaben ausführen. Dies kann ein Test zum Bestehen von Tests und Linter vor dem Senden eines Zweigs an den Server (Hook vor dem Senden) oder eine erzwungene Strategie zum Benennen von Zweigen (Hook vor dem Festschreiben) sein. Zu diesem Thema schrieb Konstantinos Lamonis im Smashing Magazine einen Artikel mit dem Titel Vereinfachung des Workflows mithilfe von Git Hooks“ .

Manuelle Automatisierung


Eine der wichtigsten Automatisierungsfunktionen in Git ist git bisect. Viele haben davon gehört, aber nur wenige benutzen es. Unter dem Strich wird der Git-Baum (Commit-Verlauf) verarbeitet und ermittelt, wo der Fehler eingegeben wird.

Der einfachste Weg, dies zu tun, ist von Hand. Sie starten git bisect start, legen die Kennungen für gute und schlechte Commits fest (wo kein Fehler vorliegt und wo ein Fehler vorliegt) und führen dann git bisect goododer git bisect badfür jedes Commit aus.

Dies ist eine leistungsstärkere Funktion, als es auf den ersten Blick scheint, da das Git-Protokoll nicht linear ausgeführt wird, was manuell als iterativer Prozess erfolgen könnte. Stattdessen wird eine binäre Suche verwendet, die Commits mit der geringsten Anzahl von Schritten effektiv durchläuft:

# Begin the bisect
git bisect start

# Tell git which commit does not have the bug
git bisect good c5ba734

# Tell git which commit does have the bug
git bisect bad 6c093f4

# Here, do your test for the bug.
# This could be running a script, doing a journey on a website, unit test etc.

# If the current commit has bug:
git bisect bad

# If the current commit does not have the bug
git bisect good

# This will repeat until it finds the first commit with the bug
# To exit the bisect, either:

# Go back to original branch:
git bisect reset

# Or stick with current HEAD
git bisect reset HEAD

# Or you can exit the bisect at a specific commit
git bisect reset <commit ID>

Weiter geht's: Wissenschaftliche Automatisierung


In seinem wissenschaftlichen Debugging- Bericht erklärte Stuart Halloway , wie der Befehl git bisectzum Automatisieren des Debuggens verwendet wird.
Er konzentriert sich auf Clojure, aber wir müssen diese Sprache nicht kennen, um von seinem Vortrag zu profitieren.

Git bisect ist teilweise wissenschaftliche Automatisierung. Sie schreiben ein kleines Programm, das etwas testet, und Git springt hin und her und schneidet die Welt mit jedem Sprung in zwei Hälften, bis die Grenze gefunden wird, an der Ihr Test den Status ändert.
Stuart Halloway

Auf den ersten Blick git bisectmag es wie eine interessante und ziemlich coole Funktion erscheinen, aber am Ende ist es nicht sehr nützlich. Die Leistung von Stewart zeigt weitgehend, dass das Debuggen tatsächlich kontraproduktiv ist, wie wir es gewohnt sind. Wenn Sie sich stattdessen auf empirische Fakten konzentrieren, unabhängig davon, ob der Test bestanden wurde oder nicht, können Sie ihn bei allen Commits ausführen, beginnend mit der Arbeitsversion, und das gewohnte Gefühl des „Wanderns im Dunkeln“ reduzieren.

Wie automatisieren wir also?git bisect? Sie können ihm für jedes entsprechende Commit ein Skript übergeben. Früher habe ich gesagt, dass Sie das Skript bei jedem Schritt der Halbierung manuell ausführen können. Wenn Sie jedoch einen Befehl zum Ausführen übergeben, wird das Skript bei jedem Schritt automatisch ausgeführt. Es kann ein Skript speziell zum Debuggen dieses spezifischen Problems oder ein Test sein (modular, funktional, Integration, jede Art von Test). Daher können Sie einen Test schreiben, um sicherzustellen, dass sich die Regression nicht wiederholt, und diesen Test für frühere Commits ausführen:

# Begin the bisect
git bisect start

# Tell git which commit does not have the bug
git bisect good c5ba734

# Tell git which commit does have the bug
git bisect bad 6c093f4

# Tell git to run a specific script on each commit
# For example you could run a specific script:
git bisect run ./test-bug

# Or use a test runner
git bisect run jest

Bei jedem vergangenen Commit


Eine der Stärken git bisectist die effektive Verwendung der binären Suche, um alle Ereignisse in der Geschichte nichtlinear zu umgehen. Manchmal ist jedoch ein linearer Bypass erforderlich. Sie können ein Skript schreiben, das das Git-Protokoll liest und bei jedem Commit den Code durchläuft. Aber es gibt einen Freund, der das für Sie erledigt : git rebase.

Kamran Ahmed in einem Tweet geschrieben, wie er rebaseist, welches Commit den Test nicht besteht:

Suchen Sie ein Commit, das den Test nicht besteht:

$ git rebase -i --exec "yarn test" d294ae9

Der Befehl führt den Garntest für alle Commits zwischen d294ae9 und HEAD aus und stoppt bei dem Commit, bei dem der Test abstürzt.

Wir haben bereits git bisectüber diese Aufgabe nachgedacht , die möglicherweise effizienter ist, aber in diesem Fall sind wir nicht auf einen Anwendungsfall beschränkt.

Es gibt einen Platz für Kreativität. Vielleicht möchten Sie einen Bericht darüber erstellen, wie sich der Code im Laufe der Zeit geändert hat (oder den Verlauf der Tests anzeigen), und es reicht nicht aus, nur das Git-Protokoll zu analysieren. Vielleicht ist dies nicht der nützlichste Trick in diesem Artikel, aber er ist interessant und zeigt eine Aufgabe, deren Realität wir vorher nicht glauben konnten:

# This will run for every commit between current and the given commit ID
git rebase -i --exec ./my-script

Eine Auswahl von Artikeln und Handbüchern, die Ihnen helfen, tiefer in Git einzusteigen


In einem solchen Artikel ist es unmöglich, sich mit dem Thema zu befassen, sonst wird das ganze Buch herauskommen. Ich habe einige kleine Tricks ausgewählt, von denen selbst erfahrene Benutzer möglicherweise nichts wissen. Git bietet jedoch noch viel mehr Funktionen: von Grundfunktionen über komplexe Skripte bis hin zu präzisen Konfigurationen und Konsolenintegration. Daher sind hier einige Ressourcen aufgeführt, die für Sie von Interesse sein können:

  1. Explorer Git . Eine interaktive Website, mit der Sie leicht verstehen, wie Sie das erreichen, was Sie wollen.
  2. Dang it git! . Jeder von uns kann sich irgendwann in Git verirren und weiß nicht, wie er ein Problem lösen soll. Diese Website bietet Lösungen für viele der häufigsten Probleme.
  3. Pro git . Dieses kostenlose Buch ist eine unschätzbare Ressource für das Verständnis von Git.
  4. Git Docs. — . , Git Docs, Git (, man git-commit) Git .
  5. Thoughtbot. Git Thoughtbot .
  6. Git. Git.
  7. Git. , … . Git, .
  8. Git: vom Anfänger bis zum Fortgeschrittenen . Mike Ritmüller hat diesen nützlichen Artikel geschrieben, der ideal für unerfahrene Git-Benutzer ist.
  9. Kleinigkeiten, die ich gerne mit Git mache . Es war dieser Artikel von Harry Roberts, der mir klar machte, wie viele Möglichkeiten in Git noch lauern, abgesehen davon, dass Code über Zweige hinweg verschoben wird.
  10. Atlassian Advanced Git Guides . In diesen Tutorials werden viele der in diesem Artikel genannten Themen beschrieben.
  11. Git Spickzettel auf Github . Es ist immer bequem, ein gutes Spickzettel für Tools wie Git zu haben.
  12. Git-Reduktion . Dieser Artikel beschreibt verschiedene Git-Befehlsflags und empfiehlt viele Aliase.

Aber was können Sie noch lesen :

  1. Git. №1: , .git
  2. Git. №2: rebase.
  3. .

All Articles