Versionshantering till nytta och nöje

Inget utvecklingsprojekt borde vara utan ett system för versionskontroll, inte ens om man är den enda som jobbar på sitt projekt. Och när man är många som jobbar med samma projekt så är det idag nästan omöjligt att göra det på ett vettigt sätt utan att stöda sig på någon form versionering.

Vad får man då för besväret av att vara tvungen att börja bokföra vad och hur man lägger in kod i sitt projekt? Jo, inte minst en möjlighet till att gå tillbaka och ångra saker som gått sönder eller som någon av misstag skrivit över. Eftersom varje ändring i varje fil sparas så kan man enkelt gå tillbaka i filens historia och kolla vad som ändrat, när något ändrat och vem som gått och ändrat. Och när det uppenbarar sig nya och oväntade buggar i sajten så är det en lättare att felsöka den genom att kolla upp vilka ändringar som gjorts i historiken.

När vi började med projektet i oktober så stod valet mellan Subversion, som vi alla kände från förr och det nyare och modernare Git som för de flesta av oss var ett system vi kände till, men som knappt någon av oss hade använt från tidigare. Git har ändå så pass många fördelar framom Subversion att vi valde att använda det. Den främsta fördelen som Git har är att det är ett decentraliserat system, dvs att man inte är lika beroende av en central server för alla versionerna, utan hela projektets alla filers alla versioner finns hela tiden tillgängligt också på din egna hårddisk, och på en centralt ställe som alla i teamet har tillgång till, det som i git kallas origin-repositoriet. Den andra stora fördelen med Git är att det är enklare att jobba på flera utvecklingsspår (såkallade branches) samtidigt.

En liten del av projektets git-logg.

Fram tills vi publicerade den slutna betan så klarade vi oss ändå bra med en huvudsaklig master-branch som vi alla sparade våra ändringar till. Nu, i och med att vi har en sajt som i det närmaste kan räknas att vara i produktion så behöver ändå lite mer kontroll över vad som läggs ut på produktionsservern. För att göra det lättare att ha koll på just det så använder vi nu två huvudsakliga branchar; master-branchen och dev-branchen. Nu sker alltså det huvusakliga utvecklingsarbetet i dev-branchen och endast färdiga och testade helheter ska sparas in i master-branchen. På det sättet så försöker vi minimera att det smyger in fel som kan ta ner sajten eller orsakar annan otrivsel för redaktörer och besökare.

Det är ändå inte helt problemfritt att jobba med många branches, framförallt blir det väldigt viktigt att se till att man är i den rätta branchen då man hämtar in och sparar ny kod, de första dagarna med flera branches gick åt att lära sig att hålla reda på var man var, och vart man höll på att spara sitt material, men redan nu känns det naturligt och enkelt att jobba med flera utvecklingsspår.

En historik som sträcker sig tillbaka till projektets början ger också fina möjligheter att visualisera hur projektet vuxit sig fram från starten i oktober fram tills idag: