m.fuchs hat geschrieben:Ich habe mal ein neues Thema dafür aufgemacht, weil es sonst zu Off-Topic wird.
Es mag durchaus sein, dass mir da immer noch das Verständnis fehlt warum es GIT sein muss. Auch wenn ich denke, dass mehrere Versuche damit warm zu werden ausreichen sollten. Aber so ein bisschen über den Tellerrand schauen kann ja nicht schaden.
Super Idee das in einen eigenen Thread zu verlagern
m.fuchs hat geschrieben:Also die Aufgabenstellung ist klar. Ich leite die Entwicklungsabteilung und will auf einen Blick sehen können, wenn wer was gemacht hat. Sprich: Minion 1 fummelt an einer File A im Projekt Todesstern rum und committed. Dann brauche ich in kurzer Zeit eine Benachrichtigung dass er das gemacht hat. Ich kann mir dann nämlich überlegen, ob das irgendwelchen Impact hat, den ich mir mit ihm noch einmal ansehen muss.
Ja das kann git nicht Clientseitig, das ist aber by design. Die Idee ist das für alles was über die normale VCS funktion hinaus geht man auf dem server weitere tools bereitstellen muss. Z.B. GitLab. GitLab integriert dann den Git Workflow mit solchen tools.
Ich erzähl mal kurz wie das bei mir auf der Arbeit läuft, wo wir mit GitLab arbeiten. Für alles was wir machen müssen machen wir Issues (tickets) auf. Wenn sich jetzt Minion 1 hinsetzt und ein feature bearbeitet, weist der sich selbst erst mal das Issue zu, damit jeder weis das die Aufgabe vergeben ist, und erstellt einen neuen branch in git (im gegensatz zu SVN hat das keinen overhead). Auf diesem branch fummelt er dann rum, commited wie er lustig ist und pusht dann irgendwann.
Mit dem push kann man auch direkt einen Merge-Request für das entsprechende Feature aufmachen, in dem beschreibt man dann in 2-3 zeilen was der MR macht und schreibt sowas wie "fixes ISSUE" oder so rein, dann wird beim Merge auch direkt das Issue geschlossen.
Solang der MR noch nicht fertig ist steht der auf "WIP", dann kann man ihn nicht mergen und es werden keine benachrichtigungen verteilt. Wenn man mit dem MR fertig ist nimmt man das WIP weg und dann ist er offen für Review.
Beim review kann der Reviewer einfach auf den MR gehen und bekommt dann eine Liste mit allen commits, sowie das diff zum master angezeigt. Man kann dann allgemeine kommentare schreiben oder in den Code gehen und auf eine bestimmte Zeile klicken und da dann was dran schreiben.
Der ersteller des MR's bekommt dann benachrichtigungen (z.b. Mails) für jedes kommentar, und kann sich dann hinsetzten das zu ändern. Wenn er das gemacht hat kommentiert er unter den ursprungskommentaren und der Reviewer bekommt eine Notification. Der reviewer wiederum kann dann sich die änderungen seit dem letzten Review anschauen, und kann seine "Diskussionen" die er gestartet hat entweder schließen, neue kommentare dran hängen oder zu seinen vorrigen kommentaren was hinzufügen.
Sobald sich Reviewer und Minion einig sind, oder so sehr hassen das sie nicht mehr miteinander reden, kann der Merge dann durchgeführt werden (alles über GitLab, der Reviewer braucht das projekt nicht lokal zu haben) und das feature landet auf dem Master branch.
Wenn bei der Diskussion neue sachen aufgekommen sind macht man dafür neue Issues auf und das ganze Spiel fängt von vorne an. Der Master branch sollte dabei dann eh protected sein, das man nur über Merges damit interagieren kann und niemand direkt drauf pusht.
Das ganze kann man dann auch noch so einrichten das jeder MR mindestens N reviews braucht (bei kleineren projekten meistens einen, bei größeren auch gerne mal 2 unabhängige reviews), mit klar verteilten rollen, die der Firmenstruktur entsprechen.
Um jetzt auf deine Situation zurückzukommen, um zu sehen was die Minions gemacht haben kann man also einfach auf GitLab gehen, auf die entsprechenden Projekte und auf Merge-Requests. Oder man stellt sich in GitLab notifications ein, dann bekommt man ne Mail sobald ein MR von WIP genommen wird.
Allein auf grund des massiven overheads von SVN branches macht ein solches vorgehen unter SVN keinen Sinn. Für 2-3 Commits einen eigenen branch zu erzeugen bedeutet halt den kompletten Ordner zu kopieren. Bei einem Projekt wie LLVM also knapp 1 GB.
m.fuchs hat geschrieben:Das ist dann durchaus ein Vorteil sein, wenn man eine schmale Leitung hat. Ebenso wie die Möglichkeit einen Offline-Commit zu machen. Aber für meine Arbeitsweise spielen diese beiden Features keine Rolle. Und dann ist die Frage: was bleibt von den Vorteilen von GIT?
Da du alle informationen lokal hast, und nicht wie bei SVN nur den aktuellen branch und die aktuelle revision, kannst du problemlos dein gesammtes repo navigieren, wenn ein git log mache, sehe ich genau welche branches auf welchem punkt sind, ich kann z.b. sehen mein aktueller branch baut auf dem branch xyz auf, welcher 4 commits von master entfernt ist.
Generell hat git einfach mehr informationen zur verfügung. Der Git-Graph (git log --graph) zeigt dir an wann gebrancht wurde und wann gemerged wurde. Das kommt natürlich auch bei Merges zugute:
Auf der Arbeit entwickeln wir mit Forks einer Open-Source software, wenn jetzt neue features für die Original version (ich nenn sie einfach mal upstream) hinzu kommen, fetche ich den remote (also lade die daten im aktuellen repo runter ohne ein neues repo dafür zu erstellen/auszuchecken) und kann dann einen merge gegen machen. Git an dieser stelle erkenn die commits die zwischen beiden versionen geteilt werden, muss also nur versuchen die dateien zu mergen die jeder von uns separat angepackt hat.
Nicht nur das, wenn in einer der Software dateien umbenannt wurden, erkennt git das auch vollautomatisch und bezieht diese infos dann in den merge mit ein. Wobei ich nicht weiß ob das in SVN mittlerweile auch drin ist, als ichs benutzt hab war das noch nicht drin (ist aber auch ewig her).
Außerdem kann git erkennen wenn du vorher bereits schonmal gegen gieses repo gemerged hast und macht damit subsequente merges einfacher
m.fuchs hat geschrieben:Und damit ist es eigentlich schon draußen, da ist mir das Risiko zu hoch dass irgendjemand was kaputt macht.
Während ich hinter diesem hauptkritikpunkt zwar im grunde immernoch stehe, hatte ich zu dieser zeit noch nicht so sehr mit branches und GitLab gearbeitet. So kann man in GitLab branches protecten (wie z.b. den master branch) dann kann man keine history rewrites mehr drauf machen. Man kann (und sollte) das nur auf den eigenen feature branches machen. Im worst case, wenn man nicht aufpasst, kann man da schlimmsten falls nur seine gesammte arbeit dieses Features (also max 1-2 monate) verlieren. Immernoch schlimm, aber "kaputt" geht da nix, man verliert höchsten kürzlich getätigte Arbeit.
Ich sollte an diesem punkt aber mal ein bisschen erläutern. Git ist nicht nur ein VCS sondern auch ein Dokumentations-tool. Als solches ist es wichtig die Commit historie sauber zu halten. Beispiel du hast ein neues feature entwickelt und auf deinem branch hast du die folgende commit historie:
- Adding feature ... (* lange commit message mit vielen details *)
- Fixing xyz
- Fixing hij
- fixing new bugs due to new hij functionality
- adding tests for NEW Functionality
- turns out xyz was never broken, restoring
- fixing abc
- fixing broken test
- fixing broken test
Wenn jetzt jemand in die Historie sieht sieht er genau 2 relevante commits und 7 irrelevante, beim git blame würden auch ein großteil der Zeilen nur "fixing ..." sein. Das ist auf nem branch ok, auf dem master möchte man das dann aber nicht haben. Also setzt man sich hin und changed die historie, löscht die beiden xyz commits und squashed hij und abc fixes zusammen mit dem "Adding features" commit und die beiden "broken tests" zusammen mit dem "Adding tests ..." commit. Und am ende hat man 2 saubere commits, die dann auf master landen.
Das ist ein oftmals verwendeter workflow mit git der so mit SVN einfach nicht wirklich möglich. Wenn man aber auf eine saubere commit historie verzichtet, braucht man davor keine angst zu haben, da man dann komplett drauf verzichten kann.
Der andere punkt an dem man rebasen muss ist wenn 2 leute gleichzeitig an nem feature in einem branch arbeiten, Feature 1 wird gemerged, dann ist der Feature2 branch auf einem veralteten master. Was man dann normalerweise macht ist gegen master zu rebasen, dabei erkennt git den letzten gemeinsamen commit, und wendet dann alle neuen commits deines aktuellen branches auf den neuen master an. Du ersetzt also den alten master zu dem neuen master als deinen Basis/Historie, daher rebase.
Dabei wird jeder deiner commits die du seit dem alten master gemacht hast neu auf den neuen master applied, und damit kann in jedem einzelnen dieser commits ein konflikt entstehen. Wenn du beim beheben dieser konflikte nicht aufpasst, machst du aus perfectly working code einen haufen garbage. Im Gegensatz zu einem merge gegen master, bei dem alle konflikte in einem Merge-Commit aufgelöst werden, den du reverten kannst, hast du hier deine historie überschrieben und kannst so einfach nicht mehr zurück gehen. Das gesagt ist das problem eher geringer natur weil du nur code kaputt machen kannst der konflikte verursacht hat, also in den meisten fällen nur 2-3 stellen, du kannst also nicht deine ganze arbeit verlieren.
Mein kommentar damals war etwas überspitzt ausgedrückt, zwar stehe ich im Grund noch zu der Aussage das diese designentscheidungen in einem VCS nicht die besten sind, aber man ist eigentlich doch eher fern davon "alles kaputt" zu machen. Zum einen sollte man lokal ja immernoch ein bisschen testen, d.h. wenn alles kaputt wäre, dann würde man das lokal merken und nicht pushen, und eine funktionierende version wäre noch online. Zum anderen gewöhnt man sich ziemlich an, wenn man merkt das ein rebase sehr komplex wird den abzubrechen (kann man machen solang er noch ned durch ist, dann wird der originalstand wieder hergestellt) und erst mal einen backup branch zu erzeugen, auf den man im notfall zurückgreifen kann. Da branching keinen overhead kostet kann man das ganz einfach machen.
Und selbst wenn man alles verkackt hat, und den kaputten rebase gepusht hat, GitLab merkt sich jede Änderung nochmal separat von git wenn ein merge-request offen ist, und solang man sauber mit GitLab MR's arbeitet, kann man eigentlich keine infos verlieren.
Also während ich diese Design-Entscheidung immer noch nicht gut finde, macht sie nicht so viel kaputt.
Zugegeben ein Nachteil ist wenn 2 personen auf dem selben branch arbeiten, und einer rebased den branch und der andere pullt ganz normal, macht git einen merge der alle gerebaseten änderungen wiederherstellt und die Historie noch kaputter macht. Aber merges sind ganz einfach zu reverten, und eigentlich sollte man sich auch an die regel: 1 entwickler - 1 branch halten, sonst kommt man eh in teufels Küche
m.fuchs hat geschrieben:Und ein weiteres Zitat:
[...]
Das wiederum ist (für mich) eben gar kein Argument.
Das war im vergleich zu mercurial, die designtechnisch das ganze einfach besser gelöst haben. Im vergleich zu SVN bietet git einem doch deutlich mehr. Vor allem muss ich mittlerweile auch sagen habe ich den vollen funktionsumfang von GitLab kennen gelernt und auch wenn Git nicht das beste VCS sein mag, die tools die einem GitLab bietet machen eigentlich alle inconviniences von git weg