https://mediawiki.a-eskwadraat.nl/wiki/api.php?action=feedcontributions&feedformat=atom&user=DaanrA-Eskwiki - User contributions [en]2026-08-10T23:05:31ZUser contributionsMediaWiki 1.23.2https://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:34:08Z<p>Daanr: /* Nieuw lid */</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je de code van de website binnenhalen en je eigen debugomgeving aanmaken. Dit doe je door de volgende commando's in een terminal te draaien:<br />
<br />
(Weet je niet hoe je een 'terminal' moet openen? Vraag een medewebcieër!)<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=DEBUGNAAM-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>DEBUGNAAM</code> vervangen met de naam van je debugomgeving, bijvoorbeeld 'pepernoot' of 'comint'.)<br />
<br />
Dit zorgt ervoor dat de code die in de map <code>~/wwwdebug</code> staat wordt uitgevoerd wanneer je naar <code>DEBUGNAAM-debug.a-eskwadraat.nl</code> gaat in je browser.<br />
<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:33:45Z<p>Daanr: /* Nieuw lid */</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je de code van de website binnenhalen en je eigen debugomgeving aanmaken. Dit doe je door de volgende commando's in een terminal te draaien:<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=DEBUGNAAM-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>DEBUGNAAM</code> vervangen met de naam van je debugomgeving, bijvoorbeeld 'pepernoot' of 'comint'.)<br />
(Weet je niet hoe je een 'terminal' moet openen? Vraag een medewebcieër!)<br />
<br />
Dit zorgt ervoor dat de code die in de map <code>~/wwwdebug</code> staat wordt uitgevoerd wanneer je naar <code>DEBUGNAAM-debug.a-eskwadraat.nl</code> gaat in je browser.<br />
<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:31:57Z<p>Daanr: /* Nieuw lid */</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je de code van de website binnenhalen en je eigen debugomgeving aanmaken:<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=DEBUGNAAM-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>DEBUGNAAM</code> vervangen met de naam van je debugomgeving, bijvoorbeeld 'pepernoot' of 'comint'.)<br />
<br />
Dit zorgt ervoor dat de code die in de map <code>~/wwwdebug</code> staat wordt uitgevoerd wanneer je naar <code>DEBUGNAAM-debug.a-eskwadraat.nl</code> gaat in je browser.<br />
<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:31:18Z<p>Daanr: /* Nieuw lid */</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je de code van de website binnenhalen en je eigen debugomgeving aanmaken:<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=DEBUGNAAM-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>DEBUGNAAM</code> vervangen met de naam van je debugomgeving, bijvoorbeeld 'pepernoot' of 'comint'.)<br />
<br />
Dit zorgt ervoor dat de code die in de map <code>~/wwwdebug</code> staat wordt uitgevoerd wanneer je naar <code>$bla-debug.a-eskwadraat.nl</code> gaat in je browser.<br />
<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:30:39Z<p>Daanr: /* Nieuw lid */</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je de code van de website binnenhalen en je eigen debugomgeving aanmaken:<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=$bla-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>$bla</code> vervangen met de naam van je debugomgeving, bijvoorbeeld 'pepernoot' of 'comint'.)<br />
<br />
Dit zorgt ervoor dat de code die in de map <code>~/wwwdebug</code> staat wordt uitgevoerd wanneer je naar <code>$bla-debug.a-eskwadraat.nl</code> gaat in je browser.<br />
<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:29:00Z<p>Daanr: /* Nieuw lid */</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je je eigen debugomgeving aanmaken:<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=$bla-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>$bla</code> vervangen met de naam van je debugomgeving, bijvoorbeeld 'pepernoot' of 'comint'.)<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Nieuw_WWW-lidNieuw WWW-lid2018-10-05T18:27:09Z<p>Daanr: /* Nieuw lid */ wwwdebug -> wwwdebug2</p>
<hr />
<div>Wat je moet doen voor een nieuw lid van de [[WebCie|www]]:<br />
<br />
== Bestuur ==<br />
<br />
#Toevoegen aan 'webcie' (inloggen op de server en bij de repo)<br />
<br />
== Webcie ==<br />
<br />
Ga naar de [[vm-www-debug]] en log in als user webcie:<br />
ssh vm-www-debug<br />
sudo -i -u webcie<br />
<br />
Toevoegen aan de htpasswd:<br />
htpasswd /srv/htpasswd $USER<br />
Toevoegen aan de htgroups<br />
vim /srv/config/vm-www-debug/httpd/conf.d/htgroups<br />
vim /srv/config/vm-www/httpd/conf.d/htgroups<br />
Toevoegen aan de wwwdebug.conf<br />
cd /srv/http/www/git<br />
vim webcie_leden.sh<br />
./webcie_leden.sh<br />
git add -p<br />
git commit<br />
git push<br />
sudo service httpd restart<br />
Toevoegen aan de git repo<br />
Vraag aan een momenteel webcie lid om dit te doen<br />
<br />
<br />
== Nieuw lid ==<br />
<br />
Als eerste ga je je eigen debug omgeving aanmaken:<br />
<br />
cd /mnt/wwwdebug2<br />
mkdir $USER/<br />
cd $USER<br />
git clone https://git.a-eskwadraat.nl/webcie/website.git wwwdebug<br />
cd wwwdebug/www<br />
./manage build --enable-debug --hostname=$bla-debug.a-eskwadraat.nl<br />
ln -s /mnt/wwwdebug2/$USER/wwwdebug/ ~/wwwdebug<br />
<br />
(Hier moet je <code>$bla</code> vervangen met de naam van je debugwebsite.)<br />
=== Je eerste commit doen ===<br />
<br />
In de root van je website (dat is de map ~/wwwdebug/www/ dus doe als je daar nog niet in zit <code>cd ~/wwwdebug/www/</code>) staat de map space/auth/ met daarin het bestand init.php. Voeg jezelf hier toe bij de $GODNRS. Om dit bestand vervolgens te committen doe je<br />
git commit space/auth/init.php<br />
Vervolgens moet je het bestand pushen zodat de rest van de webcieërs het binnen kunnen halen<br />
git push<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2018-01-23T00:47:20Z<p>Daanr: /* Doetjes & Doe-nietjes */</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)<br />
<br />
== Pull Requests ==<br />
<br />
Als je een branch wil mergen, doe dit dan altijd via een pull request. Dan kunnen andere WebCie'rs ook de code checken op bugs of stijlfouten.<br />
<br />
== Branches ==<br />
<br />
;develop<br />
: Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.<br />
;master<br />
: De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je ''kan'' hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!<br />
;feature-$bla<br />
: Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.<br />
;refactor-$bla<br />
: Als je meer in het algemeen wilt refactoren, kan je daarvoor ook het beste een aparte branch maken, zodat er niet teveel ruis op <code>develop</code> is en zodat je er een pull request van kan maken.<br />
<br />
== Doetjes & Doe-nietjes ==<br />
<br />
* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek! <br />
* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld<br />
* '''Doe''': als een feature branch waar je mee bezig bent nogal achterloopt op develop, kan je die rebasen op develop (en vervolgens force-pushen), ''mits'' je de enige bent die een lokale checkout van die branch heeft. Nadruk op mits.<br />
* '''Doe-niet''': <code>git cherry-pick</code>. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2018-01-15T18:45:22Z<p>Daanr: /* Doetjes & Doe-nietjes */</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)<br />
<br />
== Pull Requests ==<br />
<br />
Als je een branch wil mergen, doe dit dan altijd via een pull request. Dan kunnen andere WebCie'rs ook de code checken op bugs of stijlfouten.<br />
<br />
== Branches ==<br />
<br />
;develop<br />
: Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.<br />
;master<br />
: De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je ''kan'' hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!<br />
;feature-$bla<br />
: Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.<br />
;refactor-$bla<br />
: Als je meer in het algemeen wilt refactoren, kan je daarvoor ook het beste een aparte branch maken, zodat er niet teveel ruis op <code>develop</code> is en zodat je er een pull request van kan maken.<br />
<br />
== Doetjes & Doe-nietjes ==<br />
<br />
* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek! <br />
* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld<br />
* '''Doe''': als een feature branch waar je mee bezig bent nogal achterloopt op develop, kan je die rebasen op develop (en vervolgens force-pushen), ''mits'' je de enige bent die een lokale checkout van die branch heeft.<br />
* '''Doe-niet''': <code>git cherry-pick</code>. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2018-01-15T18:43:01Z<p>Daanr: </p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)<br />
<br />
== Pull Requests ==<br />
<br />
Als je een branch wil mergen, doe dit dan altijd via een pull request. Dan kunnen andere WebCie'rs ook de code checken op bugs of stijlfouten.<br />
<br />
== Branches ==<br />
<br />
;develop<br />
: Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.<br />
;master<br />
: De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je ''kan'' hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!<br />
;feature-$bla<br />
: Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.<br />
;refactor-$bla<br />
: Als je meer in het algemeen wilt refactoren, kan je daarvoor ook het beste een aparte branch maken, zodat er niet teveel ruis op <code>develop</code> is en zodat je er een pull request van kan maken.<br />
<br />
== Doetjes & Doe-nietjes ==<br />
<br />
* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek! <br />
* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.<br />
* '''Doe-niet''': <code>git cherry-pick</code>. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2018-01-15T18:40:53Z<p>Daanr: /* Branches */</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)<br />
<br />
== Branches ==<br />
<br />
;develop<br />
: Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.<br />
;master<br />
: De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je ''kan'' hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!<br />
;feature-$bla<br />
: Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.<br />
;refactor-$bla<br />
: Als je meer in het algemeen wilt refactoren, kan je daarvoor ook het beste een aparte branch maken, zodat er niet teveel ruis op <code>develop</code> is en zodat je er een pull request van kan maken.<br />
<br />
== Doetjes & Doe-nietjes ==<br />
<br />
* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek! <br />
* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.<br />
* '''Doe-niet''': <code>git cherry-pick</code>. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2018-01-15T18:38:36Z<p>Daanr: /* Doetjes & Doe-nietjes */</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)<br />
<br />
== Branches ==<br />
<br />
;develop<br />
: Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.<br />
;master<br />
: De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je ''kan'' hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!<br />
;feature-$bla<br />
: Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.<br />
<br />
== Doetjes & Doe-nietjes ==<br />
<br />
* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek! <br />
* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.<br />
* '''Doe-niet''': <code>git cherry-pick</code>. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Talk:CodestijlTalk:Codestijl2018-01-14T16:57:10Z<p>Daanr: Created page with "== Witregel voor <code>{</code> == : Openingshaakjes van blokken zijn verplicht en komen op de regel eronder. (Dus <code>→ if (...)\n→ {\n→ → ...</code>) Weet niet z..."</p>
<hr />
<div>== Witregel voor <code>{</code> ==<br />
<br />
: Openingshaakjes van blokken zijn verplicht en komen op de regel eronder. (Dus <code>→ if (...)\n→ {\n→ → ...</code>)<br />
<br />
Weet niet zeker of ik 't hier mee eens ben; is dit de gangbare stijl in PHP-land? -- [[User:Daanr|Daanr]] ([[User talk:Daanr|talk]]) 17:57, 14 January 2018 (CET)</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/CodestijlCodestijl2018-01-14T16:52:45Z<p>Daanr: Iets duidelijker verwoorden</p>
<hr />
<div>Omdat we nog genoeg fietsenstallingen hebben, hebben we hier een korte opsomming van wat we mooie stijl vinden.<br />
<br />
* Indentatie is een tab, en doorgaan van regels is twee tabs.<br />
* Regels langer dan 80 karakters zijn lelijk maar niet verboden. Dus, wees niet bang om statements en expressies over meerdere regels te verdelen.<br />
* Na een blok (functiedefinities, <code>if</code>, <code>foreach</code> etc.) komt precies één witregel.<br />
* Openingshaakjes van blokken zijn verplicht en komen op de regel eronder. (Dus <code>→ if (...)\n→ {\n→ → ...</code>)<br />
* Klassen zijn UpperCamelCase en functies, variabelen enzo zijn lowerCamelCase.<br />
* Heb je een afkorting zoals CSV, dan doen we CamelCase nog steeds met hoofdletters: <code>CSVPagina</code>, niet <code>CsvPagina</code>.<br />
* Code is Nederlandstalig, dus gebruik Nederlandse woorden. Ga hierin ook weer niet te ver: <code>BlaView::tabel()</code> ipv <code>BlaView::table()</code> maar <code>BlaView</code> ipv <code>BlaBlik</code>.<br />
* Doxygen-commando's zijn met @: <code>@brief</code>, <code>@param</code> bla, <code>@returns</code>, enz.<br />
* De <code>HTMLPage</code> maak je aan in de controller, de view returnt <code>HTMLObject</code>en die je erin kan stoppen.<br />
* Als je wilt je checken of iets <code>NULL</code> is, gebruik dan altijd <code>is_null()</code>.<br />
* Gebruik [[Responses]] ipv stateful functies.<br />
* Gebruik <code>new $blaPage()</code> ipv <code>Page::getInstance('$bla')</code><br />
<br />
Vul je andere favoriete pet peeves hier in!<br />
<br />
Als je met (bestaande) code bezig bent die zich niet helemaal houdt aan deze stijl, fix dat dan (minstens in de methode waar het om gaat).<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-07T12:31:46Z<p>Daanr: /* Daan */</p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= [[User:Daanr|Daan]] =<br />
<br />
Ongeveer op lexicografische volgorde van 'realistisch, belangrijk' naar 'P = NP, niet zo belangrijk'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Zorg dat de PromoCie weer toegang heeft tot de vertaalstrings op de een of andere manier<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Gebruik Dia niet meer als model-definitie format, want het is echt niet chill voor version control.<br />
* Gooi FotoWeb weg ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om URL parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Meer DevOps dingen, makkelijker je eigen developer env en de production env draaien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N want dat is ''web scale''<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
= [[User:Timb|Timb]] =<br />
<br />
* Een fijn (unit)testsysteem. (werk ik aan!)<br />
* De meeste functies zijn zo goed als puur, en de functies die niet puur zijn komen niet in een View voor.<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Continuous integration.<br />
* 100 % code coverage.<br />
* Decorator-achtige constructies voor requireAuth enzo.<br />
* dia2php poept volautomatisch een hele CRUD-app uit.<br />
* Herschrijf de website in Swail, de toffe Haskell-en-Python-hadden-een-baby programmeertaal die je helpt te zeggen wat je bedoelt (en die syntactische whitespace heeft!).<br />
* Volledig automatisch je testomgeving maken.<br />
* Een formeel bewijs dat de website featurecompleet is.<br />
* Onze eis is niets meer, maar kan ook niets minder zijn, dan het Goede Leven voor elk persoon.<br />
* Bewijs dat P =/= NP.<br />
<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-07T12:30:53Z<p>Daanr: /* Daan */</p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= [[User:Daanr|Daan]] =<br />
<br />
Ongeveer op lexicografische volgorde van 'realistisch, belangrijk' naar 'P = NP, niet zo belangrijk'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Zorg dat de PromoCie weer toegang heeft tot de vertaalstrings op de een of andere manier<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Gooi FotoWeb weg ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om URL parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Meer DevOps dingen, makkelijker je eigen developer env en de production env draaien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N want dat is ''web scale''<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
= [[User:Timb|Timb]] =<br />
<br />
* Een fijn (unit)testsysteem. (werk ik aan!)<br />
* De meeste functies zijn zo goed als puur, en de functies die niet puur zijn komen niet in een View voor.<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Continuous integration.<br />
* 100 % code coverage.<br />
* Decorator-achtige constructies voor requireAuth enzo.<br />
* dia2php poept volautomatisch een hele CRUD-app uit.<br />
* Herschrijf de website in Swail, de toffe Haskell-en-Python-hadden-een-baby programmeertaal die je helpt te zeggen wat je bedoelt (en die syntactische whitespace heeft!).<br />
* Volledig automatisch je testomgeving maken.<br />
* Een formeel bewijs dat de website featurecompleet is.<br />
* Onze eis is niets meer, maar kan ook niets minder zijn, dan het Goede Leven voor elk persoon.<br />
* Bewijs dat P =/= NP.<br />
<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-05T00:13:49Z<p>Daanr: </p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= [[User:Daanr|Daan]] =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Gooi FotoWeb weg ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om URL parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Meer DevOps dingen, makkelijker je eigen developer env en de production env draaien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
= [[User:Timb|Timb]] =<br />
<br />
* Een fijn (unit)testsysteem. (werk ik aan!)<br />
* De meeste functies zijn zo goed als puur, en de functies die niet puur zijn komen niet in een View voor.<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Continuous integration.<br />
* 100 % code coverage.<br />
* Decorator-achtige constructies voor requireAuth enzo.<br />
* dia2php poept volautomatisch een hele CRUD-app uit.<br />
* Herschrijf de website in Swail, de toffe Haskell-en-Python-hadden-een-baby programmeertaal die je helpt te zeggen wat je bedoelt (en die syntactische whitespace heeft!).<br />
* Volledig automatisch je testomgeving maken.<br />
* Een formeel bewijs dat de website featurecompleet is.<br />
* Onze eis is niets meer, maar kan ook niets minder zijn, dan het Goede Leven voor elk persoon.<br />
* Bewijs dat P =/= NP.<br />
<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:58:37Z<p>Daanr: </p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= [[User:Daanr|Daan]] =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Gooi FotoWeb weg ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om URL parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:57:51Z<p>Daanr: /* Daan */</p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= Daan =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Gooi FotoWeb weg ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om URL parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:57:26Z<p>Daanr: </p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= Daan =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Gooi FotoWeb weg ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om HTTP parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:56:34Z<p>Daanr: /* Daan */</p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= Daan =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om HTTP parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:55:59Z<p>Daanr: </p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in, of doen met, de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= Daan =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om HTTP parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:55:33Z<p>Daanr: </p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in/doen met de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= Daan =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Test meer dingen. (Wordt aan gewerkt.)<br />
* Maak Benamite/WhosWho4 chiller om te gebruiken. Vooral op het gebied van routing. Bijvoorbeeld dat je expliciet in een controllerfunctie kan zeggen wat voor parameters erin je parameters moeten. Zie: Flask.<br />
* Test controllerfuncties á la QuickCheck. Dus dan moet je een manier vinden om HTTP parameters te... parameteriseren. En geen idee of een QuickCheck-achtige library voor PHP bestaat, en zo nee, hoe die eruit zou moeten zien.<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die (REST) API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met bovenstaand item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WishlistWishlist2017-12-04T23:37:56Z<p>Daanr: Created page with "Hier kan je dingen neerzetten die je graag zou zien in/doen met de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het n..."</p>
<hr />
<div>Hier kan je dingen neerzetten die je graag zou zien in/doen met de code of website. Dit kunnen dan een soort persoonlijke TODO's of ideëen zijn, of iets wat meer is van het niveau "herschrijf alles in Idris", i.e. lulz.<br />
<br />
= Daan =<br />
<br />
Ongeveer op volgorde van 'realistisch' naar 'P = NP'.<br />
<br />
* Upgrade naar PHP 7.<br />
* Upgrade naar PostgreSQL.<br />
* Maak de dia2php netter, i.e. minder met teringlange strings met allemaal tabs erin. Iets met een expliciete AST en quasiquoting ofzo.<br />
* Maak alles een tikje meer microservice-achtig, door ledenbeheer e.d. in een kern-API te stoppen, en dan 'apps' op basis van die API te implementeren. Gevolg hiervan is dat je dan ook andere talen dan PHP kan gebruiken, zonder dat je alles hoeft te herschrijven!<br />
* Waarschijnlijk samen met de vorige item: doe leuke & fijne frontend dingen met Elm/PureScript/TypeScript/WebAssembly.<br />
* C O N T A I N E R I Z A T I O N<br />
* Herschrijf de website in de toffe Haskell-en-Python-hadden-een-baby taal die [[User:Timb|Tim]] ooit gaat maken.<br />
* Bewijs dat P = NP.<br />
* Verander PHP in een goede taal.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Docu_Todo_(WebCie)Docu Todo (WebCie)2017-12-04T23:23:19Z<p>Daanr: Daanr moved page WebCie Docu Todo to Docu Todo (WebCie): Betere alfabetische sortering -> makkelijker te vinden</p>
<hr />
<div>De volgende onderwerpen mogen nog wel eens gedocumenteerd worden:<br />
<br />
== Voor de WebCie zelf ==<br />
<br />
* [[Dia en generated code]] (wat is dia, hoe bewerk ik het, wat te doen bij merge conflicts?)<br />
* [[Generator aanpassen]] (stel dat ik niet tevreden ben met de manier waarop de generator werkt, hoe pas ik dat aan?)<br />
* [[Ingewerkt WebCie-lid]] (ik ben zojuist door de inwerking gekomen, wat nu?)<br />
* [[Scripts_(WebCie)]] (wat doen de verscheidene scripts?)<br />
* [[Antieke code aanpassen]] (bookweb moet anders, wat nu?)<br />
* [[Noodgevallen WebCie]] (poep is op de fik, wat nu?)<br />
* [[Checklist voor werkavonden]] (heb je al eens geupt? hoe staat het met je overleg? zijn je libraries nog up to date? is de hoeveelheid nicolas cages adequaat?)<br />
<br />
== Voor de "gewone" gebruikers ==<br />
<br />
* [https://www.a-eskwadraat.nl/Onderwijs/Boekweb/Handleidingen/ Boekenweb voor de BoekCom]<br />
* [[DiBSstatistieken]] (wat betekenen al die grafiekjes?)<br />
* [[Introdingen]] (wat moet de WebCie doen voor de intro? Wat moet de Intro doen op de website?)<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WebCie_Docu_TodoWebCie Docu Todo2017-12-04T23:23:19Z<p>Daanr: Daanr moved page WebCie Docu Todo to Docu Todo (WebCie): Betere alfabetische sortering -> makkelijker te vinden</p>
<hr />
<div>#REDIRECT [[Docu Todo (WebCie)]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/CodestijlCodestijl2017-12-04T22:09:31Z<p>Daanr: Regel over witruimte na een blok</p>
<hr />
<div>Omdat we nog genoeg fietsenstallingen hebben, hebben we hier een korte opsomming van wat we mooie stijl vinden.<br />
<br />
* Indentatie is een tab, en doorgaan van regels is twee tabs.<br />
* Regels langer dan 80 karakters zijn lelijk maar niet verboden. Dus, wees niet bang om statements en expressies over meerdere regels te verdelen.<br />
* Na een blok (functiedefinities, <code>if</code>, <code>foreach</code> etc.) komt precies één witregel.<br />
* Klassen zijn UpperCamelCase en functies, variabelen enzo zijn lowerCamelCase.<br />
* Heb je een afkorting zoals CSV, dan doen we CamelCase nog steeds met hoofdletters: <code>CSVPagina</code>, niet <code>CsvPagina</code>.<br />
* Doxygen-commando's zijn met @: <code>@brief</code>, <code>@param</code> bla, <code>@returns</code>, enz.<br />
* De <code>HTMLPage</code> maak je aan in de controller, de view returnt <code>HTMLObject</code>en die je erin kan stoppen.<br />
* Als je wilt je checken of iets <code>NULL</code> is, gebruik dan altijd <code>is_null()</code>.<br />
<br />
Vul je andere favoriete pet peeves hier in!<br />
<br />
Als je iets in code verandert die zich niet helemaal houdt aan deze stijl, fix dat dan (minstens in de methode waar het om gaat).<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/CodestijlCodestijl2017-12-04T21:52:15Z<p>Daanr: Opmerking over stijl fixen</p>
<hr />
<div>Omdat we nog genoeg fietsenstallingen hebben, hebben we hier een korte opsomming van wat we mooie stijl vinden.<br />
<br />
* Indentatie is een tab, en doorgaan van regels is twee tabs.<br />
* Regels langer dan 80 karakters zijn lelijk maar niet verboden.<br />
* Klassen zijn UpperCamelCase en functies, variabelen enzo zijn lowerCamelCase.<br />
* Heb je een afkorting zoals CSV, dan doen we CamelCase nog steeds met hoofdletters: <code>CSVPagina</code>, niet <code>CsvPagina</code>.<br />
* Doxygen-commando's zijn met @: <code>@brief</code>, <code>@param</code> bla, <code>@returns</code>, enz.<br />
* De <code>HTMLPage</code> maak je aan in de controller, de view returnt <code>HTMLObject</code>en die je erin kan stoppen.<br />
* Als je wilt je checken of iets <code>NULL</code> is, gebruik dan altijd <code>is_null()</code>.<br />
<br />
Vul je andere favoriete pet peeves hier in!<br />
<br />
Als je iets in code verandert die zich niet helemaal houdt aan deze stijl, fix dat dan (minstens in de methode waar het om gaat).<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/CodestijlCodestijl2017-12-04T21:50:17Z<p>Daanr: Opmerking over is_null()</p>
<hr />
<div>Omdat we nog genoeg fietsenstallingen hebben, hebben we hier een korte opsomming van wat we mooie stijl vinden.<br />
<br />
* Indentatie is een tab, en doorgaan van regels is twee tabs.<br />
* Regels langer dan 80 karakters zijn lelijk maar niet verboden.<br />
* Klassen zijn UpperCamelCase en functies, variabelen enzo zijn lowerCamelCase.<br />
* Heb je een afkorting zoals CSV, dan doen we CamelCase nog steeds met hoofdletters: <code>CSVPagina</code>, niet <code>CsvPagina</code>.<br />
* Doxygen-commando's zijn met @: <code>@brief</code>, <code>@param</code> bla, <code>@returns</code>, enz.<br />
* De <code>HTMLPage</code> maak je aan in de controller, de view returnt <code>HTMLObject</code>en die je erin kan stoppen.<br />
* Als je wilt je checken of iets <code>NULL</code> is, gebruik dan altijd <code>is_null()</code>.<br />
<br />
Vul je andere favoriete pet peeves hier in!<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/CodestijlCodestijl2017-12-04T21:49:15Z<p>Daanr: Meer code tags == meer beter</p>
<hr />
<div>Omdat we nog genoeg fietsenstallingen hebben, hebben we hier een korte opsomming van wat we mooie stijl vinden.<br />
<br />
* Indentatie is een tab, en doorgaan van regels is twee tabs.<br />
* Regels langer dan 80 karakters zijn lelijk maar niet verboden.<br />
* Klassen zijn UpperCamelCase en functies, variabelen enzo zijn lowerCamelCase.<br />
* Heb je een afkorting zoals CSV, dan doen we CamelCase nog steeds met hoofdletters: <code>CSVPagina</code>, niet <code>CsvPagina</code>.<br />
* Doxygen-commando's zijn met @: <code>@brief</code>, <code>@param</code> bla, <code>@returns</code>, enz.<br />
* De <code>HTMLPage</code> maak je aan in de controller, de view returnt <code>HTMLObject</code>en die je erin kan stoppen.<br />
<br />
Vul je andere favoriete pet peeves hier in!<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/SVN_(WebCie)SVN (WebCie)2017-11-27T21:39:11Z<p>Daanr: Daanr moved page WebCie SVN to SVN (WebCie): Betere alfabetische sortering -> makkelijker te vinden</p>
<hr />
<div>[[Category:WebCie]]<br />
<br />
We gebruiken tegenwoordig [[WebCie Git]], dus het overgrote gedeelte van de pagina staat vanaf nu in html-comments. Check dus de source als je toch nog SVN moet leren!<br />
<br />
<!--<br />
SVN (Subversion) is het magische systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Ieder WebCie-lid heeft een kopie (een checkout) van het volledige systeem staan op zijn eigen account (in de map ~/wwwdebug). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op http://blabla.debug.a-eskwadraat.nl). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp. <br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met SVN.<br />
<br />
==svn up==<br />
Met <code>svn up</code> zorg je ervoor dat je locale versie geupdate wordt met alle wijzigingen die de rest van de WebCie heeft aangebracht. Doe dit dus altijd voordat je begint met hekken, anders wijzig je misschien dingen die al door anderen gewijzigd zijn en bestaat de kans op collisions!<br />
<br />
Typische output van een <code>svn update</code>:<br />
<pre><br />
[otto@nikola]~/wwwdebug$ svn up<br />
U www/WhosWho4/Controllers/Activiteiten.php<br />
U www/WhosWho4/Activiteit.view.php<br />
U www/WhosWho4/Deelnemer.cls.php<br />
U www/WhosWho4/Lid.view.php<br />
<br />
Fetching external item into 'libdb'<br />
External at revision 75.<br />
<br />
<br />
Fetching external item into 'gettext/voc'<br />
External at revision 153.<br />
<br />
At revision 12329.<br />
</pre><br />
<br />
==svn st==<br />
Met <code>svn st</code> vraag je de huidige status op van jouw lokale kopie.<br />
<pre><br />
[otto@nikola]~/wwwdebug$ svn st<br />
X libdb<br />
S gettext<br />
X gettext/voc<br />
S www<br />
M www/WhosWho4/Activiteit.view.php<br />
M www/javascript/Activiteit/Wijzig.js<br />
S lib<br />
S scripts<br />
M scripts/script-init.php<br />
S docs<br />
<br />
Performing status on external item at 'libdb'<br />
<br />
Performing status on external item at 'gettext/voc'<br />
</pre><br />
Je ziet een lijstje met wijzigingen. Je kan de items met een X of een S ervoor negeren, evenals scripts/script-init.php.<br />
<br />
We concluderen dat de bestanden <code>www/WhosWho4/Activiteit.view.php</code> en <code>www/javascript/Activiteit/Wijzig.js</code> gewijzigd zijn.<br />
<br />
==svn diff==<br />
Met <code>svn diff</code> bekijk je alle wijzigingen die er zijn tussen jouw lokale kopie en de huidige revisie. Gebruik <code>svn diff bestand1 bestand2 ...</code> om de wijzigingen van een of meer bestanden te bekijken. <br />
<br />
Met plusjes en minnetjes wordt er weergegeven welke regels weggehaald zijn en welke er bij zijn gekomen.<br />
<br />
==svn ci==<br />
Als je tevreden bent met de wijzigingen die <code>svn diff</code> je voorgeschoteld hebt, kan je je werk committen met <code>svn ci</code>. Ook hier kan je weer losse bestanden mee pakken door die erachter te zetten zoals bij diff. Je komt dan in nano terecht, en er staat welke bestanden je op het punt staat te committen.<br />
<br />
Schrijf een duidelijke omschrijving van wat jouw commit bewerkstelligd, anders wordt de rest van de WebCie boos! Vervolgens ram je op Ctrl-X en Y, en hopla jouw wijzigingen worden opgenomen in het centrale systeem. Als jouw collega's svn uppen krijgen ze dus jouw code!<br />
<br />
==Overig==<br />
#<code>svn add bestand</code> - gebruik dit als je een volledig nieuw bestand hebt gemaakt. Nu wordt deze ook meegenomen bij je svn status, diffs en commits!<br />
#<code>svn revert bestand</code> - als je een chaos van een bestand hebt gemaakt, reset je hem hiermee weer naar de versie zoals die centraal geadministreerd stond.<br />
<br />
==Collisions==<br />
Als je dit ziet, ben je de sjaak:<br />
<br />
<pre><br />
[otto@nikola]~/wwwdebug$ svn up<br />
U www/WhosWho4/Controllers/Activiteiten.php<br />
U www/WhosWho4/Activiteit.view.php<br />
U www/WhosWho4/Deelnemer.cls.php<br />
U www/WhosWho4/Lid.view.php<br />
U www/WhosWho4/Contact.cls.php<br />
Conflict discovered in 'www/WhosWho4/Persoon.view.php'.<br />
Select: (p) postpone, (df) diff-full, (e) edit,<br />
(mc) mine-conflict, (tc) theirs-conflict,<br />
(s) show all options:<br />
</pre><br />
<br />
Je hebt dan wijzigingen aangebracht in een bestand dat inmiddels door iemand anders is gewijzigd en gecommit, en deze wijziging botst met die van jouw. Wederom een reden om vaak <code>svn up</code> te doen! <br />
<br />
Neem de tijd om even te kijken wat het probleem is (de commit van je collega staat in je mail), je kan expliciet het probleem zien door <code>df</code> (diff full) te typen.<br />
<br />
Dan concludeer je meestal dat je collega gelijk heeft, en jouw wijziging genegeerd moet worden. Kies daarvoor <code>tf</code> (theirs-full). Je bestand wordt dan volledig geoverride, wat meestal de bedoeling is. <br />
<br />
Schakel indien nodig een ervarener WebCie-er in.<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Ga naar de live vm met <code>ssh vm-www</code> en log in als WebCie met <code>s webcie</code>. De site staat in <code>/srv/http/www/www</code>, en je kunt gewoon een <code>svn up</code> doen om de live site up-to-date te maken met de SVN repo.<br />
<br />
== Geen wachtwoorden! ==<br />
Uit een mail van een zekere [[User:Pepijno|Pepijn "neger" Overbeeke]]:<br />
<br />
Goed nieuws! Minder wachtwoorden! Het is me eindelijk gelukt om authenticatie van de svn-repo te koppellen aan het systeem dus we hebben geen aparte wachtwoorden voor de svn meer nodig. Het is zelfs zo dat als je in de werkkamer bent ingelogd dat je dan helemaal geen wachtwoord meer nodig hebt om bij de svn te komen (dit betekent niet dat iedereen er zomaar bij kan). Dat komt vanwege kerberos tickets enzo. Overigens is de default fallback als je geen kerberosticket hebt je systeemaccount met systeemwachtwoord, maar met een kerberosticket is de svn wel een heel stuk sneller. Je kan altijd een nieuwe ticket krijgen door in de terminal 'kinit *account*' te doen (met natuurlijk als account je eigen accountnaam). Anyway, mochten er problemen mee zijn, laat het dan vooral aan me weten.<br />
<br />
--><br />
<br />
== Hoe verhuis ik SVN naar Git? ==<br />
<br />
In december 2016 heeft de WebCie besloten om over te stappen naar Git. Omdat dit nogal een klus is en meerdere dagen duurde, leek het [[User:Timb|me]] handig om voor mezelf ook meteen bij te houden wat er voor stappen nodig waren. Zie ook [https://stackoverflow.com/questions/79165/how-to-migrate-svn-repository-with-history-to-a-new-git-repository StackOverflow] en [http://www.pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/ iemands website].<br />
<br />
Maak in je homedir een mapje waar alle tsjak in terechtkomt.<br />
<pre><br />
mkdir ~/svn2git<br />
</pre> <br />
<br />
Eerst zoeken we alle committers uit zodat we die naar git kunnen vertalen.<br />
<pre><br />
cd ~/wwwdebug<br />
git svn rebase<br />
git shortlog -sn > ~/svn2git/committers.txt<br />
cd ~/svn2git<br />
</pre><br />
(alternatief als je nog geen gitsvn-checkout hebt, maar werkt niet want er staan HEEL ERG VEEL dingen in SVN:<br />
<pre><br />
svn log --quiet https://svn.a-eskwadraat.nl/svn/www/ | grep '^r' | awk '{print $3}' | sort -u > committers.txt<br />
</pre><br />
<br />
Vertaal nu gebruikersnamen naar naam + emailadres (het formaat is <code>gebruikersnaam = Naam &lt;emailadres&rt;</code>. Gebruik bijvoorbeeld dit vim-macro: <code>|df→yiw$a = ^[pa <^[pa@a-eskwadraat.nl>^[j</code> (waarbij <code>→</code> staat voor tab en <code>^[</code> voor escape)<br />
<pre><br />
vim authors.txt<br />
</pre><br />
<br />
We gaan nu een schone kopie van de repo maken om daar verscheidene vertalingen op toe te passen. Dit duurt '''ongelofelijk''' lang want er staan HEEL ERG VEEL dingen in SVN:<br />
<pre><br />
git svn clone https://svn.a-eskwadraat.nl/svn/www/ --no-metadata -A authors.txt -t tags -b branches -T trunk wwwdebug >>fetch_log 2>>error_log<br />
</pre><br />
(Merk op dat we elke branch uitchecken en het op zijn minst lineair is in het totaal aantal wijzigingen in elke commit op elke branch, wat ook wel O(griezelig groot) heet.)<br />
<br />
Je kan nu misschien de volgende errors krijgen (hiervoor hebben we de bestanden fetch_log en error_log want een paar duizend commits keer een paar duizend files scrolt meteen uit je terminalbuffer):<br />
<br />
* ontbrekende author: voeg die toe in authors.txt en <code>git svn fetch >>fetch_log 2>>error_log</code> verder<br />
* ontbrekende bestanden (absent_file en/of object not found in commit): ''Volgens het internet:'' doe <code>git svn reset -r...</code> tot de laatste commit die wel klopte en <code>git svn fetch >>fetch_log 2>>error_log</code> verder. Dit bleek niet te werken bij het fetchen van r15195 naar trunk, dus toen ben ik maar een bestaande git-svn checkout gaan bewerken.<br />
<br />
Vraag een sysopper of die heel lief voor je wil zijn en de commithooks uit de svn-repository in <code>~/svn2git/hooks</code> wil zetten. Liefst ook het script dat de WebCie een mail stuurt als een nieuwe commit is gepusht, op dit moment te vinden in <code>/usr/share/subversion/hook-scripts/mailer/mailer.py</code><br />
<br />
Nu gaan we nog wat restjes ledendata weghalen, want blijkbaar was het een ding vroeger om ledendata in je repo te zetten... Zie ook [https://stackoverflow.com/questions/13988511/remove-a-directory-from-all-previous-commits StackOverflow].<br />
<pre><br />
git filter-branch --index-filter 'git rm --cached -r --ignore-unmatch www/whoswho_cprogs.old/' --prune-empty --tag-name-filter cat -- --all<br />
</pre><br />
(Check of het ook weg is in de obsolete branch, of mieter gewoon die hele branch weg!)<br />
<br />
Importeer de commit-hooks van subversion en pas ze aan zodat ze met git werken. Ik heb besloten om ze in een nieuwe map hooks te zetten en dan te symlinken. Dit is een boel gespecialiseerd programmeerwerk, dus kan ik verder geen hints voor geven. Check wel even dat al je dingen executable zijn!<br />
<br />
Pas in je lokale repository ook de cronscripts aan zodat ze werken met git ipv svn.<br />
<br />
Nu gaan we dingen beschikbaar maken! Maak een repo voor alle commits en eentje voor de hooks. Op <code>vm-www</code>:<br />
<br />
<pre><br />
sudo mkdir -p /srv/git /srv/git-hooks<br />
sudo chown webcie:webcie /srv/git /srv/git-hooks<br />
sudo chmod o= /srv/git /srv/git-hooks<br />
sudo chmod ug=rwx /srv/git /srv/git-hooks<br />
sudo chmod g+s /srv/git /srv/git-hooks<br />
cd /srv/git<br />
git init --bare # want we willen niet dat er een checkout komt!<br />
cd ../git-hooks<br />
git init<br />
git remote add origin ../git<br />
git config core.sparsecheckout true # we hoeven alleen de hooks hier te hebben<br />
echo hooks/ >> .git/info/sparse-checkout<br />
</pre><br />
<br />
In je lokale git-repo:<br />
<pre><br />
git remote add origin ssh://vm-www/srv/git<br />
git push origin master<br />
</pre><br />
<br />
Op vm-www, in <code>/srv/git-hooks</code>:<br />
<pre><br />
git pull<br />
cd /srv/git/hooks<br />
ln -s /srv/git-hooks/* .<br />
</pre><br />
<br />
Installeer een ssh key zodat je als user webcie kan git pull'en.<br />
Op vm-www-debug als user webcie:<br />
<pre><br />
ssh-keygen <br />
ssh-copy-id vm-www <br />
<br />
# Maak nu de repo voor demosite <br />
mkdir /srv/http/demo/git <br />
cd /srv/http/demo/git <br />
git init <br />
git remote add origin ssh://vm-www/srv/git <br />
git pull origin master <br />
<br />
# Stop de huidige inhoud van demosite in je git-repo <br />
rm -r gettext lib scripts share www <br />
mv ../gettext ../lib ../scripts ../share ../www . <br />
# en gebruik symlinks om het weer werkend te krijgen <br />
ln -s /srv/http/demo/git/gettext .. <br />
ln -s /srv/http/demo/git/lib .. <br />
ln -s /srv/http/demo/git/scripts .. <br />
ln -s /srv/http/demo/git/share .. <br />
ln -s /srv/http/demo/git/www ..<br />
</pre><br />
<br />
Check goed dat alles werkt (zie ook [https://www.a-eskwadraat.nl/Service/Bugweb/7334 Bug #7334] voor een error die random was begonnen te gebeuren en random weer ophield), en doe hetzelfde voor de livesite in <code>/srv/http/www/git</code> (ik ga geen commando's geven want je moet hier heel goed bij nadenken!)<br />
<br />
Ook nog wat cronjobs installeren (die je als het goed is al hebt vertaald van svn naar git!)<br />
<br />
Op vm-www-debug als user webcie:<br />
<pre> <br />
cd /srv/http/demo/scripts <br />
crontab -l # check dat je de juiste crontab wil aanpassen <br />
crontab cron/crontab_vm-www-debug.webcie <br />
</pre><br />
Op vm-www als user webcie:<br />
<pre> <br />
cd /srv/http/demo/scripts <br />
crontab -l # check dat je de juiste crontab wil aanpassen <br />
crontab cron/crontab_vm-www.webcie <br />
</pre> <br />
<br />
Zorg er tenslotte "eventjes" voor dat iedereen overstapt naar Git en alle documentatie weer klopt.</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WebCie_SVNWebCie SVN2017-11-27T21:39:11Z<p>Daanr: Daanr moved page WebCie SVN to SVN (WebCie): Betere alfabetische sortering -> makkelijker te vinden</p>
<hr />
<div>#REDIRECT [[SVN (WebCie)]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2017-11-20T22:52:23Z<p>Daanr: Schrijf die shit</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)<br />
<br />
== Branches ==<br />
<br />
;develop<br />
: Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.<br />
;master<br />
: De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je ''kan'' hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!<br />
;feature-$bla<br />
: Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.<br />
<br />
== Doetjes & Doe-nietjes ==<br />
<br />
* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek! <br />
* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat bisecten en blamen wat moeilijker gaat, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.<br />
* '''Doe-niet''': <code>git cherry-pick</code>. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2017-11-20T17:37:46Z<p>Daanr: /* Branches */</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows<br />
<br />
== Branches ==<br />
;develop<br />
:<br />
;master<br />
:<br />
;feature-$bla<br />
:<br />
;bug-$bla<br />
:<br />
<br />
== Dos & Don'ts ==<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_WorkflowGit Workflow2017-11-20T17:37:15Z<p>Daanr: Created page with "Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het m..."</p>
<hr />
<div>Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.<br />
<br />
Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.<br />
<br />
Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows<br />
<br />
== Branches ==<br />
;develop<br />
:<br />
;master<br />
:<br />
;feature-$bla<br />
:<br />
;bug-$bla<br />
:<br />
<br />
== Dos & Don'ts<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-11-13T23:28:56Z<p>Daanr: /* Migreren tussen Git-repo's */</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijvoorbeeld de URL <code>git.example.com/user/repo</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTE_URL</code> &mdash; Voeg de nieuwe repository als een remote toe.<br />
* <code>git fetch origin</code> &mdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. ([https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
<br />
En klaar is Kees! (Hopelijk...)<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WebCie_GitWebCie Git2017-11-12T22:00:28Z<p>Daanr: Daanr moved page WebCie Git to Git (WebCie): Betere alfabetische sortering -> makkelijker te vinden</p>
<hr />
<div>#REDIRECT [[Git (WebCie)]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-11-12T22:00:27Z<p>Daanr: Daanr moved page WebCie Git to Git (WebCie): Betere alfabetische sortering -> makkelijker te vinden</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijvoorbeeld de URL <code>git.example.com/user/repo</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code> &mdash; Voeg de nieuwe repository als een remote toe.<br />
* <code>git fetch origin</code> &mdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. ([https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
<br />
En klaar is Kees! (Hopelijk...)<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-11-06T15:26:40Z<p>Daanr: /* Migreren tussen Git-repo's */</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijvoorbeeld de URL <code>git.example.com/user/repo</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code> &mdash; Voeg de nieuwe repository als een remote toe.<br />
* <code>git fetch origin</code> &mdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. ([https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
<br />
En klaar is Kees! (Hopelijk...)<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-11-06T15:26:22Z<p>Daanr: /* Migreren tussen Git-repo's */ Afkortingen zijn eigenlijk helemaal niet cool.</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijvoorbeeld de URL <code>git.example.com/user/repo</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code> &mdash; Voeg de nieuwe repository als een remote toe.<br />
* <code>git fetch origin</code> &emdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. ([https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
<br />
En klaar is Kees! (Hopelijk...)<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-10-30T21:52:46Z<p>Daanr: Pleur de gecommente tsjak weg. Je kan het toch teruglezen in de revisiegeschiedenis.</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijv. de URL <code>git.example.com</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code> &mdash; Voeg de nieuwe repository als een remote toe. <br />
* <code>git fetch origin</code> &emdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. [https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-10-30T21:51:55Z<p>Daanr: /* Migreren tussen Git-repo's */</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijv. de URL <code>git.example.com</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code> &mdash; Voeg de nieuwe repository als een remote toe. <br />
* <code>git fetch origin</code> &emdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. [https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
<br />
<!-- Info van voor de overstap naar git, weet niet of we dit nog willen hebben.<br />
<br />
Als je liever <code>git</code>'t dan <code>svn</code>'t (en je hebt zin om te leren hoe dat samengaat), dan kun je gebruik maken van <code>git-svn</code>. Lees van te voren ook even de online documentatie hiervan, want het loopt allemaal net wat anders dan svn werkt of git zonder svn werkt.<br />
<br />
== Je eerste checkout ==<br />
<br />
Het handigste is als je een schone checkout maakt van de code, want dan heb je gittroep niet tussen svntroep. Het uitchecken duurt best lang, dus start eerst een <code>screen</code>sessie op! Dan kun je binnen die screensessie <code>git svn checkout</code> doen op de huidige svn-repo (zie [[WebCie SVN]] voor de url). Na heel wat gecheckout waarbij een stuk of tienduizend commits worden binnengehaald, heb je een gitrepository waar je gewoon lokale branches hebt en alles!<br />
<br />
== Handige aliassen ==<br />
<br />
Je kan in git aliassen instellen om de volgende commando's af te korten. Ze doen ongeveer wat svn doet bij de corresponderende afkortingen, en vooral dat je dingen wat makkelijker met svn kan koppelen. Je mag natuurlijk ook gewoon alle git-svn-commando's uit je hoofd gaan leren.<br />
<br />
* ''git ci'': <code>git stash && git svn dcommit && git stash apply</code> (zet de commits in je lokale branch om in commits op de svn-server)<br />
* ''git up'': <code>git stash && git svn rebase && git stash apply</code> (haal alle nieuwe veranderingen uit de svn op en zet het tussen je werk neer)<br />
<br />
--><br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-10-30T21:51:20Z<p>Daanr: /* Migreren tussen Git-repo's */</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijv. de URL <code>git.example.com</code>.<br />
<br />
Een WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code> &mdash; Voeg de nieuwe repository als een remote toe. <br />
* <code>git fetch origin</code> &emdash; Haal alles op uit de huidige repository.<br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> &mdash; Hiermee pushen we alles van origin naar new-origin. [https://stackoverflow.com/questions/23947419 Aldus sprak StackOverflow]) Let wel: misschien pusht dit juist iets te veel. Bij het testen hiervan kwam er bijvoorbeeld een branch op de nieuwe remote met de naam HEAD. Dit moet je dan weer even deleten met e.g. <code>git push new-remote --delete HEAD</code>.<br />
* <code>git remote remove new-origin</code> &mdash; Verwijder de remote.<br />
<br />
Iedereen doet vervolgens:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code> &mdash;<br />
<br />
<!-- Info van voor de overstap naar git, weet niet of we dit nog willen hebben.<br />
<br />
Als je liever <code>git</code>'t dan <code>svn</code>'t (en je hebt zin om te leren hoe dat samengaat), dan kun je gebruik maken van <code>git-svn</code>. Lees van te voren ook even de online documentatie hiervan, want het loopt allemaal net wat anders dan svn werkt of git zonder svn werkt.<br />
<br />
== Je eerste checkout ==<br />
<br />
Het handigste is als je een schone checkout maakt van de code, want dan heb je gittroep niet tussen svntroep. Het uitchecken duurt best lang, dus start eerst een <code>screen</code>sessie op! Dan kun je binnen die screensessie <code>git svn checkout</code> doen op de huidige svn-repo (zie [[WebCie SVN]] voor de url). Na heel wat gecheckout waarbij een stuk of tienduizend commits worden binnengehaald, heb je een gitrepository waar je gewoon lokale branches hebt en alles!<br />
<br />
== Handige aliassen ==<br />
<br />
Je kan in git aliassen instellen om de volgende commando's af te korten. Ze doen ongeveer wat svn doet bij de corresponderende afkortingen, en vooral dat je dingen wat makkelijker met svn kan koppelen. Je mag natuurlijk ook gewoon alle git-svn-commando's uit je hoofd gaan leren.<br />
<br />
* ''git ci'': <code>git stash && git svn dcommit && git stash apply</code> (zet de commits in je lokale branch om in commits op de svn-server)<br />
* ''git up'': <code>git stash && git svn rebase && git stash apply</code> (haal alle nieuwe veranderingen uit de svn op en zet het tussen je werk neer)<br />
<br />
--><br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-10-30T21:21:07Z<p>Daanr: /* Migreren tussen Git-repo's */</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijv. de URL <code>git.example.com</code>.<br />
<br />
Elke WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code><br />
<br />
De volgende 2 commands hoeven maar één keer, door één persoon gedaan te worden:<br />
<br />
* <code>git fetch origin</code><br />
* <code>git push new-origin refs/remotes/origin/\*:refs/heads/\*</code> ([https://stackoverflow.com/questions/23947419/how-can-i-pull-every-branch-from-origin-remote-and-push-to-our-backup-remote Aldus sprak StackOverflow])<br />
<br />
En dit weer door iedereen:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
* <code>git remote remove new-origin</code><br />
<br />
<!-- Info van voor de overstap naar git, weet niet of we dit nog willen hebben.<br />
<br />
Als je liever <code>git</code>'t dan <code>svn</code>'t (en je hebt zin om te leren hoe dat samengaat), dan kun je gebruik maken van <code>git-svn</code>. Lees van te voren ook even de online documentatie hiervan, want het loopt allemaal net wat anders dan svn werkt of git zonder svn werkt.<br />
<br />
== Je eerste checkout ==<br />
<br />
Het handigste is als je een schone checkout maakt van de code, want dan heb je gittroep niet tussen svntroep. Het uitchecken duurt best lang, dus start eerst een <code>screen</code>sessie op! Dan kun je binnen die screensessie <code>git svn checkout</code> doen op de huidige svn-repo (zie [[WebCie SVN]] voor de url). Na heel wat gecheckout waarbij een stuk of tienduizend commits worden binnengehaald, heb je een gitrepository waar je gewoon lokale branches hebt en alles!<br />
<br />
== Handige aliassen ==<br />
<br />
Je kan in git aliassen instellen om de volgende commando's af te korten. Ze doen ongeveer wat svn doet bij de corresponderende afkortingen, en vooral dat je dingen wat makkelijker met svn kan koppelen. Je mag natuurlijk ook gewoon alle git-svn-commando's uit je hoofd gaan leren.<br />
<br />
* ''git ci'': <code>git stash && git svn dcommit && git stash apply</code> (zet de commits in je lokale branch om in commits op de svn-server)<br />
* ''git up'': <code>git stash && git svn rebase && git stash apply</code> (haal alle nieuwe veranderingen uit de svn op en zet het tussen je werk neer)<br />
<br />
--><br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-10-30T20:59:08Z<p>Daanr: /* Migreren tussen Git-repo's */</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijv. de URL <code>git.example.com</code>.<br />
<br />
Elke WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code><br />
<br />
De volgende 2 commands hoeven maar één keer, door één persoon gedaan te worden:<br />
<br />
* <code>git fetch origin</code><br />
* <code>git push new-origin refs/remotes/origin/*:refs/heads/*</code> ([https://stackoverflow.com/questions/23947419/how-can-i-pull-every-branch-from-origin-remote-and-push-to-our-backup-remote Aldus sprak StackOverflow])<br />
<br />
En dit weer door iedereen:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
* <code>git remote remove new-origin</code><br />
<br />
<!-- Info van voor de overstap naar git, weet niet of we dit nog willen hebben.<br />
<br />
Als je liever <code>git</code>'t dan <code>svn</code>'t (en je hebt zin om te leren hoe dat samengaat), dan kun je gebruik maken van <code>git-svn</code>. Lees van te voren ook even de online documentatie hiervan, want het loopt allemaal net wat anders dan svn werkt of git zonder svn werkt.<br />
<br />
== Je eerste checkout ==<br />
<br />
Het handigste is als je een schone checkout maakt van de code, want dan heb je gittroep niet tussen svntroep. Het uitchecken duurt best lang, dus start eerst een <code>screen</code>sessie op! Dan kun je binnen die screensessie <code>git svn checkout</code> doen op de huidige svn-repo (zie [[WebCie SVN]] voor de url). Na heel wat gecheckout waarbij een stuk of tienduizend commits worden binnengehaald, heb je een gitrepository waar je gewoon lokale branches hebt en alles!<br />
<br />
== Handige aliassen ==<br />
<br />
Je kan in git aliassen instellen om de volgende commando's af te korten. Ze doen ongeveer wat svn doet bij de corresponderende afkortingen, en vooral dat je dingen wat makkelijker met svn kan koppelen. Je mag natuurlijk ook gewoon alle git-svn-commando's uit je hoofd gaan leren.<br />
<br />
* ''git ci'': <code>git stash && git svn dcommit && git stash apply</code> (zet de commits in je lokale branch om in commits op de svn-server)<br />
* ''git up'': <code>git stash && git svn rebase && git stash apply</code> (haal alle nieuwe veranderingen uit de svn op en zet het tussen je werk neer)<br />
<br />
--><br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Git_(WebCie)Git (WebCie)2017-10-30T20:58:00Z<p>Daanr: Voeg een stukje over tussen Git-repo's migreren toe</p>
<hr />
<div>Git (wat staat voor "Git") is het bovennatuurlijke systeem waarmee we controle houden op wat er gebeurt met alle WebCie-code. Als WebCie-lid heb je een kopie (een ''checkout'') van het volledige systeem staan op je eigen account (in de map <code>~/wwwdebug</code>). Deze code bepaalt wat jij te zien krijgt in je browser als je naar je persoonlijke debugpagina gaat (lijkt op <code>https://bla-debug.a-eskwadraat.nl</code>). Als je wijzigingen in deze code aanbrengt, veranderen dus alleen de pagina's op jouw persoonlijke debug-omgeving. Dat noemen we een sandbox, het zorgt er voor dat je rustig je code kan ontwikkelen zonder dat de rest van de WWW daar last van heeft. Bovendien is jouw debugpagina alleen benaderbaar door WebCie-leden, dus als je per ongeluk lekkende SQL-queries schrijft is dat geen ramp.<br />
<br />
Op deze pagina staat basale info om aan de slag te gaan met Git. Je kan ook in de [https://git-scm.com/book/en/v2 online handleiding] kijken voor meer pro-tips.<br />
<br />
De WebCie is onlangs <!-- dat is dus 2017, laten we kijken hoe lang dat blijft staan --> overgestapt naar Git. Hierbij is ook de svn-geschiedenis gefilterd, dus pas op bij overstappen!<br />
<br />
== Workflow ==<br />
<br />
Een ding waar je bij git waarschijnlijk aan moet wennen is dat iedereen een eigen idee heeft van de geschiedenis van alle code. Op de server staan een setje commitgeschiedenissen (oftewel branches), en op je debug staat ook zo'n setje. Met een beetje geluk komen ze ook nog overeen, maar dat hoeft dus niet! Er zijn commando's om van iemand anders de geschiedenis overnemen. Dan krijg je een kopietje binnen van hun geschiedenis, maar wordt jouw geschiedenis ''niet'' aangepast! Je hebt bijvoorbeeld de volgende branches, allemaal opgeslagen in je eigen debug:<br />
<br />
* master (jouw laatste editie van de livesite)<br />
* develop (jouw eigen editie van de "echte" code)<br />
* feature-watleuks (jouw eigen editie van deze feature)<br />
* feature-zoveel (een feature waarvan de server nog helemaal niet weet dat die bestaat)<br />
* HEAD (wijst naar de laatste commit die bij jou is gebeurd, dus als het goed is de branch waar je nu op werkt)<br />
* origin/master (wat jij denkt dat de servereditie van de livesite is)<br />
* origin/develop (wat jij denkt dat de servereditie van de "echte" code is)<br />
* origin/feature-watleuks (wat jij denkt dat de servereditie van de deze feature is)<br />
<br />
Als je <code>git fetch</code> doet, zal git de laatste versie van elke branch van de server opvragen en die bewaren in origin/$branch. Dan kun je die weer in jouw branches stoppen met bijvoorbeeld <code>git merge</code>. Het commando <code>git pull</code> stuurt jouw editie van de huidige branch naar de server. (De server weet dus in principe niet welke gebruikers er zijn of welke branches ze hebben!)<br />
<br />
We hebben twee hoofdbranches: <code>master</code> en <code>develop</code>. De livesite zou gelijk moeten lopen met de branch <code>master</code>, dus we moeten goed opletten wat we daarop zetten. Om makkelijk code te kunnen delen, gaan we in principe alle commits doen op de branch <code>develop</code>, maar het is nog netter om met branches te werken.<br />
<br />
Handige commando's om het overzicht te bewaren:<br />
<br />
* <code>git log</code> om de commits op je huidige branch te bekijken.<br />
* <code>git log $commit-of-branch-of-etc</code> om de commits op een andere branch te bekijken. (Het is handig om hiervoor ook <code>git fetch</code> te doen.)<br />
* <code>gitk</code> als je beter tegen een grafische interface kan.<br />
* <code>git status</code> toont je branch, hoe die verschilt met origin/$branch en wat je ten opzichte van je branch hebt aangepast<br />
* <code>git branch -a</code> toont elke branch waar git in jouw debug van afweet<br />
* <code>git log --graph --decorate --pretty=oneline --abbrev-commit</code> om in de terminal een mooie gerichte graaf van commits te tonen (<code>--all</code> voor alle branches tegelijk)<br />
<br />
=== Maak een feature ===<br />
<br />
# <code>git checkout develop</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b feature-$bla</code><br />
# ga een stukje zitten programmeren<br />
# heb je nieuwe bestanden toegevoegd: vertel dat aan git met <code>git add $bestand</code><br />
# wil je bestanden weggooien: doe dat en vertel het tegelijk aan git met <code>git rm $bestand</code><br />
# wil je kijken wat je allemaal hebt gedaan: gebruik <code>git status</code> en/of <code>git diff</code><br />
# ben je tevreden met een setje wijzigingen: commit ze met <code>git add $gewijzigd_bestand1 $gewijzigd_bestand2 ...</code> en <code>git commit</code> (het is netjes om eerst nog even te kijken wat je gaat committen zodat er geen troep meekomt)<br />
# herhaal bovenstaande stappen tot je feature helemaal af is<br />
# ben je klaar: stop je feature in develop met <code>git checkout develop</code> en dan <code>git merge feature-$bla</code> en maak het openbaar met <code>git push</code> '''(TODO: Of gaan we helemaal hardcore met pull requests beginnen?)'''<br />
# alle webcie'ers krijgen nu een mailtje met de commits die je hebt gepleegd en zullen je feliciteren en/of afkraken op je programmeerstijl<br />
<br />
Nu is werken in je eentje heel leuk, maar samenwerken geeft een veel mooier feestje! Daarom is het aan te raden dat je om de zoveel tijd commits van anderen opvraagt en met ze deelt:<br />
<br />
# als iemand anders op je branch heeft gewerkt: doe <code>git pull</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
# als er dingen binnenkomen op develop: stop ze in je branch <code>git fetch</code>'en en dan <code>git merge origin/develop</code>. (Voor echte pro's is er ook <code>git rebase</code>, maar dat heeft meer problemen met samenwerken op de branch)<br />
# als je je vooruitgang wilt delen: doe <code>git push</code> (krijg je een error in de trant van "geen remote voor branch", doe dan <code>git branch --set-upstream-to origin/feature-$bla</code> om de remote in te stellen en probeer opnieuw)<br />
<br />
=== Fix een bug ===<br />
<br />
(Je kan dit proces ook op develop doen als de bug niet zo heel hoge prioriteit heeft. Doe dan gewoon wat hierboven staat.)<br />
<br />
Is er een bug die snel opgelost moet worden? Dan gaan we op basis van de livesite werken zodat we de fix apart kunnen houden van eventuele (halfbakken) features.<br />
<br />
# <code>git checkout master</code> en <code>git pull</code> om up to date te zijn<br />
# maak een nieuwe branch met <code>git checkout -b bug-$bla</code><br />
# doe precies hetzelfde programmeer-commitriedeltje als hiervoor beschreven<br />
# als je in een commit een regel "Closes: #$bugnummer" zet, wordt de bug automatisch op gesloten gezet in Bugweb.<br />
# ben je klaar: stop je fix in master met <code>git checkout master</code> en dan <code>git merge bug-$bla</code> en maak het openbaar met <code>git push</code><br />
# zorg ervoor dat develop up-to-date blijft: <code>git checkout develop</code> en dan <code>git merge master</code> en maak het openbaar met <code>git push</code><br />
<br />
=== Shit's on fire yo ===<br />
<br />
Heb je er een potje van gemaakt, en wil je terug naar de laatste commit? Als je een enkel bestand wil terugzetten, heb je <code>git checkout $bestand</code>; alles wat je in het bestand hebt gedaan sinds de laatste commit wordt dan teruggezet zoals het was. De makkelijkste manier om echt helemaal alles weg te gooien is met <code>git reset --hard HEAD</code>; elk bestand dat je hebt veranderd t.o.v. je laatste commit wordt dan teruggezet zoals het was. Dit kan dus ook nuttige wijzigingen weggooien!<br />
<br />
Heb je er een nog erger potje van gemaakt, en heb je een foute commit gemaakt? Als dit de laatste commit(s) was (waren) op je branch en je hebt ze nog niet gepusht, dan heb je <code>git reset HEAD~1</code> om de laatste commit weg te gooien (en <code>HEAD~</code>''n'' om ''n'' commits tegelijk ongedaan te maken.) Heb je ze al wel gepusht, dan moet je naar de aanpak hieronder overgaan.<br />
<br />
Heeft iemand anders een enorm potje gemaakt, en wil je de commit ongedaan maken? Doe dan <code>git revert $commit</code>. Dat maakt een nieuwe commit waarin precies het tegenovergestelde gebeurt van die wijzigingen. De originele commit blijft nog wel in de geschiedenis staan! Als iemand dus geheime data heeft gecommit, moet je toch echt [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History geavanceerde tools gebruiken].<br />
<br />
== Om iets live te zetten ==<br />
<br />
Ten eerste: denk goed na of je dit echt wel wilt doen. Er kunnen nog wel eens gebruikers gaan klagen.<br />
<br />
Doe gewoon een <code>git push</code> naar master op je eigen bakkie. Typ lekker <code>./zetLive.sh</code> in de /scripts map en gaan met die banaan.<br />
<br />
== Migreren van SVN naar Git ==<br />
<br />
Is jouw debug van voor de overstap? Dan is het niet heel lastig om te switchen!<br />
<br />
=== Verhuizen van git-svn ===<br />
Gebruik je al Git-SVN, dan kun je als volgt switchen:<br />
# <code>cd wwwdebug</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git branch -t origin/develop</code><br />
<br />
Nu '''moet''' je handmatig commits van je huidige branches op develop rebasen, want anders gaat de hele geschiedenis stuk. Check dat de 3e commit vanaf het begin begint met <code>9cf65047</code> ipv <code>cc9c5bb</code>. Zo niet, ga je allemaal antieke ledendata meepushen (die ik met pijn en moeite heb weggefilterd) en gaat de Autoriteit Persoonsgegevens je slaan.<br />
<br />
=== Verhuizen zonder git-svn ===<br />
Heb je wel een wwwdebug maar nog geen git? Dan moet je iets meer moeite doen om je laatste versie te bewaren:<br />
# <code>cd wwwdebug</code><br />
# <code>svn up</code><br />
# <code>svn log</code> Kijk hier wat de laatste revisie is!<br />
# <code>git init</code><br />
# <code>git remote add origin ssh://vm-www/srv/git</code><br />
# <code>git fetch</code><br />
# <code>git commit --allow-empty -m "Initial empty commit"</code> (want git snapt het niet als je geen commit hebt gedaan en wel branches wil beginnen, dan maar zo)<br />
# <code>git log origin/master</code> Kijk hier welke git-commit overeenkomt met de laatste svn-revisie.<br />
# <code>git reset --mixed $laatste_revisie_commit</code><br />
# <code>git stash</code><br />
# <code>git checkout -t origin/develop</code><br />
# <code>git stash apply</code><br />
<br />
=== Vertaalsleutel svn -> git ===<br />
<br />
Het belangrijkste verschil is dat git heel veel verschillende commitgeschiedenissen heeft en svn maar eentje. Bij elk commando vraagt svn bijvoorbeeld aan de server of er nog commits bijgekomen zijn. Git doet dat alleen als je erom vraagt met <code>git fetch</code>. Het is daarom een goed idee om als svn'er voor elk commando <code>git fetch</code> te runnen totdat je doorhebt wanneer het echt nuttig is.<br />
<br />
* <code>svn up</code> -> <code>git pull</code> (vraag aan de remotes welke veranderingen er zijn, merge die automatisch)<br />
* <code>svn st</code> -> <code>git status</code> (vraag de huidige status op van jouw lokale kopie ten opzichte van jouw laatste commit)<br />
* <code>svn diff</code> -> <code>git diff</code> (bekijk alle wijzigingen die er zijn tussen jouw lokale kopie en jouw laatste commit)<br />
* <code>svn ci</code> -> <code>git commit -a</code> (stop al je wijzigingen in een nieuwe commit, die je zou kunnen opsturen naar de andere WebCie'ers)<br />
<br />
== Een nieuwe git-repo opzetten ==<br />
<br />
Als je code die niet bij de livesite hoort wilt delen met de WebCie, kan dit via een aparte git-repo. Op deze manier maak je een nieuwe repo:<br />
<br />
* <code>ssh vm-www</code><br />
* <code>cd /srv</code><br />
* <code>sudo mkdir git-$bla-repo</code><br />
* <code>sudo chown webcie:webcie /srv/git-$bla-repo</code><br />
* <code>sudo chmod o= /srv/git-$bla-repo</code><br />
* <code>sudo chmod ug=rwx /srv/git-$bla-repo</code><br />
* <code>sudo chmod g+s /srv/git-$bla-repo</code><br />
* <code>cd /srv/git-$bla-repo</code><br />
* <code>git init --bare --shared</code><br />
<br />
Nu kun je als het goed is een <code>git clone ssh://vm-www/srv/git-$bla-repo</code> doen!<br />
<br />
== Migreren tussen Git-repo's ==<br />
<br />
Als de repository ergens anders gehost gaat worden, wil je natuurlijk dat alle huidige code daar terechtkomt.<br />
<br />
Stel dat er al een repository is aangemaakt voor de code (e.g. zoals hierboven beschreven), met bijv. de URL <code>git.example.com</code>.<br />
<br />
Elke WebCie'r moet dan doen:<br />
<br />
* <code>git remote add new-origin $REMOTEURL</code><br />
<br />
De volgende 2 commands hoeven maar één keer, door één persoon gedaan te worden:<br />
<br />
* <code>git fetch --all origin</code><br />
* <code>git push new-origin refs/remotes/origin/*:refs/heads/*</code> ([https://stackoverflow.com/questions/23947419/how-can-i-pull-every-branch-from-origin-remote-and-push-to-our-backup-remote Aldus sprak StackOverflow])<br />
<br />
En dit weer door iedereen:<br />
<br />
* <code>git remote set-url origin $REMOTE_URL</code><br />
* <code>git remote remove new-origin</code><br />
<br />
<!-- Info van voor de overstap naar git, weet niet of we dit nog willen hebben.<br />
<br />
Als je liever <code>git</code>'t dan <code>svn</code>'t (en je hebt zin om te leren hoe dat samengaat), dan kun je gebruik maken van <code>git-svn</code>. Lees van te voren ook even de online documentatie hiervan, want het loopt allemaal net wat anders dan svn werkt of git zonder svn werkt.<br />
<br />
== Je eerste checkout ==<br />
<br />
Het handigste is als je een schone checkout maakt van de code, want dan heb je gittroep niet tussen svntroep. Het uitchecken duurt best lang, dus start eerst een <code>screen</code>sessie op! Dan kun je binnen die screensessie <code>git svn checkout</code> doen op de huidige svn-repo (zie [[WebCie SVN]] voor de url). Na heel wat gecheckout waarbij een stuk of tienduizend commits worden binnengehaald, heb je een gitrepository waar je gewoon lokale branches hebt en alles!<br />
<br />
== Handige aliassen ==<br />
<br />
Je kan in git aliassen instellen om de volgende commando's af te korten. Ze doen ongeveer wat svn doet bij de corresponderende afkortingen, en vooral dat je dingen wat makkelijker met svn kan koppelen. Je mag natuurlijk ook gewoon alle git-svn-commando's uit je hoofd gaan leren.<br />
<br />
* ''git ci'': <code>git stash && git svn dcommit && git stash apply</code> (zet de commits in je lokale branch om in commits op de svn-server)<br />
* ''git up'': <code>git stash && git svn rebase && git stash apply</code> (haal alle nieuwe veranderingen uit de svn op en zet het tussen je werk neer)<br />
<br />
--><br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Project_SOEPMESProject SOEPMES2017-10-30T20:42:43Z<p>Daanr: Ook een itempje over de Dia</p>
<hr />
<div>''Opdat de code niet versteent.''<br />
<br />
Project #SOEPMES# zou ervoor moeten zorgen dat alle code die we gebruiken ook gewoon fijn is, met makkelijk toe te voegen features.<br />
<br />
* Kies pagina's om te deprecaten.<br />
* Documenteer ook wat de domeininhoud is van een object ipv de codeinhoud.<br />
* Gebruik requestobjecten ipv stateful dingen echoen.<br />
* Form parsen moet beter kunnen.<br />
* Linten en formatten.<br />
* Iets als de Dia, maar don zonder vreselijke merge conflicts.<br />
<br />
[[Category:WebCie]]</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Webredactie_SVNWebredactie SVN2017-10-10T21:52:34Z<p>Daanr: Voeg {{Outdated}} toe. We gebruiken SVN niet/nauwelijks meer!</p>
<hr />
<div>{{Outdated}}<br />
<br />
SVN wordt door de PromoCie gebruikt om de strings op de website te vertalen, die niet in Publisher staan. Zie voor documentatie voor de WebCie de sectie [[#Voor_de_WebCie|Voor de WebCie]], voor de PromoCie zie [[#Voor_de_PromoCie|Voor de PromoCie]].<br />
<br />
== Voor de WebCie ==<br />
<br />
Om ervoor te zorgen dat de PromoCie tekst heeft om te vertalen doe je het volgende:<br />
<br />
*Ga naar www/gettext en voer het update bestand uit via <code>./update</code><br />
*De wijzigingen in voc/en_GB.po en voc/nl_NL.po kun je dan vervolgens committen<br />
<br />
Denk eraan dat je altijd tekst in je code beschikbaar maakt voor vertalen, bijvoorbeeld <code>_('Deze tekst moet vertaald worden')</code>. Deze strings moeten niet te triviaal worden, anders heeft de vertaler er niets aan. Als je zomaar <code>_('overig')</code> neerzet, dan weet de vertaler echt niet of het slaat op "remaining" (bijvoorbeeld als je dingen indeelt in groepjes) of het slaat op "other" (bijvoorbeeld als je omschrijvingen geeft aan dingen). Om dit euvel te verhelpen, kun je hints neerzetten in de vertaalbare strings, die betekenissen moeten verduidelijken en ontwarren. Dan kun je bijvoorbeeld <code>_('[VOC: niet in voorgaande lijstjes]overig')</code> of juist <code>_('[VOC: functie commissielid]overig')</code> neerzetten. Op zo'n zelfde manier kun je stringinterpolaties verduidelijken: in plaats van <code>_("Deze persoon %s!")</code> schrijf je dan <code>_("Deze persoon %s[VOC: redenen dat persoon niet verwijderd mag worden]!")</code>.<br />
<br />
Het update-script zorgt er meteen voor dat de hints worden weggefilterd, dus er is geen enkele reden om het niet te doen!<br />
<br />
== Voor de PromoCie ==<br />
<br />
SVN (Subversion) is een programma dat zorgt voor het versiebeheer van de vertaalbare strings. Ook houdt het (vaak) automatisch rekening met het mergen van verschillende versies en kan je makkelijk een oude versie terugzetten. Voor de onderstaande commando's heb je een terminal nodig.<br />
<br />
=== SVN Checkout ===<br />
<br />
Als je nog nooit strings hebt vertaald moet je eerst een SVN checkout doen via <code>svn checkout [https://www.a-eskwadraat.nl/svn/webredactie/ https://www.a-eskwadraat.nl/svn/webredactie/] webredactie</code><br />
<br />
=== SVN Update ===<br />
<br />
Om je bestand up to date te maken gebruik je <code>svn up</code><br />
<br />
Hierna kan je werken aan het bestand met behulp van het programma GTranslator via <code>gtranslator en_GB.po &</code><br />
<br />
=== SVN Commit ===<br />
<br />
Als je een wijziging hebt gedaan aan de vertaalbare strings (en hebt opgeslagen) moet je dit committen, zodat andere PromoCieleden er ook iets mee kunnen doen en zodat het op de website komt.<br />
<br />
Dit doe je via: <code>svn ci en_GB.po</code><br />
<br />
Zorg wel dat je in de terminal eerst naar de juiste map gaat waar het bestand in staat.<br />
<br />
Het kan zijn dat SVN zeurt dat je geen EDITOR hebt ingesteld. In dat geval kan je in je .bashrc bestand de volgende regel toevoegen: <code>export EDITOR=nano</code> of je geeft meteen een log message mee via <code>svn ci -m "blabla" en_GB.po</code><br />
<br />
=== SVN Difference ===<br />
<br />
Om het verschil te zien tussen het vertaalbestand dat online staat en jouw bestand moet je svn diff gebruiken: <code>svn diff en_GB.po</code><br />
<br />
=== SVN Status ===<br />
<br />
Om te kijken welke bestanden gewijzigd zijn kan je SVN status gebruiken via <code>svn st</code><br />
<br />
Als het goed is is alleen en_GB.po gewijzigd.<br />
<br />
=== Overig ===<br />
<br />
*Als je je bestand wilt terugzetten naar de versie die op de server staat gebruik je: <code>svn revert en_GB.po</code><br />
*Als je een conflict krijgt betekent dat dat je versie botst met die van een andere webredacteur. Je kan dan het conflict bekijken via <code>df</code> en vervolgens jouw versie accepteren (<code>mc</code>) of de andere versie (<code>tc</code>).<br />
[[Category:WebCie]] [[Category:Webredactie]]<br />
<br />
== Waarom bestaat nl_NL.po? ==<br />
<br />
Uit een mailtje overgenomen:<br />
<br />
Het is natuurlijk voor de vertalingen heel lastig als een vertaalbare string meerdere Engelse vertalingen heeft, of dat je geen idee hebt waar alle %s'jes en %d'tjes voor staan. Om jullie een beetje te ondersteunen, gaan we de Nederlandse strings niet direct uit de code halen, maar net als het Engels "vertalen" uit de strings die al in de code staan. Dit komt neer op een tweede bestand, nl_NL.po, die in principe niets interessants bevat. Alleen als we een vertaalbare string tegenkomen die voor verwarring zorgt, kunnen we er een opmerking aan toevoegen (zodat "overig" wordt van de vorm "[VOC: functie commissielid]overig", of "Deze persoon %s!" wordt "Deze persoon %s[VOC: redenen dat persoon niet verwijderd mag worden]!").<br />
<br />
Een ander voordeel is dat je in de nl_NL.po heel snel, zonder de code te hoeven aanpassen, spellingsfouten in de Nederlandse website kan oplossen. Bovendien zijn alle lijntjes heel makkelijk halfkast te maken, zonder dat PHP zich zorgen hoeft te maken over vage Unicodetekens.<br />
<br />
Het update-script gaat al die [VOC]-opmerkingen automatisch wegfilteren dus de nl_NL.po hoeft geen extra werk te kosten, en in de en_GB.po kunnen jullie vertalen zoals gewoonlijk, met extra hints. (Ze worden ook in en_GB.po weggefilterd, zodat de eindgebruiker ze nooit te zien krijgt!) Het fijne aan deze aanpak is dat jullie niets extra's hoeven te doen als jullie de huidige situatie met alleen de en_GB.po voldoende vinden, maar als iets goed is, kan het altijd beter, toch?</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Website-Ipa-integratieWebsite-Ipa-integratie2017-10-09T21:10:09Z<p>Daanr: Grammatica, Pepijn!</p>
<hr />
<div>[[Category:WebCie]]<br />
[[Category:Sysop]]<br />
<br />
Op dit moment wordt er gewerkt aan een website-ipa-integratie. Dat houdt in dat als commissieleden op de website in een commissie gestopt worden, het automatisch ook op het systeem gebeurt.<br />
<br />
Om dit allemaal mogelijk te maken moeten er een aantal dingen geregeld zijn:<br />
<br />
Alle scripts die gebruikt worden (op dit moment changecieforward, changeciesymlink, createciehomedir en makemensjehomedir) moeten in /usr/local/bin op de vm-www en vm-www-debug staan en de selinux-permissies moeten goed staan! Ook moeten op beide machines dezelfde skel-directory staan als op de workstations. In IPA moet geregeld worden dat apache deze commando's mag uitvoeren met sudo (als cies of mensje of wat van toepassing is). Verder moet er een gebruiker website-ipa zijn in ipa die de juiste rechten heeft om de juiste handelingen te doen. Van deze gebruiker wordt er een keytab-file opgeslagen op de vm-www en vm-www-debug die gebruikt wordt om de juiste ipa-commands uit te voeren. Verder is het ook belangrijk dat in /etc/sudoers (editten met visudo) de regel<br />
Defaults:apache !requiretty<br />
komt te staan.<br />
<br />
Omdat veel IPA-scripts relative lange tijd kosten om te draaien worden op de website bij de pagina's die nieuwe accounts aanmaken (zowel cies als mensjes) de verschillende onderdelen met ajax aangeroepen. Hierdoor kan het zijn dat een van de scriptjes het niet doet wat problemen oplevert. Alle foutmeldingen moeten wel goed afgevangen worden om de 'normale' bestuursleden enig inzage te geven in wat er mis gaat.</div>Daanrhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/Website_stuk_wat_nuWebsite stuk wat nu2017-10-09T21:08:55Z<p>Daanr: Oeps, begin een beetje moe te worden...</p>
<hr />
<div>==Debug is wit scherm na pullen==<br />
<br />
Probeer eens <code>manage update</code> te doen om alle dependencies weer in het gareel te krijgen.<br />
<br />
==503 service unavailable==<br />
<br />
Krijg je een error als:<br />
<pre><br />
Service Temporarily Unavailable<br />
<br />
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.<br />
Apache/2.2.15 (CentOS) Server at comint-debug.a-eskwadraat.nl Port 80<br />
</pre><br />
Check dan of de server en/of PHP wel draaien:<br />
<code><br />
sudo service httpd status<br />
sudo service php-fpm status<br />
</code><br />
en zo nee, start ze:<br />
<code><br />
sudo service httpd start<br />
sudo service php-fpm start<br />
</code><br />
<br />
== Andere errors ==<br />
<br />
Heb je al geprobeerd te herstarten? Weet je zeker dat de stekker erin zit?<br />
<br />
[[Category:WebCie]]<br />
[[Category:HowTo]]</div>Daanr