da bei uns in der Firma größere Wartungsarbeiten am svn-Server anstehen wurde einfach mal in den Raum geworfen, ob wir nicht stattdessen direkt auf git umsteigen. Da ich mich privat immer mal wieder ein bisschen mit git beschäftigt habe, habe ich das zum Anlass genommen, mich tiefer einzuarbeiten. Ich habe zwar nach wie vor nicht produktiv mit git gearbeitet, aber ich glaube, dass ich inzwischen ein ganz gutes theoretisches Verständnis über das Arbeiten mit git und den Begriffen habe.
Eine der wichtigsten Entscheidungen für den Umstieg scheint mir momentan noch die Repository- bzw. Verzeichnisstruktur. Da fehlt mir allerdings noch das Verständnis und ich bitte um Tips.
Folgende zwei Fragen habe ich:
Wie bilde ich unsere vorhandene Repository-Struktur sinnvoll in git ab?
Ich konnte mit dem Eclipse-Plugin egit Code von einem testbranch in den masterbranch pushen. Kann man das verhindern?
Das hatte den Vorteil, dass man ein großes Repository in Eclipse angelegt hat und sich dann über die Repository-View die notwendigen Projekte einzeln ausgecheckt hat.
Wie würde man das sinnvoll in git abbilden? Vor allem im Hinblick darauf, dass die svn-History auch migriert werden soll eek Wenn ich es richtig verstanden habe ist die Empfehlung, pro Eclipse-Projekt ein git-Repository anzulegen. Da kann ich mir im Moment aber schwer vorstellen, wie man da den Überblick behält. Wenn ein ein neues Eclipse-Projekt angelegt wird, muss dann jeder Entwickler ein neues Repository anlegen? Klingt für mich im Moment nicht wirklich produktiv ?( Gelesen habe ich noch von submodules (allerdings nicht empfohlen) und subtrees. Ist das wirklich eine Alternative? Oder wie wird das bei euch gehandhabt?
Bei der zweiten Fragen geht es darum, dass ich über das egit-Eclipse-Plugin versucht habe, git absichtlich falsch zu bedienen. Dabei wollte ich z.B. Änderungen eines testbranches in den master-branch des Remote-Repositories pushen. Das scheint mir auch gelungen zu sein. Ich habe auch das Gefühl, dass ich dabei inkonsistente Zustände erhalten habe (Unterschiede zwischen lokalem Repository und dem Remote-Repository). Leider kann ich nicht 100% beschreiben, was ich gemacht habe und ich kann es auch nicht wirklich nachstellen Aber ich probiere es mal:
[ul][li]Eclipse-Projekt aus einem remote-Repository geclont
[/li][li]In Eclipse einen testbranch angelegt und commited
[/li][li]Testbranch ins remote-Repository gepusht
[/li][li]Änderung im testbranch gemacht und commited[/ul]
[/li]
Bis hier hin alles ganz normal. Aber beim nächsten push (Team → Remote → push…) habe ich „versehentlich“ den testbranch in den master-branch des remote-Repositories gepusht (siehe Screenshot)
Kann man das verhindern? Was passiert da im Hintergrund? Welche Konsolen-Befehle werden da ausgeführt? Können dadurch unterschiedliche Zustände in den verschiedenen Repositories entstehen?
Es geht mir nicht um eine Diskussion pro/contra git. Ich habe nur die Überlegungen in der Firma zum Anlass genommen, mich selbst intensiver mit git zu beschäftigen. Viel weiter als “in den Raum geworfen” sind die Überlegungen in der Firma noch nicht. Speziell die Frage nach der Repository-Struktur hatte ich mir schon viel früher gestellt und es interessiert mich wirklich.
[quote=Calvin]Bis hier hin alles ganz normal. Aber beim nächsten push (Team -> Remote -> push…) habe ich “versehentlich” den testbranch in den master-branch des remote-Repositories gepusht (siehe Screenshot)[/quote]Das hat funktioniert, weil dein Testbranch sich per “Fast Foreward” in dem Master mergen lässt. Wenn es im Master schon andere Commits gegeben hätte ware die Aktion von git verhindert worden bzw. hätte ein -f (force) erfordert.
[quote=Calvin;95567]Kann man das verhindern?[/quote]ja, wenn man einen “echten Server” wie beispielsweise gerrit einsetzt. gerrit hat noch weitere Vorteile. Einer davon ist sein eigentliches Aufgabengebiet: Unterstützung von CodeReviews.
Ein Anderer ist, dass push und fetch/pull deutlich schneller sind, als gegen ein Repository auf Verzeichnisbasis.
[quote=Calvin;95567]Was passiert da im Hintergrund?[/quote] in dem konkreten Fall?
Dein Testbranch ist ein direkter Nachfahre von origin/master auf dem remore-Repository ist nicht bekannt, dass Du in Deinem lokalen Repository einen neuen Branch angelegt hast. Beim Pusch stellt also git fest, dass die gepuschten Commits “legale” Nachfahren des Masters sind und akzeptiert sie als neuen Stand des Masters, unabhängig davon, wie der Branch in Deinem lokalen Repository hieß. In git sind Branch-Namen nur Schall und Rauch, was sich auch darin ausdrückt, dass man diese (auch im remote-Repository) beliebig ändern und verschieben kann. Einzig die Commits selbst sind “heilig”.
Das direkte puschen nach origin/master hätte (wie gesagt) nicht funktioniert, hätte der origin/master schon weiter Commits gehabt, seit Du Deinen Branch erzeugt hast. In dem Fall hättest Du erst ein fetch machen und anschließen mit origin/master mergen müssen. Danach hätte der Pusch direkt nach origin/master wieder funktioniert.
[quote=Calvin;95567]Können dadurch unterschiedliche Zustände in den verschiedenen Repositories entstehen?[/quote]Soweit es die Commits selbst (und deren Inhalte) angeht: nein (solange keiner mit -f im remote bestehende Commits löscht).
Aber die Namen der Branches können sich unterscheiden.
in unserem Projekt haben wir eine Jenkis-Server, der die Branches der einzelnen Entwickler in den Master merged. jeder Entwickler puscht auch immer nur in “seinen” Branch wenn er eine Teilaufgabe erledigt hat. Das funktioniert ziemlich gut.
Da hatten wir vor kurzem eine Diskussion in der Arbeit auf Basis dieses Diagramms: Wie geht man mit dem Fall um, das man an einem Feature-Branch arbeitet dessen Entwicklung sich über Wochen streckt? Mit SVN würden wir den Branch ganz normal anlegen und dann jeden Tag von Head einen Merge machen damit es am Ende nicht zu einem Big-Bang kommt.
Wie geht man mit solchen Abläufen in Git „richtig“ um? Ständig re-basen ist ja nicht Git-like soweit ich das verstanden habe.
Man kann rebasen, wenn man alleine daran arbeitet, das macht ja dann nichts. Ansonsten einen sauberen --no-ff merge vom master/develop in den Feature Branch.
[quote=schlingel]Mit SVN würden wir den Branch ganz normal anlegen und dann jeden Tag von Head einen Merge machen damit es am Ende nicht zu einem Big-Bang kommt.[/quote]das macht man mit git genau so.
ob man das dann mit einem echten merge oder einem rebase macht ist ehr Geschmackssache…
Wenn ein ein neues Eclipse-Projekt angelegt wird, muss dann jeder Entwickler ein neues Repository anlegen? Klingt für mich im Moment nicht wirklich produktiv ?( Gelesen habe ich noch von submodules (allerdings nicht empfohlen) und subtrees. Ist das wirklich eine Alternative? Oder wie wird das bei euch gehandhabt?
Aber ich probiere es mal: