Git vs. Perforce Helix – vad är skillnaden?

Det finns förstås många andra aktörer inom versionshantering, med verktyg som Microsoft Team Foundation Server, Subversion och Mercurial, som alla har sina anhängare. Git och Perforce Helix är dock två av de mest populära VCS-verktygen på marknaden, och på nätet diskuteras det flitigt vilket av de två systemen som är bäst.

Innan vi tittar på vad folk säger om de här två systemen börjar vi med lite bakgrund om de konkurrerande verktygen.

Perforce Helix

Vi börjar med det äldre av de två systemen. Perforce Helix lanserades första gången 1995, hette ursprungligen bara ”Perforce” och skapades av Perforce Software – ett företag grundat av Christopher Seiwald. Perforce har sitt säte i Minneapolis i USA och såldes till investeringsgruppen Summit Partners i februari 2016, då Janet Dryer utsågs till ny vd.

Än i dag är systemet fortfarande starkt, med versioner för en rad olika operativsystem, bland annat Windows, MacOS, Linux, Solaris och NetBSD.

Git

Till skillnad från Perforce är Git en kostnadsfri lösning med öppen källkod, skapad av Linux skapare Linus Torvalds. Torvalds behövde ett distribuerat versionshanteringssystem som kunde möta hans krav och skapade och lanserade därför Git 2005. Sedan dess har populariteten ökat kraftigt. Faktum är att Git har blivit världens klart mest populära VCS.

Nu när vi har presenterat våra två kombattanter ska vi titta närmare på dem och se vad folk säger om dem.

Obs! Clearvision (numera en del av Eficode) är förstås en förespråkare för Git, så ursäkta om vi är lite partiska. Som du snart kommer att se finns det dock många skäl till att vi gillar det så mycket.

Hastighet

Även när hastighet inte är den avgörande faktorn är det en viktig aspekt som de flesta organisationer vill ta hänsyn till när de väljer ett versionshanteringssystem.

Vi har sett att ett område där Git överträffar centraliserade VCS:er som Perforce är ren hastighet. Du kan ha hela projekthistoriken tillgänglig på några sekunder – en upplevelse som utvecklaren Aristotle Pagaltzis, som skriver på www.stackoverflow.com, kallar ”befriande”.

”Till och med att skapa en commit-logg för hela projekthistoriken, inklusive en fullständig diff för varje commit, kan göras på bråkdelar av en sekund”, säger han. I stora projekt kan du förstås märka av vissa prestandaförsämringar. Historiskt sett har Git haft problem med att hantera större filer.

I många fall har dock ”VCS:er som måste göra en tur och retur över nätverket helt enkelt ingen chans att konkurrera när det gäller hastighet, inte ens över en Gigabit Ethernet-länk.”

Konflikter

Automatisering är i regel en utmärkt tidsbesparare, men den innebär alltid en viss risk. Med Perforce har det rapporterats om tillfällen då arbete har förstörts av P4Merges auto-resolve. Det beror vanligtvis på hur verktyget används, inte på själva verktyget, men det innebär att team som använder Perforce behöver investera tid i utbildning och i att lära känna funktionen. All risk för förlorat arbete är dålig; i avgörande lägen kan den bli en katastrof om den inte hanteras korrekt.

Detta kan undvikas genom att göra merges manuellt i Perforce, på ungefär samma sätt som merges hanteras i Git. När Git signalerar en konflikt är det faktiskt en konflikt, och resten av tiden löser Git problemen korrekt och sparar mycket tid.

Hålla koll på merges

Om du är van vid att ha en branch som kontinuerligt tar emot merges från två andra brancher vet du kanske redan vilken huvudvärk det ibland kan innebära i Perforce. Med Git minimeras huvudvärken eftersom resultatet av en merge i Git faktiskt är en ny commit som känner till sina föregångare.

Stashing

Historiskt sett har detta varit möjligt i Git men inte i Perforce. Om din Perforce-server är version 2010.1 eller senare kan du nu använda kommandot p4 shelve för samma ändamål.

Skapa patchar

Det är enkelt att göra i Git, men i Perforce är det för närvarande omöjligt utan att använda kommandoraden, vilket kan vara en utmaning för den som inte är van vid hur kommandoraden fungerar.

Diskutrymme

”I Perforce är varje branch en kopia”, säger Carl på www.stackoverflow.com. ”Det betyder att om ditt källkodsträd är stort äts diskutrymmet snabbt upp. Och då räknar vi inte ens med det extra utrymme som behövs när du börjar bygga.”

”Med Git kan du ha 100 grenar, men bara en gren existerar åt gången. Om du specifikt vill arbeta med två versioner samtidigt kan du klona, göra ditt arbete och sedan ta bort en klon om du vill, utan att förlora något.”

Spåra ändringar vid refaktorisering

Carl förklarar återigen:

”Prova att dela upp BigClass i SmallClass1 och SmallClass2. För Perforce har BigClass nu upphört att existera och två nya klasser (SmallClass1 och SmallClass2) har lagts till i källkodsträdet. För Perforce finns det inget samband mellan BigClass, SmallClass1 och SmallClass2.”

Git har en stor fördel här eftersom det är ”smart nog att veta att x % av BigClass nu finns i SmallClass1 och y % av BigClass finns i SmallClass2 och att BigClass har upphört att existera … Ur perspektivet för någon som granskar ändringar mellan flera grenar är [Gits metod mer användbar], eftersom den mer korrekt återspeglar den faktiska ändringen i koden. Git kan göra detta eftersom det spårar innehållet i filen, inte själva filen.”

Centraliserat eller decentraliserat

En av de viktigaste skillnaderna mellan dessa två system är att Git bygger på en distribuerad, decentraliserad modell, medan Perforce är centraliserat. Båda har förstås sina fördelar, men med ett centraliserat system går det inte att decentralisera det i efterhand. Ett distribuerat VCS kan däremot centraliseras.

För vissa utvecklare är ett centraliserat system användbart. Programmeraren Bart Ruffle säger till exempel: ”Jag ser kommunikation som den viktigaste faktorn – att låta andra veta allt jag gör. Ett centraliserat VCS hjälper till med det.”

Det kan ligga något i detta, men det finns många sätt att kommunicera när man använder ett distribuerat system, och det är inte nödvändigtvis ett problem som andra utvecklare upplever. I kommentarsfältet till Barts blogginlägg ger faktiskt ”Alexander” ett annat perspektiv:

”Kommunikation. För det uppfanns ärendehanteringssystem. Men om du vill låta [andra] veta vad du gör – dela dina lokala repos.”

Ett företags preferens för decentraliserat eller centraliserat avgörs ofta av organisationens specifika krav, men det är ändå tydligt att Git erbjuder betydligt större flexibilitet på lång sikt.

Relaterat: Ladda ner Git 101 – en kostnadsfri guide till grunderna

Grenmappningar

Om du vill hantera grenar på rätt sätt i Perforce behöver du skapa en grenmappning. Det finns skäl till det, kopplade till hur Perforce ser på en gren. För en utvecklare eller ett team innebär det ett extra steg i arbetsflödet som du inte hade behövt med Git. Det är ofta ett litet steg, men för vissa team kan det göra stor skillnad, och det är värt att tänka på när du väljer mellan de två.

Dela arbete mellan team

Det är omöjligt att dela upp en inlämning i Perforce. Carl ger ett användbart exempel:

Tänk på det i termer av team A, B och C, säger han. ”Team A arbetar med funktion A. Team B med funktion B. Team C arbetar med buggfixar.

”Nu måste team A och B fixa en rad buggar för att kunna implementera sina funktioner. Problemet är att de inte var särskilt disciplinerade när de checkade in sina ändringar (troligen eftersom de jagar en deadline), så deras ”buggfixar” är delar av större inlämningar som, ur versionshanteringens perspektiv på deras grenar, även innehåller ny funktionalitet.

”Team C gör nu en patchrelease och vill få in buggfixarna från de andra teamen. Om de använde Git skulle team C kunna cherry-picka de relevanta ändringarna från de andra teamen, dela upp dem och bara ta det de behövde utan att behöva oroa sig för att införa delvis implementerade funktioner. Med Perforce kan team C få de berörda filerna, men måste separera de relevanta ändringarna genom en betydligt mer manuell process.”

Byta till fantastiska Source Control Engine X

”Om du bestämmer dig för att byta system för källkodshantering [till system X],” fortsätter Carl, ”kommer det att bli en mardröm att extrahera din versionshistorik från Perforce och flytta den till det nya system X, eftersom det är proprietärt och det bästa du kan göra är att gissa …. Med Git är det åtminstone öppen källkod, vilket eliminerar mycket av gissningsarbetet.”

Så … vem vinner?

Beslutet mellan Git och Perforce fattas förstås ofta från fall till fall av varje företag. Vi föredrar Git, men många team föredrar Perforce, särskilt inom spelbranschen.

Som tidigare nämnts är vi starka förespråkare för Git. För oss går Git segrande ur även en jämn jämförelse, men för att motverka eventuell partiskhet kommer här en snabb lista över fördelarna med Perforce, enligt Emil Sit, en mjukvaruutvecklare som skriver på Quora:

”Perforce:

• anses ofta vara ett mer förnuftigt val för stora repos.

• har en write-through-proxy.

• spårar integration per fil, inte per commit, vilket vissa team ser som en fördel.

• har bra stöd för Windows (särskilt klienter, men även radslut).

• har mycket flexibla (och partiella) checkouts (med anpassningsbara workspaces/klienter), medan Git gör detta mer komplicerat.

• kan automatiskt mata ut de flesta kommandoresultat i picklat Python-format (med flaggan -G) eller i ett format som kan tolkas av shell (med ”-z tag”).

• har integrerade mekanismer för åtkomstkontroll till delar av namnrymden (”p4 protect”), medan Git överlåter detta till hostingmiljön.

• kan mycket väl vara lättare att få gehör för i en företagsmiljö.”

Och du kan förstås välja att använda Perforce tillsammans med Git (det finns en app för det!).

Båda har sina fördelar. Många uppskattar Git för dess enkelhet och snabbhet, medan Perforce fungerar utmärkt för spelutvecklare och stora företag som Microsoft.

Vilken är din favorit? Berätta i kommentarerna.

Källor

Vill du ha mer information eller hjälp med att konfigurera något av dina Git-verktyg för just din utvecklingsmiljö kan Clearvision hjälpa till. Som Atlassian Platinum Solution Partner är våra konsulter experter på Atlassian, Git och allt inom Agile – kontakta oss med dina behov redan idag!