Frage zur Versionsverwaltung mit git

[The_Unknown]

Heyho,

ich habe hier ein Projekt zu betreuen und arbeite dabei zum ersten Mal mit git. Und zwar gibt es einen master-Branch und einen beta01-branch, welcher den aktuellen Stand auf dem Kundenrechner darstellt (ist aber noch nicht wirklich produktiv, eher halt beta-Status ). Im master-Branch kommen neue Features rein. Ab einem bestimmten Zeitpunkt wird dann vom master-Branch ein neuer beta-Branch gezogen, der dann auf dem Kundensystem eingespielt wird. In den beta-Branch kommen Bugfixes.

Da das mein erstes größeres Projekt ist und ich auch mit git noch nicht *die* Erfahrung habe. Macht dieser Aufbau eurer Meinung nach Sinn oder wäre ein anderes Branching sinnvoll?

Und dann noch eine Frage: Wenn ich jetzt ein paar Bugfixes gemacht habe, die sich mit dem master-Branch "vertragen", wäre es dann möglich, mit einem "git merge beta01" im master-Branch diese Änderungen zu übertragen? Da stellt sich für mich nämlich die Frage, inwieweit dann im master-Branch bearbeitete Dateien, die im beta-Branch noch nicht bearbeitet sind, wieder durch den alten Stand überschrieben werden.

Ich hoffe, ihr könnt mir da einen Rat geben Danke im Voraus.

Ciao The_Unknown

 

[DasBoeseLebt]

Warum sollten deine Kunden einen Branch bekommen, der den Beta-Status hat und womöglich gar nicht gut funktioniert, verstehe ich nicht.

Eigentlich hat man einen Hauptentwicklungszweig von dem alles abgeht. Dieser wird auch verteilt und stellt die fertigen Versionen dar.

Dann hat man noch nen Branch für Fixes und einen Developmentbranch (alternativ kann man auch neue Features je einen eigenen Branch geben).

So kenne ich das.

Dabei sollte man beachten, dass Änderungen im Fix-Branch auch in den Dev.-Branch übernommen werden.

 

[The_Unknown]

Warum sollten deine Kunden einen Branch bekommen, der den Beta-Status hat und womöglich gar nicht gut funktioniert, verstehe ich nicht.

Weil der Kunde gerne den aktuellen Entwicklungsstand mitverfolgen möchte und auch Verbesserungswünsche/Bugfixes daraus ableitet. Es ist noch kein fertiges Projekt mit einer finalen ersten Version.

Und wie ist es mit dem Mergen vom beta in den master-Branch wie oben beschrieben? Welches Verhalten zeigt sich da bei git?

 

[wahli]

Dieser Aufbau macht Sinn. Später wirst du evtl. noch mehr Branches parallel haben.

Ein Merge vom "Beta-Branch" zum Master-Branch geht.

Wenn das dein erstes größeres Projekt ist, dann gibt es doch bestimmt Entwickler, die sich mit dem Merge auskennen und dir helfen können.

 

[The_Unknown]

@wahli: Hier in der Firma ist es das erste git und ich darf experimentieren Von daher ist da noch nicht allzuviel Wissen vorhanden.

 

[KillerCow]

Zum Thema Git gibts ein nettes Buch, daß man sich online angucken, kostenlose runterladen oder natürlich gerne auch kaufen kann -> http://git-scm.com/book

 

[DasBoeseLebt]

Es empfiehlt sich halt schon, wenn man Fehlerbehebung und Entwicklung trennt, da die Fehlerbehebung dann immer auf der aktuellsten ausgelieferten Version stattfindet und nicht auf einen ,,Halb-Beta-Status-neue-Features-Produkt'', wo Fehler womöglich ein ganz anderes Verhalten haben oder ganz andere Sachen auftreten.

Ich kann natürlich nicht die Komplexität deines Projektes und wie viele neben dir mitarbeiten, aber mit min. 3 Branches bei größeres Projekten würde ich eben schon empfehlen. (Main, Fix, Dev).

Stellst du aber nur 1Version zur Verfügung und/oder ist ein kleines Projekt, dann könnten auch wiederum 3 Branches unnötig sein. :-P

 

[wahli]

Vielleicht hilft dir das weiter: klick (KillerCow hat auch auf dieses Buch verwiesen)

Wenn noch keine Erfahrung da ist, dann würde ich mir mal ein Testprojekt anlegen und mich dort austoben.

 

[The_Unknown]

Ja, es ist schon ein relativ kleines Projekt und wir arbeiten derzeit zu zweit daran.

Was mir etwas Kopfzerbrechen bereitet, sind Änderungen am Datenbankschema. Es ist sehr wahrscheinlich, dass in beiden Branches verschiedene DB-Schemata verwendet werden. Hast du da ein gutes Vorgehen? Momentan arbeiten wir mit Migrationen, d.h. neue Sachen werden als Migration gegenüber dem bisherigen Stand abgelegt. Das kann sich aber in beiden Branches auseinanderentwickeln (auch konfliktbehaftet). Was muss man denn da beim Zusammenführen beachten? Muss man das händisch machen oder gibt es da irgendwelche Best-Practices?

@KillerCow: Das Buch werde ich mir auf jeden Fall zu Gemüte führen

 

[DasBoeseLebt]

Wenn man merged und es treten Konflikte auf, dann sollte man die in 99% der Fälle mit Hand lösen (alternativ einfach überschreiben oder eben nicht, man sollte aber wissen was man macht). Da gibt es auch Tools, die einen helfen.

Allerdings sollte eher geklärt werden, warum ihr euch in selben Projekt auseinander entwickelt, weil das für mich als externe Person jetzt nicht wirklich Sinn macht. Ihr werdet dann das komplette Projekt bei jedem Merge-Vorgang im schlimmsten Falle Konflikte haben und geht dann etwas schief, dann funktioniert womöglich das Projekt erstmal nicht mehr, bis ihr die Sachen korrigiert habt (unnötige Arbeit).

Also vorher so wichtige Sachen abklären, wäre hier mein Tipp. (Aus dem Grund stecken in großen Projekten enorm viel Planung, weil nicht einfach irgendwer, weil er lustig ist, was ändern darf, womit alle arbeiten. Sowas wird dann in der Doku festgehalten und meist gleich mit Interfaces verankert).

 

[The_Unknown]

Einfaches Beispiel: Ein Bugfix erfordert ein Ändern des DB Schemas. Das DB Schema wurde aber im master Branch bereits zuvor einmal verändert. Dadurch kommt die Migrationshistory durcheinander. Hast du dafür irgendwelche Tipps?

Das Mergen von Code geht immer noch, weil da keine Daten in der DB mit dranhängen.

 

[wahli]

Wenn ein Bugfix eine Schemaänderung beinhaltet, dann muss doch diese Änderung auch in den Master-Branch übernommen werden. Wenn allerdings im Master-Branch dieser Teil z. B. total umgebaut wurde, dann brauchst du die Änderung nicht übernehmen - macht ja keinen Sinn und geht auch gar nicht).

Und sonst kenne ich es so, dass einfach verschiedene Dateien zu jedem Branch existieren, d. h. du kannst z. B. verschiedene Verzeichnisse ("'Beta01", "Beta02",...) haben und dort sind die Dateien mit gleichem Namen drin (z. B. "schema.sql") oder du hast für jede Version eine eigene Datei ("schema.sql", "schema-beta01.sql", "schema-beta02.sql",...). Hier liegt es dann am "build", dass die richtigen Dateien für den build verwendet werden.

 

[DasBoeseLebt]

Richtig, es liegt am Code, ob du den Fehler auch in Masterbranch einspielen musst (was ja dein Dev.-Zweig ist).

Grundsätzlich sollten Fehler auch dort behoben werden und geheckt werden, ob sie dort auch exisitieren (selbst nach ,,Code-Umbau'').

Du hast halt keinen klaren Fix-Zweig, dass ist dein Problem (der hängt bei dir zwischen Master- und Betabranch und hüpft fröhlich rum, so ca. ), was nicht per se schlecht ist, wenn man eh nicht dauernde ,,fertig'' Versionen ausliefern will oder muss.

 

[The_Unknown]

@DasBoeseLebt: Wenn es eine erste produktive Version gibt, wird das vermutlich eh noch ändern. Aber danke für eure Hinweise!

@wahli: Wir arbeiten hier so, dass es einen Basisstand gibt auf dem dann bei jeder Schemaänderung eine Migration generiert wird, die die gemachten Änderungen beinhaltet. Diese Migrationen liegen dann im Repository, sodass jeder Dev Zugriff darauf hat und so garantiert wird, dass jeder das gleiche Schema nutzt. Bei verschiedenen Branches hat man dann aber das Problem, dass von einer Migration verschiedene weitere Migrationen ausgehen können je nach Branch. Ich glaube aber, da kommt man um etwas Handarbeit nicht herum

 

[ice-breaker]

Einfaches Beispiel: Ein Bugfix erfordert ein Ändern des DB Schemas. Das DB Schema wurde aber im master Branch bereits zuvor einmal verändert. Dadurch kommt die Migrationshistory durcheinander. Hast du dafür irgendwelche Tipps?

Es gibt Tools für soetwas, z.B. Liquibase.