Skip to end of metadata
Go to start of metadata

Próbálok haladni a korral és egy új projektet megpróbálok Git alapokon verzió kezelni, merthogy majd lesz benne sok refaktorálás, létre is hoztam szépen a Git repository-t, tettem fölé HTTP protokollt, éppen kötném be a Jenkins alá, amikor rájöttem arra a nem túl reklámozott korlátozásra, hogy egy repository az nagyjából egyben kezelendő fordítási egység vagy projekt. Nekem például most egy olyan projektem van, ahol lazán csatolva öt különálló modulom van:

  • Common libraries
  • Common data model
  • Android
  • Back end
  • Front end

Ha ezeket külön szeretném verziózni build és release szempontjából, akkor – jelenlegi tudományom szerint – ez öt Git repository létrehozását jelenti, mert nem szeretném egyetlen esernyő alá bezsúfolni a négy projektet, amikor csak puszta adatok mozognak közöttük REST vagy SOAP protokollon, ennél több függés ugyanis nincs a projektek között, leszámítva a Java alapú projektekben közösen használt eszközöket. Tehát például a Back end projekt teljesen önállóan kerül (majd) kiadásra, a külvilág felé REST protokollon JSON alapú interfészen fognak adatok mozogni, értelmetlennek tartom ezen projekt mellé odacsomagolni az Android projektet, amely ugyan használja az interfészen át a szolgáltatásokat, de teljesen más okokból fogok release-t kiadni.

Ha viszont engedek az "each project in its own repo" filozófiának, akkor elvesztem a Git azon előnyét, hogy a fájlok és egész fák mozgását jobban képes követni, mint a Subversion, hiszen a nagyfokú refaktorálás során minden bizonnyal egész fájlok és/vagy metódusok fognak mozogni a projektek között (kód duplikáció elkerülése okán sok dolog át fog kerülni a Common libraries projektbe, illetve projektek közötti mozgás is elképzelhető). Ebből a mozgásból a Git nem sokat fog látni, mert egyik független repository-ból kiveszem és beleteszem a másik független repository-ba.

Én most egy kicsit megakadtam... segítsetek kicsit: valamit rosszul gondolok vagy ilyen feladatokra nem való a Git?

      
      
Page viewed times
  • No labels

4 Comments

  1. SVN-nel ugyanezt hogy oldanád meg?

    elvesztem a Git azon előnyét, hogy a fájlok és egész fák mozgását jobban képes követni

    Ezzel amúgy olyan nagyon-nagyon sokat nem vesztesz szerintem.

    1. Auth Gábor AUTHOR

      Mármint SVN esetén az egy repository-n belüli, de projektek közötti mozgatást? Gond nélkül, létezik már egy ideje merge-tracking: http://wiki.apache.org/subversion/SupportedMergeScenarios

      Ezzel amúgy olyan nagyon-nagyon sokat nem vesztesz szerintem.

      Tényleg úgy látom, hogy nem fogja azt és úgy tudni, amire és ahogy használni szeretném. Egy Linux kernelnél megértem a lényegét, de több összefüggő, egymást hívó, de amúgy külön kiadási ciklussal rendelkező projektekre nem látom értelmét.

  2. Unknown User (zamek42)

    submodule nem lenne jó?

    1. én is erre gondoltam elsőre, de a "elvesztem a Git azon előnyét, hogy a fájlok és egész fák mozgását jobban képes követni" submodulok használatával is fennáll (ebben mondjuk csak 99%-ban vagyok biztos(smile)).