Code syncen tussen meerdere pcs ?

[Rebbelx]

Ik ben vrij nieuw in het programmeren dus ik weet niet of ik een relevante vraag stel of niet... Ik heb 2 computers, soms programmeer ik op de ene, soms op de andere..Het spreekt voor zich dat de code die ik soms op pc1 schrijf , ik nadien nodig heb op pc2. Tot nu toe zette ik alles op een external drive die ik dan aansloot wanneer ik switch tussen de pcs.

Ik vroeg me echter af of er tools bestaan waardoor je je code in de cloud kan saven en die telkens je een pcs gebruikt met deze locatie synced en je dus steeds de laatste code hebt. Ik heb al gelezen over GitHub maar heb geen idee of dit hetgene is wat ik precies zoek..

Alvast bedankt!

[diondokter]

Als je alleen werkt en niet geeft om versie beheer (git), dan kun je het prima via een van de grote cloud diensten gebruiken. Zo staan bijna al mijn hobby projectjes op mijn onedrive zodat ik er ook op mijn laptop bij kan.

Voor grotere projecten of projecten waar je samenwerkt raad ik je aan om git te gebruiken. Dit kun je hosten op github, gitlab, bitbucket, etc...

[djc]

Zeker bestaan daar tools voor! Het heet een Version Control System (VCS). Het populairste voorbeeld is momenteel Git, waarbij GitHub als centrale opslag functioneert. Raad je aan om eens te kijken naar online boeken en tutorials over Git, het eerste begin is niet heel ingewikkeld.

[RobIII]

Je moet je sowieso aanwennen alles in een VCS te zetten, ook kleine frutprojectjes. Het kost amper tot geen moeite (en het basisprincipe leren stelt ook niets voor), en je krijgt er veel voor terug. Zo kun je altijd kijken wat er gewijzigd is tussen twee commits (wat heb ik gedaan waardoor het nu stuk is?), heb je altijd een "backup", kun je makkelijk experimenteren in een nieuwe branch en als je experiment mislukt terug naar vóór die tijd door gewoon die branch te snoeien (of laten rondhangen voor later) etc. etc.

Eenmaal een VCS gewend wil je nooit meer zonder (en zou je ook niet moeten willen!). Code "delen" middels dropbox/onedrive of zipjes naar jezelf mailen oid is echt een poor-mans VCS at best.

Git is een veelgebruikte en bekende, GitHub biedt daar een leuke makkelijke (Web maar ook desktop) GUI voor, maar er is ook een BitBucket (ook git-based), CodePlex (TFS en/of Git), Visual Studio Team Services (ook TFS en/of Git), SourceForge en ga zo maar door. Een aantal daarvan bieden ook 'private projects' maar bij een aantal betaal je daar voor. Maar ook lokaal een VCS opzetten zoals GitLab of TFS is in een handomdraai gedaan.

[ Voor 31% gewijzigd door RobIII op 25-09-2016 12:26 ]

[jeroen3]

Een vcs lost het fundamentele probleem niet op. Tenminste, niet als je de tijdlijn schoon wilt houden.

Je kunt dan beter je projecten in Owncloud zetten.

Let op! Niet in Dropbox! Die hebben de afgelopen jaren veel gewijzig en werken daardoor niet meer goed samen met svn/git bestanden en compilers.

[jip_86]

Tja wat is een schone tijdlijn? Als dat een probleem is kan je uiteindelijk met branches gaan werken om features afgerond te krijgen voor je ze naar een stable merged. Ook heeft TFS (ongetwijfeld andere VCS ook wel) daar shelves voor om dingen even tijdelijk op de plank te leggen.

[Super_ik]

jeroen3 schreef op zondag 25 september 2016 @ 13:20:
Een vcs lost het fundamentele probleem niet op. Tenminste, niet als je de tijdlijn schoon wilt houden.

Een vieze tijdlijn is altijd nog oneidig veel beter dan geen vcs.

[farlane]

jeroen3 schreef op zondag 25 september 2016 @ 13:20:
Een vcs lost het fundamentele probleem niet op. Tenminste, niet als je de tijdlijn schoon wilt houden.

Je kunt dan beter je projecten in Owncloud zetten.

Let op! Niet in Dropbox! Die hebben de afgelopen jaren veel gewijzig en werken daardoor niet meer goed samen met svn/git bestanden en compilers.

Ik gebruik 3 pc's/laptop's om code op te schrijven, en ze syncen allemaal via het vcs (svn in dit geval) en dat werkt in 1 woord geweldig. Een VCS lost het fundamentele probleem volgens mij wel op.

[RobIII]

jeroen3 schreef op zondag 25 september 2016 @ 13:20:
Een vcs lost het fundamentele probleem niet op. Tenminste, niet als je de tijdlijn schoon wilt houden.

Wat schiet je op met (en beter: wat is überhaupt) een "schone tijdlijn"?

Nee, sorry, maar dit is het ergste advies in dit topic dat je kunt geven...

Overigens ondersteunen een aantal VCS'en ook een concept á la "shelving" waarmee je nog niet hoeft te committen maar wel je work-in-progress naar andere pc's kunt halen.

[ Voor 18% gewijzigd door RobIII op 25-09-2016 14:26 ]

[Ed Vertijsment]

Git/VCS (lang verhaal kort, ik raad git aan) lost het probleem volgens mij zeker op. Ooit bedrijven gezien de code beheren op owncloud als VCS voorhanden is? Een schone tijdlijn heeft geen enkele waarde (en ja, je kunt die achteraf opschonen mocht je echt willen), een gevulde tijdlaan daarentegen is heel nuttig. Even die maandagmorgen code wegmikken en vervangen met iets moois is dan zo gedaan...

Mocht je, je willen verdiepen in git en wat tastbaar leesvoer zoeken raad ik "Pragmatic Guide to Git", heeft mij destijd veel geholpen.

[Ventieldopje]

Eensch met de rest, gebruik een fatsoenlijk VCS en leer daar goed mee om te gaan. Werk je vaak tussen commits op verschillende PC's, gebruik dan een externe hardeschijf of schaf een laptop aan waar je altijd op werkt.

Ik gruwel van de gedachte alleen al om je code te "syncen", laat staan met OwnCloud. Hoe erg dat wel niet mis kan gaan (en heb zien gaan)

[johnkeates]

Gebruik een VCS/SCM. Git is een goede keuze, niet perse om dat het de beste is (daar zijn meningen nog steeds over verdeeld), maar om dat er de meeste Q&A over te vinden is op het moderne internet.

Er zijn veel gratis services die in elk geval Git aanbieden, zoals GitLab.com, GitHub.com en BitBucket om wat te noemen. Vaak is er ook nog wel SVN toegang mogelijk, en nagenoeg allemaal hebben ze een online file browser.

Naast het oplossen van je probleem is dit eigenlijk ook een essentiele skill van een software engineer. Als je geen VCS/SCM gebruikt of kan gebruiken kan je er van uit gaan dat potentiele werkgevers of klanten je nogal vies aan gaan kijken.

Je kan het trouwens ook zelf hosten, stel dat je ergens een VPS hebt draaien of een echte server, dan kan je daar vrij eenvoudig GitLab op hosten, of Gogs om maar wat te noemen.

[jeroen3]

RobIII schreef op zondag 25 september 2016 @ 14:25:
[...]

Wat schiet je op met (en beter: wat is überhaupt) een "schone tijdlijn"?

Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Je hebt voor Git helemaal geen cloud nodig. Een git remote kan prima werken op een Windows netwerkshare.

[ Voor 16% gewijzigd door jeroen3 op 25-09-2016 15:06 ]

[Ed Vertijsment]

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
[...]

Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Je hebt voor Git helemaal geen cloud nodig. Een git remote kan prima werken op een Windows netwerkshare.

Doorgaan wel, maar vaak genoeg commits a "started implementing X but duty calls" gehad. Gewoon in een losse branch dan, en later gesquasht...

[Ventieldopje]

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
[...]

Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Je hebt voor Git helemaal geen cloud nodig. Een git remote kan prima werken op een Windows netwerkshare.

Afhankelijk van je manier van branchen (hele andere discussie) geldt dat vaak alleen op de release/master branch. Op je develop/feature branches kun je prima commits hebben die nog niet helemaal goed compilen of waar nog bugs in zitten. Daarvoor heb je tools als Bamboo, Jenkins, Travis etc. om automatisch build tasks uit te voeren (unit tests etc.) en je code te controleren op fouten. Je kan dan meteen per branch zien wat werkt en niet werkt.

Ed Vertijsment schreef op zondag 25 september 2016 @ 15:21:
[...]


Doorgaan wel, maar vaak genoeg commits a "started implementing X but duty calls" gehad. Gewoon in een losse branch dan, en later gesquasht...

Afhankelijk van de grootte van je team is dat niet echt een goeie oplossing imho. Je gebruikt dan git als auto-save feature wat het eigenlijk niet is. Als dit vaak voorkomt in een team dan moet je er aan gaan werken om sneller opvolgend commits te maken, je werk dus opdelen in kleinere stukken. Als je werkt met feature branches en iedereen werkt aan zijn eigen feature dan is er helemaal geen nut om dit te doen. Gewoon opslaan en de volgende keer verder werken en pas committen als een stuk code klaar is.

[ Voor 34% gewijzigd door Ventieldopje op 25-09-2016 15:23 ]

[Ramon]

jeroen3 schreef op zondag 25 september 2016 @ 13:20:
Een vcs lost het fundamentele probleem niet op. Tenminste, niet als je de tijdlijn schoon wilt houden.

Je kunt dan beter je projecten in Owncloud zetten.

Let op! Niet in Dropbox! Die hebben de afgelopen jaren veel gewijzig en werken daardoor niet meer goed samen met svn/git bestanden en compilers.

Als ik hoor 'tijdlijn schoon houden' denk ik aan niet al teveel nutteloze merge-commits. Jij bedoelt daar blijkbaar mee dat de staat van de code altijd compileerbaar moet zijn.

Daar ben ik het niet per definitie mee eens. Hangt helemaal af van de situatie. Bijvoorbeeld als ik net 3 dagen bezig ben met een nieuw project hoeft het allemaal niet zo strict te werken. Daarnaast is het soms ook fijn om aan het eind van de dag een "WIP"-commit te doen in een dev-branch. Al is het alleen maar om te voorkomen dat je een dag werk kwijt bent als je hardware er mee op houdt. Je kan ze later wel weer squashen. Ik vind het wel overigens raar om de TS OwnCloud aan te raden om een of andere rare aanname dat hij z'n tijdlijn toch niet schoon kan houden.

Maargoed, het gaat hier om iemand die nieuw is op dit gebied dus allerlei best practises voor grote projecten zijn niet zo relevant. De TS kan bijvoorbeeld gewoon BitBucket proberen, want gratis, inclusief het gratis SourceTree moet je toch een heel eind komen.

[Rmg]

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
[...]

Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Je hebt voor Git helemaal geen cloud nodig. Een git remote kan prima werken op een Windows netwerkshare.

Op zich een goeie regel. Alleen niet werkbaar als je op meerdere PCs werkt icm met github/gitlab/bitbucket.

Je kan dan weer gaan kloten met lokale git repo's en dan via een of andere clouddienst werken ala onedrive/stack/iets maar dat is dus wel weer een extra dependency.

Makkelijkste is naar mijn mening een develop branch en een integratiebranch, geen extra cloudplatform dependency, alles kan in github/lab/bitbucket en je kan je zelfde 'schone' tijdlijn houden

[jeroen3]

Ieder zijn workflow. Als het maar beschreven staat.

Inderdaad, SourceTree, dat was nog niet genoemd. En dat is, zelfs voor de wat meer ervaren git gebruiker, nog steeds erg gemakkelijk.

[Hydra]

jeroen3 schreef op zondag 25 september 2016 @ 13:20:
Een vcs lost het fundamentele probleem niet op. Tenminste, niet als je de tijdlijn schoon wilt houden.

Je kunt dan beter je projecten in Owncloud zetten.

Inleveren die programmeervergunning.

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Dat is leuk voor je maar dat is niet hoe in de professionele wereld gewerkt wordt. Je werkt normaliter op je eigen branch. Het maakt geen fluit uit of iets stuk is (als iets halverwege 'af' is als ik weg moet commit en push ik het gewoon) omdat niemand anders er last van heeft.

[ Voor 43% gewijzigd door Hydra op 25-09-2016 16:50 ]

[Creepy]

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
[...]

Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Je hebt voor Git helemaal geen cloud nodig. Een git remote kan prima werken op een Windows netwerkshare.

Git rebase -i voordat je naar een publiek branch pust en klaar is Klara. Niemand die kan zien dat je 10 commits voor nodig had ivm pc hoppen.

[Emiel1984]

Indien je voor GIT kiest wil ik je wel als advies meegeven om enkel de noodzakelijk files te synchroniseren\pushen\committen.

Als je deze regel vanaf begin aanhoud blijft je repository mooi schoon en overzichtelijk.
Push\commit dus bijvoorbeeld geen tijdelijke files die door je SDK worden aangemaakt maar verdwijnen bij het schoonmaken van je omgeving via de SDK opties.

Project specifieke setting files zijn wel handig om mee te nemen, zodat de instellingen op alle PC's in je SDK hetzelfde zijn bij het ontwikkelen. Hou echter wel in de gaten dat je deze niet onnodig blijft pushen naar je externe GIT omgeving\opslag.

[ Voor 13% gewijzigd door Emiel1984 op 25-09-2016 18:58 ]

[NMe]

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
[...]

Ik ben van mening dat een commit netjes af is. En compileert zonder errors.

Je release-branches moeten na een merge altijd compileren zonder errors. De branch waarin je developt en zeker een feature-branch hoeft dat zeker niet te doen. De toegevoegde waarde van vaak committen is veel groter dan die van een "schone tijdlijn". Git is een tool om je code te managen, niet een boek dat je op chronologische volgorde moet lezen...

[jeroen3]

Zo kun je het ook bekijken.... Goed advies.

[epic007]

jeroen3 schreef op zondag 25 september 2016 @ 15:06:
[...]
Je hebt voor Git helemaal geen cloud nodig. Een git remote kan prima werken op een Windows netwerkshare.

+1 En zelfs ook op een USB stick.

[DJMaze]

Je kan ook Mercurial gebruiken ipv Git als DCVS

[ Voor 10% gewijzigd door DJMaze op 26-09-2016 14:43 ]

[Montaner]

Hoe doen jullie dit trouwens met je local dev database? MySQL databases bv. Werken met migraties en seeds in bv. een Laravel project zou dat wel afvangen.. maar als je bezig bent met Wordpress en je wil ook de settings van je site gelijk houden?

[Ventieldopje]

trix0r schreef op maandag 26 september 2016 @ 15:12:
Hoe doen jullie dit trouwens met je local dev database? MySQL databases bv. Werken met migraties en seeds in bv. een Laravel project zou dat wel afvangen.. maar als je bezig bent met Wordpress en je wil ook de settings van je site gelijk houden?

Script schrijven om je database te downloaden en vervolgens een (SQL) script om je development specifieke aanpassingen te maken (dev admin user etc.).

[Kwistnix]

Creepy schreef op zondag 25 september 2016 @ 18:38:
[...]

Git rebase -i voordat je naar een publiek branch pust en klaar is Klara. Niemand die kan zien dat je 10 commits voor nodig had ivm pc hoppen.

Heel erg dit.
Commit wat je wilt, zo veel je wilt, maar voordat je 't pusht even interactive rebase er overheen. Squash de "onzinnige" commits er tussen uit, reorder desnoods wat zaken en stop vooral ook even wat tijd in zinnige commit messages. Je maakt de reviewer er zo gelukkig mee.

[DJMaze]

trix0r schreef op maandag 26 september 2016 @ 15:12:
Hoe doen jullie dit trouwens met je local dev database? MySQL databases bv. Werken met migraties en seeds in bv. een Laravel project zou dat wel afvangen.. maar als je bezig bent met Wordpress en je wil ook de settings van je site gelijk houden?

Laravel migraties en YII migraties hebben bij mij nooit gewerkt. Om de één of andere reden klapt de boel er uit.
Andere systemen werken ook niet goed omdat ik VIEW tables gebruik, en om de één of andere reden zien ze die als "tables" en moet data in de backup als "inserts" wat natuurlijk niet werkt.

Ik heb zelf een XML systeem opgetuigd wat prima zijn werk doet voor alles wat ik wil, en ik kan daardoor ook wisselen tussen verschillende RDBMS'en.
Voordeel is ook dat ik de XML bestanden prima in een DVCS kan gebruiken.

[ Voor 4% gewijzigd door DJMaze op 26-09-2016 23:04 ]

[TheNephilim]

trix0r schreef op maandag 26 september 2016 @ 15:12:
Hoe doen jullie dit trouwens met je local dev database? MySQL databases bv. Werken met migraties en seeds in bv. een Laravel project zou dat wel afvangen.. maar als je bezig bent met Wordpress en je wil ook de settings van je site gelijk houden?

Bij WordPress is dit inderdaad een drama. Je moet op elke werkplek een volledige WordPress installatie hebben. In principe kost het niet eens zo heel veel tijd, maar het is wel een gehannes.

Er zijn plugins om database van verschillende ontwikkelomgevingen te synchroniseren, maar die zijn betaald en ook heb je dan nog steeds een volledige installatie nodig. Het enige wat je niet hoeft te doen is content toevoegen, maar goed...

[Ryan_]

Interessant draadje. Ik zelf ben een echte hobby/thuis programmeur. Huis, tuin en keuken programmaatjes. Voor mij voldoet Onedrive prima inderdaad. Dropbox upload niet alle bestanden. Die zou ik links laten liggen.

Met Stack moet dit denk ik ook wel lukken.

[Creepy]

TheNephilim schreef op dinsdag 27 september 2016 @ 09:47:
[...]


Bij WordPress is dit inderdaad een drama. Je moet op elke werkplek een volledige WordPress installatie hebben. In principe kost het niet eens zo heel veel tijd, maar het is wel een gehannes.

Er zijn plugins om database van verschillende ontwikkelomgevingen te synchroniseren, maar die zijn betaald en ook heb je dan nog steeds een volledige installatie nodig. Het enige wat je niet hoeft te doen is content toevoegen, maar goed...

Wij gebruiken Vagrant voor dit soort zaken. 1 keer inrichten zodat je met 1 commando een volledig werkende Wordpress/Magento/Database/etc hebt met eventuele extra plugins en afhankelijkheden. De Vagrant en provision scripts kunnen dan weer je SCM in. Elke developer kan na het uitchecken een "vagrant up" uitvoeren en gaan devven.
Database migratie/aanpassingen doen we vanuit de applicatie/code zelf. Dan werkt dat gelijk voor de ontwikkelingomgeving maar ook in de uiteindelijke live omgeving. Daar is ook tooling voor te vinden om dat voor je te doen.

[ Voor 11% gewijzigd door Creepy op 27-09-2016 10:24 ]

[TheNephilim]

Creepy schreef op dinsdag 27 september 2016 @ 10:23:
[...]

Wij gebruiken Vagrant voor dit soort zaken. 1 keer inrichten zodat je met 1 commando een volledig werkende Wordpress/Magento/Database/etc hebt met eventuele extra plugins en afhankelijkheden. De Vagrant en provision scripts kunnen dan weer je SCM in. Elke developer kan na het uitchecken een "vagrant up" uitvoeren en gaan devven.
Database migratie/aanpassingen doen we vanuit de applicatie/code zelf. Dan werkt dat gelijk voor de ontwikkelingomgeving maar ook in de uiteindelijke live omgeving. Daar is ook tooling voor te vinden om dat voor je te doen.

Voor Laravel gebruik ik al Homestead, dus ik ben bekend met Vagrant. Ik moet zeggen dat we inderdaad al eens gekeken hebben naar Vagrant voor WordPress, maar dit was toen nog niet erg volwassen.

Gebruiken jullie een basis van https://roots.io/, of is het een eigen brouwsel?

Over het algemeen, hebben voor onze WordPress klanten het probleem dat het allemaal te groot (en dus te duur) wordt, of dat ze qua hosting wat 'aparts' moeten hebben. Zoals migraties; dat doe je dan vanuit de code neem ik aan, of via SSH oid.?

Voor het deployen vanuit Git gebruiken we http://ftploy.com/, wat wel aardig werkt. Misschien toch ook maar eens weer kijken naar een Vagrant oplossing voor onze WordPress websites. Al moet dat geheel niet teveel extra rompslomp opleveren, dus dat je 2x zo lang bezig bent met het opstarten van een project.

[CH4OS]

jeroen3 schreef op zondag 25 september 2016 @ 15:29:
Inderdaad, SourceTree, dat was nog niet genoemd. En dat is, zelfs voor de wat meer ervaren git gebruiker, nog steeds erg gemakkelijk.

Ben zelf wat huiverig voor SourceTree. Leuk, zo'n GUI, maar ik heb al eens gehad dat met verloop van tijd de repo vernaggelt is, omdat SourceTree het niet meer snapt. Daarnaast is er zoveel documentatie te vinden over Git op de commandline, dat ik liever de commandline gebruik dan een GUI, zo moeilijk zijn de commands niet.

[Creepy]

TheNephilim schreef op dinsdag 27 september 2016 @ 10:38:
[...]
Gebruiken jullie een basis van https://roots.io/, of is het een eigen brouwsel?

Over het algemeen, hebben voor onze WordPress klanten het probleem dat het allemaal te groot (en dus te duur) wordt, of dat ze qua hosting wat 'aparts' moeten hebben. Zoals migraties; dat doe je dan vanuit de code neem ik aan, of via SSH oid.?

Voor het deployen vanuit Git gebruiken we http://ftploy.com/, wat wel aardig werkt. Misschien toch ook maar eens weer kijken naar een Vagrant oplossing voor onze WordPress websites. Al moet dat geheel niet teveel extra rompslomp opleveren, dus dat je 2x zo lang bezig bent met het opstarten van een project.

Qua ontwikkeling doen we bijna alles in Java en zo goed als geen PHP werk. Wordpress wordt dan bij ons gebruikt om koppelingen/integraties mee te testen. Qua development omgevingen is het ons doel om na het uitchecken van de code alleen een "vagrant up" (eventueel meerdere) te hoeven starten waarin alle afhankelijkheden zitten zoals bijv. de database.

Dit staat bij ons los van deployment, dat gebeurd bij ons met een buildserver en saltstack. De buildserver voor CI en het maken van releases. Dat wordt dan weer doorgezet naar saltstack waarmee een release wordt uitgerold. En aangezien saltstack ook in Vagrant draait, kunnen we een deel van de salt states hergebruiken voor zowel development als de test/acceptatie/live omgeving.

[farlane]

GitKraken als (basic) UI vind ik voor mij als Git n00b wel lekker visueel. Als het niet kan via de UI dan naar de shell.

[HansvDr]

Ik gebruik Visual Studio Team Services van Microsoft ( https://www.visualstudio.com/team-services/ )

Gratis voor 5 gebruikers. Voldoet hier prima.

[Ventieldopje]

TheNephilim schreef op dinsdag 27 september 2016 @ 10:38:
[...]

Voor het deployen vanuit Git gebruiken we http://ftploy.com/, wat wel aardig werkt. Misschien toch ook maar eens weer kijken naar een Vagrant oplossing voor onze WordPress websites. Al moet dat geheel niet teveel extra rompslomp opleveren, dus dat je 2x zo lang bezig bent met het opstarten van een project.

Is dat niet ontzettend onhandig om direct te deployen zonder tussenkomst van tests en een set-up? Neem aan dat je niet al je dependencies in je repo wil hebben puur om maar simpel te kunnen deployen (die fout heb ik wel eens gemaakt).

[TheNephilim]

Ventieldopje schreef op dinsdag 27 september 2016 @ 16:01:
[...]


Is dat niet ontzettend onhandig om direct te deployen zonder tussenkomst van tests en een set-up? Neem aan dat je niet al je dependencies in je repo wil hebben puur om maar simpel te kunnen deployen (die fout heb ik wel eens gemaakt).

We zetten hier eigenlijk ook geen grote WordPress websites weg hoor Alleen het thema zit in de repository, dus niet de gehele WordPress installatie en plugins. Eventuele libraries worden handmatig geïnstalleerd, geen composer dus. Bij gebruik van npm/bower/etc. zitten de node_modules/etc. directories in de .gitignore en compilen van scripts etc. doet PhpStorm.

Het komt eigenlijk niet voor dat we tegelijk aan één thema werken, dus voor ons is dat geen probleem. Mocht dat nodig zijn, dan kan dat ook prima, we gebruiken git dmv. Bitbucket en kunnen dus evt. branchen.