[Git] Aangepaste versie van een project forken van origineel

[TheNephilim]

Onlangs hebben we voor een klant een website afgeleverd net een kleine webapp erachter. Voor ingelogde gebruikers zit daar bepaalde functionaliteit achter en er is een soort admin panel (naast het CMS) waarin de webapp beheerd kan worden.

Nu is er de vraag om een kopie te maken, met een ander thema. Het gevolg is dat logo/huisstijl/etc. anders is, inhoudelijk veranderd er eigenlijk niet zoveel.

Kan ik dit het beste aanpakken door het origineel te forken? Als ik het goed begrijp kan ik dan wijzigingen van het originele project pullen naar de kopie of andersom.

[Pete]

Een fork (als in, een andere repository) of een nieuwe branch haalt technisch niet veel uit. Lokaal gebruik je ze waarschijnlijk toch in dezelfde repo.

Het enige waar je over na moet denken is of je verschillende toegansrechten wil hebben (bijvoorbeeld als de klanten de repository kunnen zien). Dan is het handiger om verschillende repositories te hebben.

[steffex]

Wil je dan niet liever templates in je project bouwen in plaats van code te dupliceren?

Om niet geheel offtopic te gaan, zou je een fork kunnen maken. Je kunt dan je fork in sync houden met je originele repo.

meer info: https://help.github.com/a...epo#keep-your-fork-synced

[TheNephilim]

Pete schreef op dinsdag 30 september 2014 @ 10:28:
Een fork (als in, een andere repository) of een nieuwe branch haalt technisch niet veel uit. Lokaal gebruik je ze waarschijnlijk toch in dezelfde repo.

Het enige waar je over na moet denken is of je verschillende toegansrechten wil hebben (bijvoorbeeld als de klanten de repository kunnen zien). Dan is het handiger om verschillende repositories te hebben.

Yup, als in een andere repository. Ik wil alleen graag wijzigingen die handig zijn voor beiden over en weer kunnen gebruiken. De projecten zullen (naar verwachting) misschien later meer een eigen leven gaan leiden, vandaar mijn idee om te forken.

Nee de klant kan er niet bij. Puur voor ons eigen versiebeheer en deployment.

steffex schreef op dinsdag 30 september 2014 @ 10:31:
Wil je dan niet liever templates in je project bouwen in plaats van code te dupliceren?

Om niet geheel offtopic te gaan, zou je een fork kunnen maken. Je kunt dan je fork in sync houden met je originele repo.

meer info: https://help.github.com/a...epo#keep-your-fork-synced

Ik verwacht dat de projecten ook inhoudelijk her en der kleine verschillen gaan krijgen. Dat splits ik liever nu beide netjes op, dan dat ik dat later alsnog moet gaan doen.

Het topic is zo ongeveer wel/niet forken, dus offtopic zal je er niet mee gaan

[Sebazzz]

Dit is altijd lastig, ik denk dat je richting multi-tenancy moet kijken. Ayende Rahien heeft hier een hele goede blogserie over. Zelfs al ga je niet als een SaaS oplossing deployen, voor je architectuur kan het wel nuttig zijn.

[YopY]

Het probleem met 1 op 1 forken is het in sync houden van de delen die overeen komen tussen die twee projecten; wat ik lees is dat het (in eerste instantie) alleen de styling is. Die zou je los van de twee websites kunnen trekken (zodat je een repo CMS hebt, een repo voor de styling van site 1, en een repo voor site 2).

Als je een volledige fork doet mag je vervolgens met het handje wijzigingen heen en weer brengen, dat werkt niet echt.

Forks van git projecten worden vaak gemaakt op Github als tijdelijke projecten - dwz, je maakt een fork, doet daar je wijzigingen in, en submit die als pull request. Of je werkt vervolgens met die fork, waarbij je om de zoveel tijd wijzigingen uit de upstream binnenhaalt. Dat werkt ook wel voor jouw situatie, maar het is IMHO geen handige manier van werken als je zelf al de committer / beheerder bent van het origineel.