Über Git, Anfänger und Git-Artikel für Anfänger

    Freitag ist der dreizehnte hervorragende Tag für eine weitere Holywar- Diskussion über "Wie ich Git koche und warum ich es falsch koche".
    Also, jeder Programmierer, ob unter Linux, ob unter Windows, es wird immer jemanden geben, der sich jeweils in den Kreisen der Programmierer für Windows oder Linux dreht. Ich habe also Programmierer aus der Welt von Microsoft und Windows. Es ist lobenswert, dass sich solche Leute für OpenSource und Git interessieren. Aber jetzt geht es nicht darum.

    In der Geschichte verlasse ich mich manchmal auf das berühmte Buch Pro Git von Scott Chacon (Scott Chacon).

    Fall 1: Was ist schlecht git commit -m?



    In einem der Gespräche im Internet wurde ein Artikel für Anfänger in Git erwähnt, nämlich dieser . Jemand schlug auch vor, dass die Artikel "How I Prepare Git" Nuancen enthalten, die später nur schwer als schlechte Angewohnheit zu beseitigen sind. Trotzdem war ich nicht zu faul und las den Artikel. Und ich wage es, der gegebenen Meinung zuzustimmen.

    In Ordnung, was wird in dem Artikel neben vielen nützlichen Tipps vorgeschlagen ? Insbesondere solche Momente:
    1. git commit -m "Commit message"
    2. git reset --hard als Mittel zur Unterbrechung eines erfolglosen git merge
    3. eine komplizierte Idee git rebase bar, aber wir werden dies nicht diskutieren


    Warum finde ich diese Tipps nicht sehr gut, was mit der Zeit zu schlechten Gewohnheiten werden kann?

    Erstens ist es git commit -m "Commit message"zweifellos nützlich, um Änderungen zu verwerfen (Work in Progress) (das Konzept ist bei der Verwendunggit stash gut nachvollziehbar ), aber es ist schädlich für echte Änderungen an öffentlichen Brunchs, da sie oft versuchen, alles in einer Zeile zu beschreiben. In der Regel können Sie nur in der ersten Zeile der Nachricht, die häufig auf 50 bis 60 Zeichen begrenzt ist (und in vielen Fällen kann der Benutzer nur die erste Zeile sehen git log --oneline), das Wesentliche der Änderung verstehen. Wenn Sie eine detailliertere Beschreibung benötigen, fügen Sie diese hinzu, indem Sie eine Zeile nach einer einzelnen Zeile überspringen.

    Hier ist eine Beispielvorlage, wie Änderungen verarbeitet werden:
    Zusammenfassung: Eine kurze, in der Regel bis zu 66 Zeichen lange Erklärung, was diese Änderung bewirkt
    <leere Zeile>
    Beschreibung: ausführlich,
    möglicherweise mehrzeilig
    Eine Erklärung, was die Änderung bewirkt, mit Fehlerprotokollen usw.
    <leere Zeile>
    Tags: optionale Tags, Typ
    Abgemeldet von: First Last 
    Rezensiert von: First Last 


    Und hier der entsprechende Auszug aus dem Buch
    Im Allgemeinen ist es sehr wichtig, eine gute Commit-Nachricht zu schreiben. Bei Open-Source-Projekten ist es im Allgemeinen die Regel, Ihre Nachricht mehr oder weniger in diesem Format zu verfassen:

    Kurze Zusammenfassung der Änderungen (50 Zeichen oder weniger)

    . Stellen Sie ungefähr 72
    Zeichen ein. In einigen Kontexten wird die erste Zeile als
    Betreff einer E-Mail und der Rest des Texts als Textkörper behandelt. Die Leerzeile
    , die die Zusammenfassung vom Textkörper trennt, ist kritisch (es sei denn, Sie lassen
    den Textkörper vollständig weg). Einige Git-Tools können verwirrt werden, wenn Sie
    beide zusammen ausführen .

    Weitere Absätze folgen nach Leerzeilen.

    -

    Aufzählungszeichen sind auch in Ordnung - In der Regel wird ein Bindestrich oder ein Sternchen für das Aufzählungszeichen verwendet.
    davor ein einzelnes Leerzeichen mit Leerzeilen
    dazwischen, aber die Konventionen variieren hier


    Öffnen Sie beispielsweise ein beliebiges Projekt in GitHub, in dem Kommentare git commit -min einer Zeile mit Stil erstellt werden. Diese Zeile bricht in den Hauptteil der Nachricht ein, was nur eine detaillierte Beschreibung impliziert. Gleiches gilt für andere Repository-Zuordnungsdienstprogramme im Web.

    Zweitens haben viele Git-Befehlszeilenbefehle eine Option --abort. Die Verwendung in diesem Fall entspricht git reset --hard, obwohl das Ergebnis korrekt ist, dem Abschießen auf Spatzen.
    git reset --hardBereinigt nicht bereitgestellte und bereitgestellte Datenbanken, durchsucht das Repository und stellt Dateien aus dem Index wieder her, wenn sie geändert wurden, und setzt dann den Zeiger auf die angegebene ID zurück.
    git merge --abortEs ist einfacher, weil er weiß, was sich geändert hat, wo es sich geändert hat und wo es zurückkehren muss.

    Wende dich dem Buch zu
    Die Option git merge --abort versucht, zu Ihrem Status zurückzukehren, bevor Sie die Zusammenführung ausgeführt haben. Die einzigen Fälle, in denen dies möglicherweise nicht perfekt möglich ist, wären nicht gespeicherte, nicht festgeschriebene Änderungen in Ihrem Arbeitsverzeichnis, wenn Sie es ausführen. Andernfalls sollte es problemlos funktionieren.

    Wenn Sie sich aus irgendeinem Grund in einem schrecklichen Zustand befinden und einfach von vorne anfangen möchten, können Sie auch git reset ausführen - hard HEAD oder wohin Sie zurückkehren möchten. Denken Sie erneut daran, dass dies Ihr Arbeitsverzeichnis in die Luft jagt. Stellen Sie daher sicher, dass Sie dort keine Änderungen vornehmen möchten.


    Fall 2: Wie geht man rebasebei einem veralteten Feature-Zweig vor?



    Was mir sonst noch aufgefallen ist, habe ich schon in dem Gespräch erwähnt, das ich am Anfang des Artikels erwähnt habe. Dies ist der Prozess, den Menschen verwenden, nämlich diese Abfolge von Aktionen:
    # rebase myFeature относительно origin/master
    # (оговаривается, что локальный master уже мог устареть)
    git checkout master
    git pull # предлагается также git rebase с нужными аргументами
    git rebase origin/master myFeature
    # решаем конфликты один за другим
    git checkout master
    git merge --no-ff myFeature
    # утверждается, что конфликтов не будет
    


    Jetzt vergleiche mit:
    git remote update
    git rebase --onto origin/master 
    # решаем конфликтыи и тестируем
    git push myFeature:master
    # повторяем, если master успел поменятся
    

    Oder:
    git remote update origin
    git merge origin/master
    # решаем конфликтыи и тестируем
    git push myFeature:master
    # повторяем, если master успел поменятся
    


    Im ersten Fall müssen Sie eine lokale Kopie von master im Arbeitsbaum haben. Das Wechseln ist checkoutein teurer Vorgang, da Sie mit dem Dateisystem arbeiten müssen. Haben Sie bereits ein Repository für ein paar Zehntausende von Dateien vorgelegt, in dem beispielsweise kürzlich etwas durch die Vorlage geändert wurde?

    Die zweite Methode ermöglicht es Ihnen, den Index zu aktualisieren, und Sie können sofort für alle Remote-Computer, dann den Feature-Zweig in einem Vorgang aktualisieren und den dritten in master oder anderswo eintragen. Die erste Methode hatte dies nicht, abgesehen von der eigentlichen Aktualisierung des Masters.

    Fall 3: In welchen Fällen ist dies angemessen --squash?



    Darüber hinaus verwenden einige Entwicklungsteams, merge --squashum die gesamte Story nicht mit persönlichen Änderungen zu überfrachten. Aber es tut mir leid, wenn dies an die Öffentlichkeit geht (Open Source!), Dann sind alle Änderungen gemein, keine persönliche Auswahl in der Nase. squashals fixupnur in der Herstellung einer Reihe von Änderungen an dem Paket nützlich.

    Daher wird zunächst vorgeschlagen, Änderungen vor Ort vorzunehmen, zu bearbeiten, in einer normalen Serie anzuordnen und weiter hochzuladen, da dies alles bereits öffentlich ist. Andererseits, selbst wenn es sich um ein internes Repository handelt, wird es sehr schwierig sein, die Enden eines Problems zu finden. Anscheinend stellen sich nicht viele Menschen vor, was wirklich am Arbeitsplatz passiert.

    Bonus



    Und als Bonus, so ein Befehl (auf die Option achten --list):
    git branch -a --list myremote*
    

    Nützlich für Sie, insbesondere, wenn Sie den Linux-Kernel und mehrere Subsysteme gleichzeitig in einem Baum zusammenfassen, z. B .: linux-pm, linux-tty, ...

    Ja, und Google schließt Google Code.

    Jetzt auch beliebt: