Tokolosh schrieb:
Verstehe das Argument mit der Zeitersparnis zudem überhaupt nicht..
(CB verkleinert große Screen wohl... Das Original ist 6400x1440 groß...)
Wieviel Befehle bräuchtest du denn so auf der CLI, um die dargestellten Infos aufzuzeigen, plus beim Klick auf einen Commit die geänderten Dateien (+ Doppelklick für nen Diff), plus die Auflösung der Changes bei nem Merge Commit + alle Details zum Commit selbst.
Du fragst noch welche Zeitersparnis? Es ist möglich
viel mehr Informationen auf geringerem Platz unterzubringen.
Es gibt mit
tig ein ncurses Interface. Ist ganz nett und vereinfacht die Arbeit ein wenig. Mit ner Integration in ner IDE hält es trotzdem nicht mit. Eher als Alternative für TortoiseGit gedacht.
Versteh mich nicht falsch, ich nutze die CLI ständig für Rebases (für nen Merge-Konflikt aber die IDE) und tiefgreifende Sachen (bspw. reflog), aber in Sachen Praktikabilität ist die CLI einfach nur furchtbar. Beim Entwickeln nehm ich bspw. JetBrains Tools, für reguläre Sachen im Dateisystems hält TortoiseGit her, für spezielle Sachen muss die CLI ran und auf dem Server ist sowieso nur die CLI verfügbar.
Mein favorisierter History-Alias:
Code:
hist = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset) ' --all
Der Newline ist nur, weil Graph, Commit ID, Datum (abs + rel) und Headline sonst nicht auf eine Zeile passen und falls doch ein Newline den kompletten Output zerstört. Da lob ich mir ne GUI mit nem Control, was (autosized) Columns beherrscht.
Btw: Ich hasse auch andere Tools wie GitKraken, SourceTree und Co. Sind vielleicht ganz nett für Git, aber ich nutz doch nicht ein vollkommen isoliertes Tool für nen Workflow, wenn es bessere Integrationen in meiner IDE gibt.
RalphS schrieb:
Aber die eigentliche Versionskontrolle mach ich lieber händisch. Geht bestimmt auch über die IDE gut genug, aber ich hab lieber vor der Nase, was was sein soll, welches Update welcher Datei zu welchem Commit gehören soll und so fort.
Die mir einzig richtige Integration bietet JetBrains mit ihren IDEs. Dort kann man mittlerweile wirklich das Wichtigste über die GUI in ausreichend detailliertem Maße regeln. Es passieren noch Sachen automatisch, aber bspw. nur so sinnloses Zeugs wie "Stash + Pull + Stash pop". Wenn es nen Konflikt gibt, passiert es bspw. nicht automatisch, sondern du erhälst ne Fehlermeldung vorher.
Das
Commit-Window ist bspw. das Vorbildlichste überhaupt.
- Oben die geänderten Dateien, ob diese mit committed werden sollen, oder ob du ggf. nur vergessen hast, sie aus dem Staging-Bereich zu entfernen. Heißt ergo nicht Dialog schließen, Datei aus dem Staging Bereich entfernen, Commit Window neu öffnen.
- Darunter die Nachricht, welche bei jedem Tippen gespeichert wird. Raucht dir im schlimmsten Fall IDE ab, ist die Nachricht trotzdem vorhanden.
- Ganz unten einen Diff der ausgewählten Datei. In einer der letzten Versionen kam auch ein Interactive Commit hinzu. Da hast du so kleine Marker neben den Zeilennummern und kannst sagen, welche Zeile dem Commit hinzugefügt werden soll und welche ggf. nicht (Debug Statements anyone?). Alternativ hieß es F4 um die ausgewählte Datei zu öffnen, die Stelle zu finden, zu entfernen (ggf. mehrfach, je nachdem wie wüst die Statements im Code liegen), zu commit und danach gar wieder hinzuzufügen.
Summa summarum bin ich (mittlerweile) vollends(?) eigentlich nur mit der JetBrains Integration zufrieden. Alle anderen IDEs haken da teils extrem hinterher und sehen es nur als "Nice to have" an, obwohl es eigentlich ein integraler Bestandteil eines Entwicklers ist.
Bei NetBeans würde ich auch streiken und die CLI wählen...
Das ist dieses typische "Ach mappen wie mal 1:1 ins GUI was die CLI hergibt. Der User wird das schon fressen." Wahrscheinlich nutzt es im Endeffekt niemand.
Allerdings finde ich ein gewisser Umgang mit der Konsole sollte nicht vernachlässigt werden.