[Git][ZF2] Best practices voor version control van submodule

[Verwijderd]

Ik heb een aantal projecten gebaseerd op Zend Framework 2 onder versiebeheer met Git. Binnen deze projecten heb ik een aantal modules die vaak terugkomen. Bijvoorbeeld een Authenticatie module. Deze modules zijn ook een aparte git repo. Binnen het hoofd project laad ik deze dan in als submodule. Een hoop project specifieke configuratie is redelijk goed te plaatsen binnen de local.config.php bestanden, die vervolgens in .gitignore terecht komen. Helaas loop ik nu tegen het probleem dat ik project specifieke aanpassingen moet doen waarvan ik niet zie hoe ik die in local.config of buiten de submodule kan plaatsen.

Een voorbeeld is wellicht het duidelijkst. Voor mijn model gebruik ik Doctrine 2 en in mijn Authenticatie module heb ik dus een entity User

PHP:

<?php
namespace SphAuthentication\Entity;

/**
 * User
 *
 * @ORM\Table(name="users")
 * @ORM\Entity
 */
class User
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    protected $id;

    ...

}

Neem nu een project dat gebruik maakt van deze Authenticatie submodule voor bijvoorbeeld een blog. De User entity moet nu gekoppeld worden aan BlogPost Entity als een User gebruikt wordt als auteur voor blogposts. Echter deze OneToMany relation moet in de User.php file komen te staan, maar zijn alleen relevant voor het main project en niet voor de Authenticatie submodule. Ik zie niet hoe ik deze project specifieke code kan plaatsen in een soort locale config, en het zal moeten worden opgenomen in de versioning van het main project en de authenticatie submodule.

De vraag is nu, wat is de beste manier om dit onder te brengen in git. Waar ik zelf aan dacht is om voor ieder hoofd project de Authenticatie module als git submodule in te laden onder een nieuwe branch, specifiek voor dat project. Alle project specifieke code gaat dan naar de branch en algemene submodule changes kunnen naar master.

Ik heb beperkt ervaring met git en weet niet precies hoe dit zou moeten, of dit de beste manier is, of dat dit uberhaupt wel gaat werken. Alle input is welkom

[HMS]

Kan je hier niet een soort Decorator pattern (wrapper class) toepassen om de project specifieke aanpassingen op te vangen?

Wikipedia: Decorator pattern

EDIT: Ook nog een beetje on topic reageren .

Dit is het lastige met submodules die je inlaad op deze manier. Aangezien submodules (volgens mij) ook geen tracking doen maar gekoppeld zijn aan een commit is het ook lastig om hier versioning toe te passen.

Vandaar mijn Decorator / Anti corruption layer suggestie, zodat je niet in een zeer complex versioning schema terecht komt.

De simpelste oplossing is natuurlijk om de hele Authenticatie module in het project te trekken, maar ik snap dat dat om meerdere redenen niet wenselijk is .

[ Voor 56% gewijzigd door HMS op 07-01-2014 21:47 ]

[Cartman!]

In het proje t trekken? Eruit halen juist. De authenticatie een losse package maken zodat je deze kan inladen met composer (www.getcomposer.com). Een project die hier gebruik van maakt heeft een eigen User entity die deze uit je package extend. Lost meteen de originele vraag op: losse packages dus een eigen repository

[Verwijderd]

Ik ben nog niet bekend met Decorator Pattern's maar zal daar zeker eens op googlen.
Cartman's antwoord klinkt ook goed, echter ik ontwikkel mijn submodules actief binnen een project en zie zo niet hoe ik binnen dit project zowel de module als package en als repo heb. Enig advies waar ik kan zoeken voor een workflow die daar op lijkt?

[Cartman!]

Het splitsen kan zeker lastig zijn maar daarna ben je veel flexibeler in het updaten van je projecten en zoals ik zei, alles is een eigen repository dus versiebeheer is super simpel.

[Verwijderd]

Na wat verder onderzoek, kwam ik een al lang geleden gelezen SO post tegen die nu ineens op viel omdat deze aansluit bij wat Cartman heeft gezegd. Heb verder niet veel andere opties gevonden die werkbaarder lijken. Voor developing, zeker als je een package binnen een andere repo moet ontwikkelen, lijkt die workflow echter nog steeds verre van ideaal. Maar git submodules lijken het sowieso niet te worden in dit geval.

[Cartman!]

Die post legt het erg goed uit ja, precies wat ik bedoel!