Github Linux GUI Client?

[fail]

Benutzt ihr auf Linux git von der Kommandozeile aus für Github. Gibt es bessere Alternativen mit einer grafischen Oberfläche oder muss ich mich einfach daran gewöhnen die Kommandozeile zu benutzen?

[EyDu]

Gerade bei einer Versionsverwaltung ist eine grafische Oberfläche doch meistens unpraktisch. Die Befehle sind doch schneller geschrieben als irgendwie angeklickt. Gewöhne dich einfach an die Konsole, das gehört zum Programmieren dazu. Viele Dinge gehen so deutlich schneller als mit einer GUI. Je seltener du die Hände vom Keyboard nehmen musst, desto besser.

[jerch]

@fail:
Ganz klar Kommandozeile, selbst unter Windows finde das praktischer (mit dem offiziellen cmdline-Client von git). Einzig fürs Codebrowsen in den Commits/Branches nutze ich einen Repobrowser, da man dort schön schnell mal eben durchnavigieren kann.

[snafu]

Mach ich genau so: Commit mit ``git commit -am 'Mein Text'``, dann ggf nochmal via ``gitk`` angucken, was man verändert hat (weil mir manchmal mehr Veränderungen reinrutschen als erwartet und ich es einfacher finde, Commits über die GUI rückgängig zu machen) und dann ein abschließendes ``git push origin master``. Wobei man die Änderungen ja auch schon vor dem Commit angucken kann. Das wird einem dann als lokale Änderung angezeigt.

Achja, und es gibt noch ``git gui``, womit man eine grafische Oberfläche erhält. Nicht die hübscheste, allerdings schön funktional.

[mutetella]

Geht jetzt ein wenig am Thema vorbei, aber mich beschäftigt das gerade selbst: Weshalb benutzt ihr nicht Mercurial? Weil auf github mehr los ist als auf Bitbucket oder gibt es andere Gründe (auf Arbeit bereits vorgegeben etc.)?

mutetella

[snafu]

Ich nutze ``git`` wegen Github. Und Github nutze ich, weil es meiner Meinung nach inzwischen das führende Portal zum Bereitstellen von OpenSource-Code geworden ist. Eli Bendersky (den Namen kennt vielleicht manch einer) hat erst kürzlich etwas treffendes dazu gebloggt (hier), wo er auch die soziale Komponente bei Github erwähnt.

[jerch]

Bei uns kams im Team zu git, weil einer das gut kannte und die Argumente überwältigend waren. Das war so 2009, wenn mich nicht alles täuscht. Nach einer Umstellungsphase von etwa einem halben Jahr waren wir auf git, nur noch ein paar svns kullerten darum, welche später von git "durchgeschrieben" wurden. Und inzwischen hat sich git so tief in die tool chain eingegraben, dass das nur mit großem Aufwand rauszulösen wäre (tatsächlich kam die Frage zweimal auf).
Github/bitbucket hab ich alles erst später kennengelernt bzw. als wichtig wahrgenommen.

[BlackJack]

Wobei diese Führungsrolle auch ihre Schattenseiten hat. Beitrag von jemanden der (auch) GitHub nutzt: http://nedbatchelder.com/blog/201405/gi ... lture.html

[snafu]

Nach einer Umstellungsphase von etwa einem halben Jahr waren wir auf git

Scheint ja fast so schlimm wie Crystal Meth zu sein...

[snafu]

Wobei diese Führungsrolle auch ihre Schattenseiten hat. Beitrag von jemanden der (auch) GitHub nutzt: http://nedbatchelder.com/blog/201405/gi ... lture.html

Ja, manche Leute müssen es wie immer übertreiben und alles auf ein Pferd setzen. Solche Leute gibt es leider überall. Wenn die Bewerberauswahl ausschließlich über das Github-Profil des Bewerbers geschieht, dann ist das schon sehr traurig. Ich hoffe aber doch mal, dass die allermeisten Firmen dies nur als einen Aspekt von vielen bei der Bewertung von Bewerbern ansehen.

Was die angerissen Vorteile alternativer Tools angeht: Ich glaube, für viele Leute sind diese zusätzlichen Funktionen (genannt wurde ja z.B. besseres Code-Reviewing) eher zweitrangig. Oder sagen wir mal so: Es wäre schon cool, diese Dinge auch auf Github oder in ``git`` selbst zu finden. Aber es müssten schon ziemlich bedeutende Vorteile sein, als dass man dafür seine Github-Präsenz aufgeben würde. Ist so ein bißchen wie der Wechsel von Python 2.7 auf Python 3.x.

[BlackJack]

Vielleicht noch als anekdotischer Datenpunkt wie ich zu Mercurial gekommen bin: Als ich von Subversion auf ein DVCS wechseln wollte weil ich an mehreren Rechnern (zuhause, Laptop, Uni/Büro) am gleichen Quelltext arbeiten musste, war Git noch ein Haufen gruseliger Shell-Skripte und unter Windows, was leider im Betriebssystem-Mix mit enthalten war, ganz schrecklich zu installieren, und Mercurial war ganz einfach zu installieren und benutzt Python. Also eigentlich war das gar keine richtige Entscheidung.

[mutetella]

Ein Drama meines Lebens: Einerseits möchte ich auch das Coole, das alle nutzen, weil es eben cool ist. Andererseits steckt diese "Jute-statt-Plastik" Mentalität so sehr in mir, dass ich mich dann meist gegen den Mainstream entscheide, im (Irr-?)glauben, damit etwas für einen gesunden Ausgleich zu tun. Bei solchen Dingen beneide ich ein wenig die Jüngeren mit ihrer "mir-doch-egal" Einstellung...

Ich werd' wohl bei Bitbucket bleiben, auch wenn ich immer wieder mal neidenden Auges zu GitHub 'rüberschiel...

Ok, dieses Gejammer von mir musste jetzt und sofort raus...

mutetella

... anekdotischer Datenpunkt ...

Sowas findet man aber auch nur in Programmierforen...

[fail]

@mutetella Weisst du wieso ich Firefox benutze statt Chrome? Weil ich nicht wollte das Google das Monopol im Bereich Browser hat

[mutetella]

@fail
Was immer wir auch tun: Die Karawane wird weiterziehen...

mutetella

[apollo13]

Geht jetzt ein wenig am Thema vorbei, aber mich beschäftigt das gerade selbst: Weshalb benutzt ihr nicht Mercurial? Weil auf github mehr los ist als auf Bitbucket oder gibt es andere Gründe (auf Arbeit bereits vorgegeben etc.)?

Weil branching und die staging area in git so viel mächtiger sind imo, github hilft natürlich auch…

[BlackJack]

@apollo13: In wie fern mächtiger? Ich weiss das Mercurial früher branching stiefmütterlich behandelt hat und klonen vorgezogen hat, aber mittlerweile ist auch branching möglich/üblich. Und die staging area zum Beispiel im Vergleich zu shelve in Mercurial? Was verpasse ich da konkret? Vielleicht mag mich ja jemand zu Git überreden.

[jens]

Zur Ursprungsfrage: Ich nehme immer gern git-cola... Da ich meist nur einen Teil der Änderungen in einem commit packe. Außerdem Praktisch zum zurück machen von Teil-Änderungen.

[mutetella]

Wenn wir schon gerade dabei sind: Wie handhabt ihr das eigentlich mit diesen "das probier' ich mal aus" Änderungen? Ich meine, diese Dinge kommen ja potentiell nie im Hauptzweig an. Macht ihr da trotzdem einen Zweig auf den man, wenn's Blödsinn war, nicht mehr los wird oder einen Klon, der schnell entsorgt ist (siehe Batchelder's Blog, Stichwort 'resume')?

mutetella

[snafu]

@mutetella: Wieso wird man den Zweig nicht mehr los? Weißt du nicht, wie man Branches löscht oder hat es bei dir andere Gründe, dass du dich Branches später nicht mehr entledigen kannst?

Ich entwickle in meinem Solo-Projekt "shcol" übrigens kreuz und quer. Eine strukturelles Vorgehen mit Branches und/oder Milestones gibt es bei mir nicht. Falls sich mal Mitstreiter bei dem Projekt dazugesellen wollen, dann ändert sich das sicher mal. Aber momentan halte ich mein Vorgehen für angemessen.

[mutetella]

@snafu
Bis gerade eben kannte ich ``hg strip`` noch nicht...

mutetella