Gratis revisionshanterare för Linux?

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Gratis revisionshanterare för Linux?

Har provat och installerat Rabbit-paketet i min Mint 19. Svårt med menyerna. Har provat det mest. Sen läser jag nåt om att Rabbitvcs inte blivit uppdaterat på 4 år(!).
Kollar på Bazaar. Den falerar och installera. Då tänkte jag att jag hör med de på Sweclockers. Har ni nåt råd att ge mig?
Är bra om det finns en windows-version också då jag har det på jobbet.

Trädvy Permalänk
Medlem
Registrerad
Okt 2001

Git?

Skickades från m.sweclockers.com

Trädvy Permalänk
Festpilot, Geeks Gaming
David Kvist
Plats
Göteborg
Registrerad
Jun 2012

Säger nog även jag "Git?"

Synpunkter på min moderering? Kontakt:
| PM:a mig | Maila mig | PM:a Moderatorerna | Kontaktformuläret |
Testpilot, Skribent, Moderator & Geeks Gaming Huvudadmin
| Geeks Officiella Discord-server |
Forumregler

Trädvy Permalänk
Medlem
Registrerad
Dec 2015

@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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av KAD:

@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.

Jag är primärt ute efter ett grafiskt gränssnitt (av ren lathet) och med databasen liggande lokalt eller på LAN:et. Git är ju välkänt men bävar lite för det. Varför vet jag inte. Använder nu en väldigt enkel VSS (Microsofts Visual Sourcesafe) och den har de funktioner jag behöver. Dock är det inte underhåll på VSS längre så jag vill fasa ut den.
Sen jobbar jag i både Linuxmiljö och Windows så det vore bra med nåt som är för bägge världarna. Kanske Git är det jag ska satsa på ändå? Ska jag göra det och börja använda det i yrket senare vill jag nog ha en "sandlåda" först och öva på.
Tar tacksamt emot kommentarer.

Trädvy Permalänk
Medlem
Registrerad
Dec 2015

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.

Trädvy Permalänk
Medlem
Registrerad
Jul 2012

Jag säger som tidigare talare, lär dig git och kör git, det kommer du tjäna på i längden då det nu är standard.

Vill du inte lägga upp din kod publikt kan du sätta upp en gitlab-server, helt gratis och i mitt tycke bättre än github. Kör själv gitlab på jobbet av just den anledningen.

Skickades från m.sweclockers.com

Trädvy Permalänk
Hedersmedlem
Plats
Linköping
Registrerad
Okt 2006

Det finns ju även gitk och git gui att använda med git för att underlätta grafiskt.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av KAD:

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.

Ok. Det jag använder är Atmel Studio som baseras på Visual. Jag använder också IAR:s workbench SAMT även vanliga editorer. Beror lite på vad jag jobbar med.
För min del så räcker CheckIn/CheckOut och diff. Inge mer än det i nuläget.

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007

@Sweedland: Det finns en gratis bok på Gits hemsida, Pro Git, som du kan kolla in. Det finns kortare guider, men jag tycker boken är bra eftersom den går igenom grunderna ordentligt med många bra exempel. Och det räcker med ungefär halva kapitel 2 för att ha koll på grunderna.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Dec 2003

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.

Antec P280 | Corsair RM750x | ASUS ROG Strix X370-F Gaming | Ryzen 7 1800X | G.Skill Trident Z RGB 3200MHz CL14 2x16GB | ASUS GTX 1080 Ti Strix Gaming OC | Samsung 970 Pro 1TB | Samsung 850 Pro 1TB | Samsung 840 Pro 256GB | Sound Blaster Z | QNIX QX2710

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Jag ska plöja boken. Tack för tipset. Dags att få Git under lampan. Det har varit sånt intensivt år med nya programspråk och sånt för mig så varför inte ta Git före nyår?

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av blunden:

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.

Jag läser just nu om Git och det som särskiljer sig (just nu iaf) är Staging area.Var i ligger nyttan i att markera upp filer så de hamnar i Stage-arean som sen ska committas in i repot? I min värld checkar man in hela projektet/katalogen.
Om jag får reda på vitsen med Stage så greppar jag metodiken.

Trädvy Permalänk
Medlem
Registrerad
Nov 2018
Skrivet av Sweedland:

Jag läser just nu om Git och det som särskiljer sig (just nu iaf) är Staging area.Var i ligger nyttan i att markera upp filer så de hamnar i Stage-arean som sen ska committas in i repot? I min värld checkar man in hela projektet/katalogen.
Om jag får reda på vitsen med Stage så greppar jag metodiken.

