Gratis revisionshanterare för Linux?

@Sweedland: Jag är osäker på om det är ett komplett revisionshanteringssystem eller bara en grafisk klient du är ute efter.

Men precis som de andra inläggen i tråden säger så är det git som gäller nu för tiden. Git skapades av Linus Torvalds (som också skapat Linux). Nu för tiden är det standard även vid utveckling på Microsoft-plattformen.

Microsoft äger/håller på att köpa upp GitHub, som är ett gratis ställe att ha sin kod på ifall man vill ha ett öppet repository (vem som helst kan ladda ner den). Om man vill ha koden för sig själv så kan Microsofts Azure DevOps (fd Visual Studio Team Foundation Services) vara ett bra alternativ. Där kan man vara upp till 5 utvecklare som har tillgång till koden gratis, ifall de inte ändrat villkoren nyligen. Git har egentligen inget centralt repository, men alternativen ovan är bra om man ändå vill använda det så.

Det finns ett otal grafiska verktyg till git.

Ja, git är det du ska satsa på, helt enkelt för att det är det alla andra kan och för att det är cross-platform.

Visual SourceSafe är ju ökänt för att råka ut för bitröta, så det är en bra ide att försöka fasa ut det.

Men visst, det är inte superlätt att börja jobba med git som nybörjare. Om man kör Visual Studio så får man ett grafiskt gränssnitt som är OK. Men som vanligt är det bäst att (även) lära sig kommandorad, så man har koll på vad som händer under skalet om man använder GUI.

Utanför Visual Studio så har jag inte använt GUI till git, så jag kan tyvärr inte ge dig något tips baserat på egen erfarenhet. Google hittar dock ett gäng som är cross-platform, både fria och gratis icke-fria. Om man använder GitHub eller Azure DevOps så får man ju även lite hjälp av webbgränssnitten för att surfa i sitt (remote) repository.

Att komma igång och leka med ett lokalt repository är ju bara en apt-get install bort, så det tycker jag definitivt du ska göra.

Git är absolut något man bör kunna som utvecklare. Även om du väljer att köra något annat skulle jag rekommendera dig att försöka lära dig grunderna i git åtminstone då du garanterat kommer stöta på det någon gång.

@Sweedland: Om du bara är intresserad av att checka in allting så kan du köra git commit -a så läggs alla ändrade filer automatiskt till i staging och tas med i committen (nya filer måste man dock fortfarande lägga till med git add).

Men det är inte alltid man har det arbetssättet, ibland vill man kunna göra en commit med bara vissa filer, eller t.o.m. bara vissa delar av filer. Med staging behöver man inte välja allt som ska vara med i en commit på en gång, man kan bygga upp en commit stegvis och se precis vad som kommit vara med i committen och vad som inte kommer vara med. Men det fina med git är som sagt att du kan ignorera det om du vill och bara göra en commit med alla ändringar direkt.

@Sweedland: Jo, det normala förfarandet är att man gör en commit efter varje ändring man gjort, och beskriver vad man gjort i meddelandet. D.v.s. vanligtvis gör man en commit för att man gjort klart något som man vill lägga till i projektet, inte för att man ska börja på något nytt och vill ha en backup ifall något går fel. Sen är det oftast samma sak i verkligheten, d.v.s. man börjar ofta på något nytt när man är klar med föregående uppgift, men synsättet är annorlunda.
Lite svårt att veta vad som gått fel utan mer info, men det är inte så att filen heter Makefile och git gör skillnad på små och stora bokstäver? I Linux är det ju definitivt så, i Windows vet jag inte riktigt hur det fungerar.

I många fall vill man committa alla ändringarna samtidigt, men ibland inser man att man behövde göra ytterligare orelaterade ändringar. Det kan handla om att man uppdaterade versionen av något beroende exempelvis. Det har ju inget med din nya funktionalitet att göra förmodligen så då kan du enkelt committa de ändringarna först. Det kan också låta dig skapa en mer logisk uppdelning mellan dina ändringar av andra anledningar också.

Din metodik med backup-incheckingar resulterar nog inte i en särkilt ren historik. I git arbetar du ju på din lokala kopia så därmed kan du om du helt lyckas förstöra ditt lokala kodträd möjlighet att bara slänga bort det helt och klona ner allt från ditt upstream-repository igen (förutsatt att du har ett sådant, vilket man normalt sätter upp). Du kan också göra dina ändringar på en ny branch och sedan merge:a in dessa i huvud-branchen (master) när du är klar.

I en bra commit-historik checkar du som sagt in logiska/funktionella ändringar du gör, det är inte bara tänkt som en slags backup-lösning. Koden du har i ditt upstream repo är normalt alltid funktionell eftersom du bara pushar dit när saker fungerar. När du bara vill spara undan icke-fungerande version har git en stash-funktion för detta ändamål.

Mitt flöde är normalt följande:

1. git pull (behövs ej om du redan vet att du har senaste koden)
2. Gör dina ändringar.
3. git status
4. Någon form av git add (beroende på om jag vill committa alla eller bara vissa filer).
5. git commit (eller git commit -m "Mitt fina commit-meddelande" om man bara vill skriva något kort)
6. Om jag är klar eller det känns logiskt att pusha upp mina ändringar till upstream kör jag git push.

Felet du fick hade avhjälpts av att köra git status eftersom du då fått se vilken path den förväntade sig att du angav.

I fallet "git add makefile" finns det ingen wildcard att evaluera dock. Med andra ord säger du åt den att lägga till filen som heter "makefile". Någon sådan fil fanns inte i aktuell katalog och därmed fick du ett fel.

Kan förresten vara bra att veta att du kan använda tab completion i git add.