Github - wie geht's?

Sonstiges Software
41

[QUOTE=Antoras]Bei der Bekanntheit von Git eigentlich erstaunlich, dass es etwas ähnliches nicht auch schon gibt. Vllt. habe ich es bisher auch nur noch nicht gefunden. Aber da die meisten Git Nutzer wohl kein Bedürfnis dafür haben sehen die Chancen dafür u.U. wirklich schlecht aus.
[…]
[/QUOTE]

Naja, gibt es schon. Unter Windows heißt das dann TortoiseGit oder für Mercurial (welches ich verwende) TortoiseHG. Für die gängigen täglichen Aufgaben reichen die angebotenen Kommandos, sonst muss man sowieso auf die Konsole ausweichen.[1] Mit den IDE Plugins für Eclipse oder die eher maue Integration bei IntelliJ schlage ich mich schon gar nicht mehr herum.

[1] Davon abgesehen lernt man die dezentralen SCM sowieso besser über die Konsole bevor man eine GUI verwendet, dass kann man auch über die Tortoise-Tools anstoßen. Und um noch mal dezidiert darauf hinzuweisen, es gibt auch noch andere dezentrale SCM als Git die vll. für die konkreten Bedürfnisse besser funktionieren.

42

@deetee : War bei mir aehnlich, hab ewig gebraucht um das alles zu verstehen und hab zwei Anlaeufe gebraucht.

Auf Arbeit war bei uns das Argument Gerrit. Gerrit geht nur mit Git.

Da arbeitet man an PatchSets, die im Gerrit (Webapp) anguggen kann. Dort sieht man die Aenderungen zu dem PatchSet und kann das kommentieren und so weiter.

Die Sets kannste natuerlich auch erweitern (kann jeder im Team).

Erst wenn das Okay von einigen Kollegen kommt, kann der gesamte PatchSet in den Master gemergt werden. Ein Kollege ist immer Jenkins, der sein Okay gibt, wenn alle Tests laufen.

Somit sind Buildbreaks im Jenkins faktisch unmoeglich.

43

Ich bin glücklicherweise jung genug damit ich mich nie großartig mit SVN (oder gar CVS) rumschlagen musste. Ich wollte irgendwann bei einem OS Projekt contributen, das auf GitHub gehostet ist. Ich war da die ersten zwei Wochen nur damit beschäftigt das mit den commits und branches richtig hinzubekommen (und was in den folgenden Monaten da noch an Zeit draufgegangen ist will ich gar nicht wissen). Hätte ich mit vernünftigen Schulungen mit Sicherheit in einem Bruchteil der Zeit hinbekommen können, aber außer den Hilfen von den anderen Commitern stand mir da nichts zur Verfügung. Keine Ahnung ob sich langjährige Vorerfahrungen mit SVN negativ auswirken. Liegt aber wahrscheinlich nur an der Person und an der Fähigkeit “loszulassen”. Ich empfehle, wenn man Git schon lernen möchte, das nur mit einem größeren Projekt zu tun an dem mehrere Leute arbeiten. Ansonsten braucht man branching nicht und dann dauert es ewig um da dahinterzukommen. Lieber einmal gescheit lernen als sich noch fünf Jahre später damit rumplagen zu müssen.

44

Zum Thema Branching: http://nvie.com/posts/a-successful-git-branching-model/

Es lohnt sich auch alleine in Projekten zu branchen, da sich somit angefangen Features die doch nicht funktionieren auch ganz einfach verwerfen lassen ohne lang rumzufrickeln.

45

Da stimme ich TheDarkRose zu. Branching ist ein allgemeines Konzept und hat nichts speziell mit GIT zutun. Es ist aber leider so, dass ich niemanden kenne, der Branching/Merging mit SVN gerne oder oft nutzt, mich eingeschlossen.

Mit GIT ist das alles so locker und flockig, dass man endlich mal sauber seine Features planen und trennen kann. Man muss natürlich erstmal einen Plan für sein Branching und Merging haben, aber diesen umzusetzen ist mit GIT dann nur noch ein Kinderspiel.

46

Liegt auch daran, das dies bei SVN schwergewichtige Horroraktionen sind. Dazu kommt der Vorteil bei Git das man erst mal nur lokal branchen kann ohne dies je ins zentrale Repository zu pushen.

47

Wir verstehen uns :wink:

Was sagst du zur nicht vorhandenen Benutzerverwaltung bei GIT? Ein Fluch oder Segen?

48

Ein recht aktueller Vortrag zu GIT. Der das ganze sehr plastisch darstellt. Allerdings mit 90 Minuten auch nicht ganz kurz.

Die Folien zu dem Vortrag, die man parallel dazu ansehen sollte befinden sich hier. Da hat infoq etwas geschlampt.

49

Keine Ahnung wie das funktionieren soll. Wie will das VCS Zugriff auf lokale Dateien unterbinden? Funktioniert das nur mit zentralisierten VCS, bei denen alles auf einem Server liegt?

Edit: Ok, funktioniert auch mit dezentralisierten VCS, der Server muss nur verhindern, dass bestimmte Dateien aus- und eingecheckt werden.

50

Nein es wird beim Commit nichts unterbunden, wenn du aber für ein remote repository keinen Zugriff hast wird beim push einfach abgelehnt. Heißt du hast es zwar bei dir eingecheckt aber bekommst es nicht ins hauptrepo

Gesendet von meinem Nexus 7 mit Tapatalk 4

51

[QUOTE=deetee]Wir verstehen uns :wink:

Was sagst du zur nicht vorhandenen Benutzerverwaltung bei GIT? Ein Fluch oder Segen?[/QUOTE]

Fehlende Benutzerverwaltung? Hmm, wär mir jetzt nicht aufgefallen. Gitorious, Atlassian Stash, Gitlab HQ, bei allen ist Benutzerverwaltung ein integraler Bestandteil.

Bei dezentralen Zugriff muss dir der entsprechende User eh Zugang er SSH verschaffen und gelten dann die Dateirechte.

Gesendet von meinem Nexus 7 mit Tapatalk 2

52

Richtig, die nutzen dann gitolite, gitosis oder ähnliches. Das sind Git Extensions. Git hat out of the box keinerlei Rechtekonzept.

Du darfst nicht vergessen, dass nicht alle Firmen ihre Git Repos bei einer Plattform lagern wollen/dürfen.

Das stimmt, hat aber nichts mit Git zutun. Und ist entsprechend aufwendig zu pflegen. Hier muss man auf die genannten Extensions gitolite oder gitosis zurückgreifen. Die bieten eine übersichtliche Rechteverwaltung per Textdatei an, ähnlich wie es bei Subversion auch dabei ist, nur eben out of the box.

Das Problem ist, dass gitosis nicht so ganz einfach zum Laufen zu kriegen ist. Ich finde hier wäre es schön, wenn Git das etwas einfacher lösen könnte, z.B. eine Benutzerverwaltung die man nur noch konfigurieren muss, und sonst einfach funktioniert. So wie Git eben auch.

53

gitosis ist tot. Es lebe gitolite. (Weiß Gott warum.) Falls Unternehmen nicht ihren Code bei GitHub lagern wollen, können sie sich GitHub Enterprise kaufen.
Gruß,
Freak

54

Git ist ein reines SCM und kein Mischmasch wie SVN. SVN ist zentral und daher ist auch eine vereinfachte Benutzerverwaltung gleich mit an Bord, die braucht Git aber nicht, das Konzept dahinter war nämlich ein völlig anderes. Git wird im Normalfall über diese Protokolle verwendet: Git, SSH. Über Git kann man nur klonen, aber nicht pushen. Über SSH sind die nötigen Dateirechte erforderlich und ein SSH-Zugang, sonst geht da auch nix. Damit wird dann auch klar, wie Git mit Rechten umgeht. Torvalds hat es im Google Tech Talk sehr gut deutlich gemacht und er ist auch der Erfinder von Git, auch wenn er nicht mehr aktiv an dem Projekt beteiligt ist (frei übersetzt, kann mich da gerade nämlich nicht genau dran erinnern): “Ich vertraue niemandem! Und jeder, der ein Sicherheitskonzept umgesetzt hat, das anders funktioniert, hat kein Sicherheitskonzept umgesetzt, sondern Sche!ße!” Naja, einige von uns kennen Torvalds und seine Einstellung und sei sie manchmal noch so krass, aber er hat recht. Jeder kann mein Repository klonen wie er lustig ist und in seinem Klon machen, was er will, interessiert niemanden. Will er die Änderungen ins Original einspielen, hat er diese nicht zu pushen, sondern mich zu bitten, dass ich sie mir von ihm ziehe, er muss also ein Pull-Request an mich absetzen. Warum? Ganz einfach, weil ich ihm nicht vertraue und sogar wenn ein Pull-Request abgesetzt wurde, wenn ich es nicht akzeptiere oder annehmen will, dann ist das halt so und nicht mein Problem. So und nicht anders funktioniert das System hinter Git. Vertraue grundsätzlich niemandem und wenn jemand was von einem will, dann soll er fragen und bitte sagen! Mit Gitolite und Co kam eben die Möglichkeit hinzu eine Benutzerverrechteverwaltung für Git-Repositories umzusetzen bzw. einzurichten, damit man auf anderem Wege Schreibrechte vergeben kann, ohne das System mit zusätzlichen Benutzern zumüllen zu müssen und an den Dateirechten rumfummeln zu müssen. Um diese aber nutzen zu können, muss man dann über das jeweilige System, also Gitolite, auf die Repositories zugreifen und nicht mehr direkt, weil sonst die Rechteverwaltung von Gitolite nicht greifen würde.

Wer keine Lust hat Gitolite einzurichten oder zu doof dafür ist, der kann auch gerne GitLab einrichten. Das ist ein GitHub-Klon, der ursprünglich für private Repositories gedacht war und eigentlich auch noch immer ist, aber inzwischen kann man auch public Repositories einrichten. Sieht aus wie GitHub und bietet sehr viele ähnliche oder sogar identische Features und ist klasse.

Nochmal, Git ist zur reinen Versionierung von Dateien, in erster Linie natürlich von Source-Files, gedacht und übergibt oder besser überlässt das Problem mit den Benutzerrechten der einzigen Instanz, die dafür verantwortlich ist, nämlich dem Besitzer. Es greift da nicht ein und funkt auch sonst nicht dazwischen, es erlaubt über das Git-Protokoll zu klonen, verbietet aber das Pushen (Sicherheitsmerkmal) und für alle anderen Protokolle ist der Besitzer des Repositories verantwortlich und ist dann eben selbst schuld, aber niemals Git.

55

Ich fand diesen Link http://nvie.com/posts/a-successful-git-branching-model/ sehr hilfreich.

56

Der war schon im Thread, aber ja ist die ultimative Vorlage geworden - was nicht bedeutet, dass man sie nicht anpassen darf.

57

Ah danke für den Hinweis. Habe (zugegeben) nicht den ganzen Thread gelesen und fand diesen Link schon immer gut. :slight_smile:

58

Der Link ist auch ein guter und das PDF sollte sich eigentlich jeder mal gezogen haben. Gerade für Leute, die von SVN kommen und nicht den Geist von Git wirklich verstehen wollen, ist das eine sehr gute Möglichkeit zu verstehen, was Branches sind, warum Branching und vernünftiges Mergen zentraler und essenzieller Bestandteil von Git sind und wie man das eben effektiv für seine Arbeit nutzen kann und das jeden Tag. So kommen die Leute oft auch leichter von dieser zentralen Denkweise weg und fangen endlich an sich auf ihre Arbeit zu konzentieren als sich zu fragen, wie man den Code den anderen zur Verfügung stellen kann und wo und wann es knallen könnte. Das ist nämlich ein riesen großes Problem bei SVN, es ist nicht in der Lage vernünftige Merges zu bewältigen ohne irgendwo Konflikte zu produzieren. Zumal mich bei SVN diese Abhängigkeit zu einem Server inzwischen aufregt (kaum zu glauben, dass ich SVN mal mochte :D) und darum wird in jedem SVN-Repository, das ich gezwungen bin auszuchecken, ein Git-Repository initialisiert und damit gearbeitet, bis schlussendlich alles wieder ins SVN geschoben wird. Man kann auch Git-SVN benutzen, um mit SVN-Servern zu arbeiten, habe ich eine lange Zeit auch gemacht, aber da muss man auf diverse Dinge achten und vermischt beide Welten nur. So habe ich beides getrennt, aber dennoch im selben Verzeichnis, wobei selbst das nicht sein muss, denn man kann das Verzeichnis .git auch irgendwo anders unterbringen und in der Working-Copy dann einfach mit --git-dir= darauf hinweisen, das geht auch.

59

Git ist zu SVN etwa nicht wie relationale Datenbank gegen NoSQL. Eben ein ganz anderes Denkmuster.

Gesendet von meinem Nexus 7 mit Tapatalk 4

60

[QUOTE=Noctarius]Git ist zu SVN etwa nicht wie relationale Datenbank gegen NoSQL. Eben ein ganz anderes Denkmuster.

Gesendet von meinem Nexus 7 mit Tapatalk 4[/QUOTE]

So ist es und ich fühle mich damit viel wohler :slight_smile: Aber das muss nicht heißen, dass Git kompliziert sei, eher im Gegenteil finde ich. Wie gesagt, ich habe zuerst SVN benutzt, war auch begeistert, war toll und ich muss gestehen, ich habe mich am Anfang, als ich von Git gehört habe, nicht mit dem dezentralen System vertragen können und bin Git fast zwei Jahre aus dem Weg gegangen, wo es nur ging. Irgendwie hatte ich Angst davor, das sah so kompliziert aus und war irgendwie völlig anders. Aber als ich dann mal nach einem Tutorial gesucht habe, weil mich das doch nicht los ließ, und mir in ca. 5min die Grundlagen angelesen hatte und weitere Zeit damit verbrachte über die Philisophie und Konzepte von Git zu lesen (http://git-scm.com/book ist top), fragte ich mich immer mehr, was ich eigentlich an SVN so toll fand. Es dauert natürlich ein paar Tage das alles durchzuarbeiten und mit den tieferen Features von Git klar zu kommen und vor allem all das Wissen zu verinnerlichen, für vieles braucht man sogar durchaus Wochen und Monate, um es wirklich zu verstehen und zu verinnerlichen, aber in meinen Augen lohnt es sich. Und wie gesagt, die Grundlagen sind in 5min angelesen und jeder kann sofort loslegen, da ist wirklich nichts kompliziert. Heute frage ich mich, warum ich Angst davor hatte :smiley: Aber es ist so, Git ist in den Grundlagen sehr simpel und einfach, kann aber sehr komplex werden, wenn die Anforderungen steigen, unterstützt dadurch aber eben auch komplexere Abläufe. Insofern finde ich persönlich es richtig, dass es da keine Benutzerverwaltung gibt. Git konzentriert sich ausschließlich auf das Arbeiten mit den Dateien bzw. dem Repository selbst und die Frage, wer lesen und schreiben darf, gehört an eine andere Instanz übergeben.