Du kan ha editerat fler filer. Ändringar i fil 1 o h 2 kanske inte rör samma sak som ändringen i fil 3
Då kan du dela upp i flera (2) commits genom att först add:a fil 1 och 2, commita (med commit meddelande). Sen add;a fil 3 och commita med annat passande medelande

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007

@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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av perost:

@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.

Jag kan säkert se fördelar med detta "stage-läge". När jag gör större modifieringar i kod så checkar jag in allt (i VSS) före varje större ändring. Kallar den incheckningen för typ "backup [datum-tid]" och sen skriver jag en "commit-kommentar" om vad som skett och vad som ska ske.
Jag kan nog, när jag blivit varm i kläderna, ta till mig denna finess även om jag kan se enkelheten i att "committa" in allt.

hmm....jag kan inte adda "git add makefile"

Sen måste jag säga att jag gillar git via CLI. Inga problem än så länge. Jag ska dock låta bli o brancha på ett tag.

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007

@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.

Skrivet av Sweedland:

hmm....jag kan inte adda "git add makefile"

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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av perost:

@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.

Det känns bra och checka in en lyckad version innan man ger sig på nästa större grej. Tur jag är själv än så länge på versionshanteraren.

git säger: fatal: sökvägsangivelsen "makefile" motsvarade inte några filer
edit: Det gick bra när jag gick ner till den katalog som makefile låg i. Jag har flera kataloger med makefile:s. (Jag kör på Linux)

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Sweedland:

Jag kan säkert se fördelar med detta "stage-läge". När jag gör större modifieringar i kod så checkar jag in allt (i VSS) före varje större ändring. Kallar den incheckningen för typ "backup [datum-tid]" och sen skriver jag en "commit-kommentar" om vad som skett och vad som ska ske.
Jag kan nog, när jag blivit varm i kläderna, ta till mig denna finess även om jag kan se enkelheten i att "committa" in allt.

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.

Skrivet av Sweedland:

Det känns bra och checka in en lyckad version innan man ger sig på nästa större grej. Tur jag är själv än så länge på versionshanteraren.

git säger: fatal: sökvägsangivelsen "makefile" motsvarade inte några filer
edit: Det gick bra när jag gick ner till den katalog som makefile låg i. Jag har flera kataloger med makefile:s. (Jag kör på Linux)

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.

Antec P280 | Corsair RM750x | ASUS ROG Strix X370-F Gaming | Ryzen 7 1800X | G.Skill Trident Z RGB 3200MHz CL14 2x16GB | ASUS GTX 1080 Ti Strix Gaming OC | Samsung 970 Pro 1TB | Samsung 850 Pro 1TB | Samsung 840 Pro 256GB | Sound Blaster Z | QNIX QX2710

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av blunden:

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.

Ok. Jag tar till mig vad du säger. Jag kände inte till "stash". Angående makefile och path. Den tycks ju ta "*.c" galant ner i alla kataloger men inte "makefile".

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Sweedland:

Ok. Jag tar till mig vad du säger. Jag kände inte till "stash". Angående makefile och path. Den tycks ju ta "*.c" galant ner i alla kataloger men inte "makefile".

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.

Antec P280 | Corsair RM750x | ASUS ROG Strix X370-F Gaming | Ryzen 7 1800X | G.Skill Trident Z RGB 3200MHz CL14 2x16GB | ASUS GTX 1080 Ti Strix Gaming OC | Samsung 970 Pro 1TB | Samsung 850 Pro 1TB | Samsung 840 Pro 256GB | Sound Blaster Z | QNIX QX2710

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av blunden:

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.

Jag inser det. *.c säger till git att "leta efter c-filer" medan en naken makefile pekar på aktuell katalog man står i.

Jag fixade ett wildcard. git status */makefile. HA HA. Det fixade det hela.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Sweedland:

Jag inser det. *.c säger till git att "leta efter c-filer" medan en naken makefile pekar på aktuell katalog man står i.

Jag fixade ett wildcard. git status */makefile. HA HA. Det fixade det hela.

Snabbt och lätt.

Antec P280 | Corsair RM750x | ASUS ROG Strix X370-F Gaming | Ryzen 7 1800X | G.Skill Trident Z RGB 3200MHz CL14 2x16GB | ASUS GTX 1080 Ti Strix Gaming OC | Samsung 970 Pro 1TB | Samsung 850 Pro 1TB | Samsung 840 Pro 256GB | Sound Blaster Z | QNIX QX2710