Hergestellt am MIT: Gitless Version Control System


    Sie alle kennen das Git-System. Zumindest haben sie es gehört - das ist sicher. Entwickler, die das System verwenden, lieben es oder schimpfen mit seiner komplizierten Oberfläche und seinen Fehlern. Das Versionskontrollsystem von Git ist der De-facto-Standard in der Branche. Der Entwickler kann Meinungen über die Vorteile von Mercurial haben, aber meistens muss man sich mit den Anforderungen abfinden, um Git nutzen zu können. Wie jedes komplexe System verfügt es über viele nützliche und notwendige Funktionen. Da jedoch nicht alle zu brillanter Einfachheit gelangen, ließ die vorhandene Implementierung Raum für Verbesserungen.

    In einfachen Worten - eine knifflige Anwendung war schwierig zu bedienen. Deshalb hat das Labor des Massachusetts Institute of Technology Verbesserungen aufgegriffen und alle „problematischen Elemente“ abgeschnitten (schließlich kann es für ein Problem für ein anderes leicht von Vorteil sein). Die verbesserte und vereinfachte Version hieß Gitless. Es wurde unter Berücksichtigung von 2400 Fragen im Zusammenhang mit Git entwickelt und von der StackOverflow-Entwicklerseite übernommen.

    Das Autorenteam identifizierte die problematischsten Stellen in Git, einschließlich zweier Konzepte für Staging und Stashing. Dann schlugen sie Änderungen vor, um bekannte Probleme zu lösen.

    Was ist los mit git


    Viele Nutzer beschwerten sich, dass Git in der neuen Schnittstelle benötigt. Die Experten haben sogar ein Dokument erstellt. Was ist los mit Git? Konzeptionelle Analyse. Autoren: S. Perez De Rosso und D. Jackson.

    Beispiel


    git checkout < file > // отбросить все изменения в одном файле с последней выгрузки в систему
    git reset --hard    // отбросить все изменения во всех файлах с последней выгрузки в систему
    

    Diese beiden Zeilen veranschaulichen, wie sehr Git ein verbessertes Interface benötigt. Zwei verschiedene Befehle für eine Funktion mit dem Unterschied, dass einer für eine einzelne Datei und der zweite für mehrere Dateien ist. Ein Teil des Problems ist auch, dass die beiden Teams nicht genau dasselbe tun.

    Die meisten Git-Benutzer verwenden es für eine kleine Anzahl von Teams, und die verbleibenden Einheiten kennen die Plattform auf einer tieferen Ebene. Es stellt sich heraus, dass die Plattform im Grunde genommen für Grundfunktionen benötigt wird und eine große Menge an Möglichkeiten für einen zu engen Kreis verbleibt. Dies zeigt an, dass Git nicht richtig funktioniert.

    Kurzer Vergleich der Grundfunktionen mit der Vorgängerversion


    Eine der auffälligen Eigenschaften von Gitless ist, dass die Version eine Funktion namens Staging ignoriert. Hier können Sie einzelne Teile der Datei speichern. Bequem, kann aber zu Problemsituationen führen. Der Hauptunterschied zwischen dieser und der Stashing-Funktion besteht darin, dass die zweite Änderung vom Arbeitsbereich ausgeblendet wird.

    Die Stashing-Funktion verbirgt die grobe Arbeit im Arbeitsverzeichnis - überwachte Dateien, die geändert wurden, und speichert alles auf dem Stapel mit unvollständigen Änderungen. Alle Änderungen können später angewendet werden, wenn es zweckmäßig ist. Dies ist erforderlich, wenn Sie in einer Niederlassung arbeiten und sich alles in einem fehlerhaften Zustand befindet und Sie dringend zu einer anderen Niederlassung wechseln müssen. Sie möchten den Code nicht mit teilweise erledigter Arbeit im ersten Zweig für eine Weile entladen.

    Die Staging-Funktion indiziert Änderungen, die an einer Datei vorgenommen wurden. Wenn Sie bereitgestellte Dateien mit Tags versehen haben, versteht Git, dass Sie sie für den Upload vorbereitet haben.

    Gitless hat kein Konzept zum Verstauen. Stellen Sie sich folgende Situation vor. Sie sind gerade dabei, ein Projekt zu entwickeln, und sollten zu einem anderen Zweig wechseln, aber Sie haben Ihre halbfertige Arbeit noch nicht in das System hochgeladen. Die Stashing-Funktion übernimmt die von Ihnen vorgenommenen Änderungen und speichert sie auf dem Stapel mit nicht abgeschlossenen Änderungen, die Sie später wiederherstellen können.

    Der Autor des Gitless-Handbuchs meldet, dass das Problem beim Wechseln zwischen Zweigen auftritt. Es kann schwierig sein, sich zu erinnern, welches der Verstecke wo ist. Das Wichtigste dabei war, dass die Funktion nicht hilft, wenn Sie gerade eine Zusammenführung durchführen, die widersprüchliche Dateien enthält. Dies ist die Meinung von Perez de de Rosso.

    Dank Gitless ist dieses Problem gelöst. Die Zweige sind in Bezug aufeinander völlig autonom geworden. Dies erleichtert die Arbeit erheblich und ermöglicht Entwicklern, Verwirrung zu vermeiden, wenn sie ständig zwischen Aufgaben wechseln müssen.

    Änderungen speichern


    Gitless verbirgt den gesamten Bühnenbereich, wodurch der Prozess für den Benutzer transparenter und unkomplizierter wird. Es gibt viel flexiblere Festschreibungsbefehle, um Probleme zu lösen. Mit ihnen können Sie beispielsweise Codesegmente für ein Commit markieren.



    Darüber hinaus können Sie die Klassifizierung jeder Datei in Werte ändern: verfolgt, nicht verfolgt oder ignoriert. Es spielt keine Rolle, ob diese Datei im Header vorhanden ist oder nicht.



    Entwicklungsprozesse verzweigen


    Die Grundidee für das Verständnis der neuen Version: Die Zweige in Gitless sind zu völlig unabhängigen Entwicklungslinien geworden. Jeder von ihnen bleibt mit seiner Arbeitsversion der Dateien von den anderen getrennt. Es gibt keine Kreuzungen und keine Probleme. Wenn Sie zu einem anderen Zweig wechseln, wird der Inhalt Ihres Arbeitsbereichs gespeichert und Dateien, die sich auf den Zielzweig beziehen, werden wiederhergestellt. Die Dateiklassifizierung bleibt ebenfalls erhalten. Wenn die Datei in zwei verschiedenen Zweigen unterschiedlich klassifiziert ist, berücksichtigt Gitless dies.



    Einfach ausgedrückt, in der Gitless-Version müssen Sie sich nicht an Änderungen erinnern, die nicht in das System geladen wurden und die im Widerspruch zu Änderungen im Zielzweig stehen.



    Sie können die Lösung einer Konfliktsituation auch verschieben, wenn Sie eine Fusion oder Sicherung in der Mitte haben. Der Konflikt bleibt bestehen, bis Sie zurückschalten.



    Arbeiten Sie mit Remote-Repositorys


    Hier erfolgt die Synchronisation mit anderen Repositorys in beiden Programmen auf die gleiche Weise.



    Ein weiterer Vorteil der neuen Version ist die Möglichkeit, auf die alte Version umzuschalten, ohne dass Code verloren geht. Gleichzeitig ist Ihren Kollegen möglicherweise gar nicht bewusst, dass Sie eine andere Software verwenden. Sie können das

    Handbuch für die Arbeit mit Gitless auf der offiziellen Website der Anwendung lesen . In der Dokumentation wird Folgendes beschrieben: Erstellen eines Repositorys, Speichern von Änderungen; wie man mit Zweigen arbeitet; Verwenden von Tags und Arbeiten mit Remote-Repositorys.

    Was ist das Ergebnis


    Es stellte sich heraus, dass eine Anwendung die Funktionalität von Git beibehält, aber gleichzeitig für Entwicklungsteams einfacher zu erlernen und zu verwenden ist. Tatsächlich gab es bereits Versuche, Git vor Gitless zu verbessern. Laut Philip Guo (er ist Assistenzprofessor für Kognitionswissenschaft an der University of California in San Diego) hat diese Version zum ersten Mal das Ziel erreicht, die Benutzeroberfläche zu transformieren und die Hauptprobleme wirklich zu lösen.

    Das Projekt verwendete strenge Softwareentwicklungstechniken. Dies ist notwendig, um die Mängel in einem der weltweit am häufigsten verwendeten Softwareprojekte zu isolieren. In der Vergangenheit haben viele Benutzer lächerliche Argumente für und gegen Git vorgebracht, aber sie basierten nicht alle auf einem wissenschaftlichen Ansatz.

    Am Beispiel von Gitless wird deutlich, dass der Vereinfachungsansatz auch auf andere komplexe Systeme angewendet werden kann. Zum Beispiel Google Inbox und Dropbox.

    Jetzt auch beliebt: