Git - GUI oder Kommandozeile?

Sonstiges Spielwiese
1

Ich hatte neulich an der Arbeit eine Diskussion darüber, wie man am besten mit git arbeitet. Ich vertrat den Standpunkt, dass man alle Möglichkeiten mit der IDE ausnutzen sollte - wofür haben wir entsprechende Werkzeuge? Mein Diskussionspartner war der Meinung, dass man git hauptsächlich über die Kommandozeile einsetzen sollte.

Etwas Hintergrund: Ich bin kein git-Guru, ich komme damit einigermaßen zurecht, was normale Operationen angeht. Ich bin sowieso kein Freund der Kommandozeile, und fühle mich einfach sicherer, wenn mir die Optionen angeboten werden, von denen ich dann auswählen kann. Nun wird in meiner Firma auch Wert darauf gelegt, dass die Code-Historie “ordentlich” aussieht, also z.B. vor dem Commit in den Master-Branch zusammengehörende Commits zusammengefasst werden u.s.w. Es müssen auch manchmal Änderungen in ältere Versionen zurückgemerged werden u.s.w.

Die Argumente für git auf der Kommandozeile sind im Wesentlichen Geschwindigkeit und “sonst lernst du es nie richtig”. Ich bin der Meinung, dass git normalerweise gut funktioniert und die grundlegenden Operationen verständlich sind, aber wenn es um irgendwelche obskuren Operationen geht, die nicht dem normalen Workflow entsprechen, git einfach viel zu komplex wird. Ich **will ** gar kein Source-Control-Tool lernen, das so komplex wie eine Programmiersprache ist, wo man wissen muss, welche dreiundzwanzig Schalter es an jedem Befehl gibt, nur um ein paar commits in die richtige Reihenfolge zu bekommen. Das ist auch, was mich verunsichert: Wer sagt mir, dass das, was ich da gerade tippe, nicht das git-Äquivalent zu rm -rf / ist?, weil ich irgend eine Option verwechselt habe? Hinzukommt natürlich der Verlust an Komfort, z.B. wenn ich z.B. nicht graphisch mergen kann. Bin ich der einzige, dem es so geht? Ganz ehrlich, es nimmt mir den Spaß, wenn ich etwas gelöst habe, weil ja dann wieder diese ganze git-Arie ansteht. Mache ich es über meine IDE, klappt es vielleicht, aber wenn ich doch Hilfe brauche, kann ich mir wieder “Warum nimmst du nicht die Kommandozeile?” anhören. :scheiterhaufen:

2

Ich bin ein Fan der git-Console.

Aber auch ich nutze die git-Integration meiner IDE und git-GUI/gitk.

Letztlich ist es das alte Pradigma: nutze das Werkzeug, mit dem Du am schnellsten zum Ergebnis kommst, pass aber auf, dass Du nicht jedes Problem auf ein einen Nagel reduzierst…

[quote=Landei]Die Argumente für git auf der Kommandozeile sind im Wesentlichen […] “sonst lernst du es nie richtig”.
[…]
Ich will gar kein Source-Control-Tool lernen, das so komplex wie eine Programmiersprache ist[/quote]Die schlechte Nachricht: du musst.
Ein Profi kennt nun mal seine Werkzeuge und das SCM ist IMHO nach der Programmiersprache und der IDE eines der wichtigsten.

[quote=Landei;130468]Das ist auch, was mich verunsichert: Wer sagt mir, dass das, was ich da gerade tippe, nicht das git-Äquivalent zu rm -rf / ist?[/quote]An dieser Stelle ist git sogar viele freundlicher als beispielsweise SVN. Deine Aktionen in git sind alle lokal, also wenn Du was falsch gemacht hast löscht Du einfach alles auf deiner Platte und machst einen neuen Clone. Mehr Sicherheit geht nicht. (auch wenn dabei deine Arbeit seit deinem letzten push verloren geht…

[quote=Landei;130468]Hinzukommt natürlich der Verlust an Komfort, z.B. wenn ich z.B. nicht graphisch mergen kann.[/quote]Auch mit der Kommandozeile kann man graphische Merge-Werkzeuge einbinden. Muss man halt erst mal einrichten, ist aber letztlich kein git-Problem in engeren Sinne…

[quote=Landei;130468]Ganz ehrlich, es nimmt mir den Spaß, wenn ich etwas gelöst habe, weil ja dann wieder diese ganze git-Arie ansteht.[/quote]Heißt das, dass Deine Kollegen auch über Deine Erfolge meckern, weil Du die nicht mit der Konsole erzielt hast?

[quote=Landei;130468]Mache ich es über meine IDE, klappt es vielleicht, aber wenn ich doch Hilfe brauche, kann ich mir wieder “Warum nimmst du nicht die Kommandozeile?” anhören.[/quote]Genau hier schließt sich der Kreis.
Die git-Konsole ist “der kleinste gemeinsame Nenner”.

Du selbst hast geschrieben, dass Du Dich nicht mit der Konsole auseinandersetzen willst.
Wieso erwartest Du dann, dass Deine Kollegen sich ausgerechnet mit der von Dir ausgesuchten GUI auskennen?

Und nein: der Umkehrschluss, dass die Anderen von Dir nicht verlangen dürfen, mit der git-Konsole arbeiten zu können ist nicht zulässig, weil die Konsole eben das eigentliche System ist. Die Meisten GUIs rufen nämlich einfach die git.exe für Dich auf oder sind Nachimplementierungen mit eigenen Fehlern und Inkompatibilitäten.

bye
TT

3

Ich habe bei mir festgestellt, dass ich mit einer Mischung aus beidem arbeite. Für kleinere Sachen benutze ich die Konsole, da ein git commit -m "Blablabla" für mich einfacher ist als Rechtsklick->Git->Commit->Popup Fenster->Text eingeben->Commit klicken, ebenso für git push .... Für größere Sachen, wie z.B. Merges und Rebases bin ich froh über die visuelle Unterstützung die mir (in meinem Fall) Sourcetree bietet. Ebenso für Branchwechsel, das ist auf der GUI mit einem Doppelklick erledigt, da muss ich mir die Konsole nicht antun. Bei Projekten wäre ich da pragmatisch, solange niemand Mist baut soll er doch die Tools benutzen mit denen er am sichersten ist.

Das Thema ist aber auf jeden Fall spannend, wir sind gerade dabei die interne Versionsverwaltung unserer Firma auf Git umzustellen und ich werde für die Juniors eine kleine Einführung machen müssen. Ich denke diese Einführung von der Konsole aus aufzubauen und danach erst die graphischen Tools einzuführen wäre nicht verkehrt.

4


Nutze meist Kommandozeile, manchmal Sourcetree und selten die IDE.

Man sollte es jedem selber überlassen wie man committen/mergen/rebasen/squashen/pushen möchte IMHO

Die Kommandozeilen UI von git ist 'ne Katastrophe, komme mittlerweile aber gut mit zurecht.

Erst letztens gelernt:
git checkout -

5

Da bin ich mit der entsprechenden IDE schneller. Einfach in IDEA CTRL+K und ab geht es. Kannst direkt mit sagen, ob auch gepusht werden soll.

Wenn die IDE das vernünftig unterstützt, nutze ich persönlich die IDE. Mit der Konsole kann ich mich schon länger nicht mehr anfreunden. :slight_smile:

*** Edit ***

[QUOTE=maki;130473]Erst letztens gelernt:
git checkout -[/QUOTE]
Kannte ich auch noch nicht. Danke :smiley:

6

Ah, endlich mal wieder ein git bashing-Thread :smiley:

Rant
[spoiler]

Vorneweg: Bestimmte Ideen und Konzepte, die hinter GIT stecken, sind gut (und notwendig). Aber GIT an sich ist schlecht. Egal, ob man es als „Domänenspezifische Programmiersprache zum Ansteuern einer SCM-Library“, „Tool“ oder eine Art „API“ ansieht: Die Schalter und Optionen und Befehle sind inkonsistent auf Funktionalitäten abgebildet. Die einfachsten Dinge sind absurd kompliziert (etwa 8 der 15 höchstbewerteten Fragen auf StackOverflow sind Fragen dazu, wie man lächerlichST triviale Dinge mit GIT macht (alle dohf, außer Linus :rolleyes: )). Die Fehlermeldungen hören sich schon fast „lustig“ an - zumindest für Außenstehende, solange man sich nicht selbst darüber ärgert (wenn etwa beim Versuch, zu mergen, eine Meldung kommt nach dem Motto: „Du kannst nicht mergen, du musst erst mergen“ :verzweifel: )). Dass etablierte Begriffe aus anderen SCMs plötzlich eine neue Bedeutung haben, oder neue Begriffe eingeführt werden, bei denen man darüber streiten könnte, ob sie geeignet sind, um das zu beschreiben, was dort eigentlich gemacht wird, kommt als I-Tüpfelchen oben drauf. Das ganze kann auch nicht damit gerechtfertigt werden, dass Git „dezentral“ ist. Dass jeder eine Kopie des kompletten Repositories auf seiner Platte hat, heißt nicht, dass es nicht doch ein zentrales Repository gibt (und das IST ein zentrales Repository, auch wenn man ihm kreativ-verschleiernde Namen wie „tracked remote master upstream branch“ gibt). Last but not least: Die Manpages sind ein Witz. Ein klassischer Fall davon, dass jemand ein Tool geschrieben hat, und dann auf einmal gemerkt hat: „Mist, ich muss ja doku dazu schreiben“. Wenn GIT nicht von jemandem stammen würde, den eine riesige Community als Ikone verehrt und dem sie unreflektiert folgt, sondern von, sagen wir mal ganz polemisch: Microsoft, dann würden genau die Leute, die jetzt GIT in den höchsten Tönen loben (zu Recht) sagen, wie crappy es ist.

[/spoiler]

Zur eigentlichen Frage: Eine unstrukturierte Mischung aus Kommandozeile, https://tortoisegit.org/ , den Funktionen auf GitHub und git gui.

  • Um zu sehen, was Sache ist, ein git status
  • Auch mal ein git clone github/BlaBla um ein repo auf der Festplatte zu haben (das ich vorher auf GitHub per Mausklick erstellt habe :rolleyes: ).
  • Sowas wie ein (optimistisches) git pull oder ein (realistisches) git fetch --all passiert auch an der Kommandozeile
  • Um lokale Änderungen zu erkennen, verwende ich auch TortoiseGit
  • TortoiseGit auch um Dateien als „Merged“ zu markieren, oder venünftig zu vergleichen.
  • Für den „normalen“ commit/push-Teil verwende ich git-gui (mehrzeilige commit-Messages an der Kommandozeile eintippen ist frevelhaft).
    EDIT> - Meinen Namen in die git config eintragen mache ich ganz professionell: Händisch, mit einem Texteditor, per copy&paste aus einer anderen git config :smiley: <EDIT

Sowas wie SourceTree hatte ich zwar mal kurz aufgemacht, aber … war dann erstmal erschlagen. (Tipp an GUI-Entwickler: Für ein Kommandozeilentool mit 200 Befehlen ein GUI mit 200 Buttons zu erstellen ist FIAL). Aber ich schließe nicht aus, dass man damit vernünftig arbeiten kann, wenn man sich in einem Greenfield/Sandbox-Projekt gefahrlos darin einarbeiten kann.

Schließlich und endlich: Eine IDE-Integration verwende ich überhaupt nicht.

(Das ganze ist natürlich hochgradig ineffizient und insgesamt ziemlicher Murx, aber … solange es kein Tool gibt, mit dem alles, was man tächlich braucht, „gleich gut geht“, und das eine echte Abstraktion auf den über-komplizierten Kommandozeilen-Wust bietet, muss man sich eben irgendwie behelfen).

EDIT2: https://git-man-page-generator.lokaltog.net/ :smiley:

7

Aber dieser kleinste Nenner ist einfach crap. Ich sehe ja durchaus die technologischen Vorteile von git, aber die Abbildung auf Befehle ist einfach bescheiden gelöst.

Mal ein Vergleich von SVN zu git:

( 10 things I hate about Git | Steve Bennett blogs )

Sicher, der Vergleich ist nicht ganz fair, aber muss es wirklich so kompliziert sein, wenn in 99% der Fälle ein Workflow ähnlich wie in SVN vorliegt? Muss ich mir im 21. Jahrhundert merken, was der Unterschied zwischen commit und commit -a ist? Und das Diagramm ist eigentlich noch zu harmlos, es fehlen ja Dinge wie cherry-picking, squashig u.s.w.

Der Artikel von dem die Diagramme stammen ist übrigens lesenswert, da steht z.B., dass meine Befürchtung, unbeabsicht den Master zu nuken kein Hirngespinst ist:


git add . / … / git push -f origin master
git push origin +master
git rebase -i <some commit that has already been pushed and worked from> / git push

Ich würde keiner der Varianten ansehen, dass sie gefährlich ist.

8

Der Bildvergleich ist blöd und gilt nur, wenn man Forken muss. Wenn man gemeinsam an einen Repo arbeitet, dann macht man keine Forks. Auch is in diesem Bild das lokale Repo und die stage extra kompliziert dargestellt…

Ich hab bei uns in der Firma allen Sourcetree beigebracht und sie kommen gut damit zurecht. Die stage ist da gut grafisch abstrahiert und funzt. Ich selbst nutze git fast komplett in phpStorm, inkl. Git Flow. Nur pullen von upstream (bei forks) und rebase interactive benutze ich die Konsole. Wobei wenn ich gerade wegen composer oder so auf der bash bin, dann geht dort auch mal ein checkout und co ^^, weil mans ja weiß :slight_smile: Die Kollegen/Kolleginnen kommen mit dem Unterschied lokales Repo und git-Server gut zurecht, das man neben Commiten eben auch pushen muss.

*** Edit ***

[QUOTE=Landei]da steht z.B., dass meine Befürchtung, unbeabsicht den Master zu nuken kein Hirngespinst ist:


git add . / … / git push -f origin master
git push origin +master
git rebase -i <some commit that has already been pushed and worked from> / git push

Ich würde keiner der Varianten ansehen, dass sie gefährlich ist.[/QUOTE]
Nach einen rebase ist nur ein force push möglich und GitLab als auch bei GitHub lässt sich ein Branch schützen um force pushes zu verhindern. Und auch wenn es mal passiert, kann man den alten Stand (wenn auch umständlich) wiederherstellen.

9

[quote=Landei]Sicher, der Vergleich ist nicht ganz fair[/quote]Stimmt, es ist nicht fair einen Hammer mit einer Bohrmaschine zu vergleichen. ;o)

[quote=Landei;130480]Aber dieser kleinste Nenner ist einfach crap. Ich sehe ja durchaus die technologischen Vorteile von git, aber die Abbildung auf Befehle ist einfach bescheiden gelöst.[/quote]Na los: dann zeig mal Deine Gegenvorschläge…

[quote=Landei;130480]Muss ich mir […], was der Unterschied zwischen commit und commit -a ist?[/quote]kurz: ja.
Oder Du verzichtest eben auf die Möglichkeit, Änderungen nachträglich zu einem Commit hinzuzufügen.

Diese Meckerei ist etwa auf dem Neveau dem Autohersteller die Designkompetenz abzustreiten, weil es einen ESP-Schalter im Cockpit gibt, den doch nie jemand braucht…

[quote=Landei;130480]aber muss es wirklich so kompliziert sein, wenn in 99% der Fälle ein Workflow ähnlich wie in SVN vorliegt?[/quote]Ja, weil die Schnittstelle eben alle Vorgänge und nicht nur 99% supporten muss.

Und wenn dir SVN reicht, dann nimm doch das…

Ich bin fest der Überzeug, das gerade Leute wie Du am lautesten schreien, wenn eine Software irgend ein Featrue nicht hat…

bye
TT

10

git commit -a ist etwas völlig anderes als git commit --amend

q.e.d.

11

… und ein git pull --rebase ist etwas völlig anderes als git pull…

Aber das ist bekannt, das git UI ist 'ne Katastrophe, inkonsistent, ein zus. Parameter macht aus einem Befehl etwas völlig anderes usw.

Trotzdem finde ich dass es das beste SCM ist was die Features angeht, wer mal mit hq gearbeitet hat freut sich wie branches in git funzen.

Nebenbei, git selber wird auch mit git verwaltet, aber keine merges, sondern Cherrypicking…

12

Also wenn sich einer mal was grausliches mit Git sehen will, schaut euch mal den TYPO3 Contribution Workflow mit Gerrit an. Pullen vom upstream, pushen immer in ein neues refs, ohne hooks kann man gar nicht arbeiten, das review wird dan cherrypicked und verliert komplett den Kontext… Grauslich.

13

Sehe ich genau wie dein Kollege.

Aber wie du richtig sagst, „normalerweise“ funktioniert es gut in der IDE. Aber wehe es gibt Probleme … Ich musste dann immer auf die Kommandozeile ausweichen. Mit meld als Diff-Tool funktioniert das einwandfrei.

Letzte Woche habe ich noch > git add -i entdeckt. Der Interaktivmodus ist echt eine spannende Sache da der das Unstaging erleichtert.

Ich werde noch auf der Konsole bleiben obwohl gerade von Atlassian mit SourceTree ein Spitzenprodukt puncto GUI für Git gebaut wurde. Aber das habe ich auch nur so lange verwendet bis ich auf Linux umgestiegen bin. Dort habe ich die Konsolenhandhabung gelernt und bin trotz meines Umstiegs auf OSX - wo es SourceTree verfügbar gäbe - noch nicht auf die Idee gekommen wieder das zu verwenden.

14

Hab jetzt das letzte nur überflogen, aber sehe das auch eher wie Landei. Ich kompiliere meine Applikation ja auch nicht auf der Kommandozeile. Wenn ich die Werkzeuge habe, wieso nicht auch nutzen? Habe ja alles in intellij drin was ich brauch. Wobei ich auch manche Sachen auf der Konsole mache (eben wenn es config-projekte sind, die nicht zu einem intellij-Projekt gehören). Was ich auch auf der Konsole regle ist, wenn ich Dateien umbenenne. Das handling dafür ist in intellij katastrophal - die Änderungen die bei den Kollegen ankommen sind schlicht falsch. Aber letztendlich würde ich sagen: 90% von git manage ich mit Intellij.

15

Das Tooling in IntelliJ finde ich furchtbar. Bei mir waren es eher 60% die ich damit handlen konnte. Aber sobald es um’s mergen ging hatte ich dauernd Probleme. Einmal wurde sogar die Git-History zerschossen!

Seit ich auf der Konsole unterwegs bin hatte ich so ein Problem nicht mehr.

16

Gerade das merge-tool finde ich echt prima. Habe damit jetzt noch keine Probleme gehabt und find es eher praktisch, da mir noch so Sachen angezeigt werden wie z.B. unused imports (was man dann gleich mitbehandeln kann). Und auch das einleiten vom mergen geht flott von der Hand (Strg + V, 7, branch wählen -> merge).

Aber bei den GIT-Tools wundere ich mich doch schon, warum die in Intellij nicht wirklich zu den ausgereiften Tools gehören.

17

Beruflich nutze ich Mercurial, und verwende hierfür hauptsächlich TortoiseHG (GUI). Für einfache Sachen, wie commit oder annotate nehme ich auch gerne IntelliJ. Die Konsole nutze ich in absoluten Ausnahmefällen.

Ich habe eine GUI, in der ich mit einem Klick pullen/pushen kann, die Commit-History konstant sehe, die aktuellen Änderungen im Working Directory aufgelistet werden, und und und… Und dann soll mir ein Konsolenjunkie erzählen, das sei unproduktiv und HG nur mit Konsole bedient werden sollte? Sorry, so eine Person könnte ich einfach nicht ernst nehmen. Jeder muss selbst die passenden Tools für sich finden, aber die “wenn du XXX nicht nutzt, dann bist du halt scheiße”-Mentatlität unter Entwicklern geht so gar nicht.

Git nutze ich nur privat, und nicht kollaborativ, d.h. 95% “commit + push”, also bleibe ich fast nur in IntelliJ. Strg + K, dann werden alle Änderungen aufgelistet die ich noch mal überprüfen, einzelne Dateien evtl. abwählen und diverse Tools durchlaufen lassen kann (Formatting, TODOs überprüfen, Warnings-Suche etc). Wieso sollte ich denn bitte schön hierfür die (für mich) umständliche Konsole nehmen? Der einzige Grund sind für mich Befehle, die mit der GUI nicht ausführbar sind. Dann greife ich in den seltenen Fällen halt zur Konsole.

Übrigens, ich habe gestern eine neue cross-platform Git-UI entdeckt (aber noch nicht ausprobiert): GitKraken (Beta)

18

Hallöle,

also ich persönlich habe vor einigen Monaten mit Git angefangen, und zwar von Grund auf mit einer graphischen Oberfläche (SourceTree, ein feines Programm!). Ich habe einen Vortrag zur GitKonsolenbedienung besucht und weiß formal, wie ich mir in der Konsole bei leichten mit mittelschweren Problemen behelfen kann.
Einige Anspruchsvolle Sachen kann ich so aber nicht lösen, bin bisher aber noch nicht in die Situation geraten, dass meine IDE dazu etwas nicht kann.

Getreu dem Motto: Wenn man Programme hat, die was vereinfachen, muss man es ja nicht selbst programmieren. :wink:

19

Ich benutze die Eclipse integration von git ganz gerne um commits fertig zu machen.
Message Ändern, Committer und Author ändern, nochmal die Dateien durchschauen (doppelklick gibt direkt den compare-view - luxus im vergleich zur konsole). Ein einfacher push geht auch noch.
Für größere Sachen gehe ich lieber in die Konsole. Liegt aber zum Teil auch daran, dass ich manche Sachen in der IDE einfach nicht finde oder nicht beherrsche…

20

Fossil als SCM sieht ganz interessant aus. Habe es noch nicht probiert, aber ich finde, es etwas hat, Wiki und Ticketverwaltung in das SCM zu integrieren. Man erspart sich viel Konfiguration, da es nicht mehr notwendig ist, ein Single Sign On zu konfigurieren.