mboost-dp1
Subversion
dx (3) skrev:Hvor kan man læse hvordan det fungerer og hvordan man bruger det?
Her: http://svnbook.red-bean.com/en/1.5/index.html
#3 Google is your friend
Men derudover, så hvis du ikke allerede ved hvad versionsstyring drejer sig om, så er der gode chancer for, at det ikke er noget du skal bekymre dig om ;)
OT: Til dem der savner TortoiseSVN lidt, når de arbejder på deres *nix, så er RabbitVSC, lige udkommet i en release. (Det er tæt på en eksakt klon af Tortoise)
PT. findes der front ends til Nautilus og Thunar file managerene.
Jeg har brugt den i et par dage nu og jeg kan konstatere at den indtil nu har virket fejlfrit ;)
Endelig.
(Rabbit vil forøvrigt indbygge Git i næste version.)
Men derudover, så hvis du ikke allerede ved hvad versionsstyring drejer sig om, så er der gode chancer for, at det ikke er noget du skal bekymre dig om ;)
OT: Til dem der savner TortoiseSVN lidt, når de arbejder på deres *nix, så er RabbitVSC, lige udkommet i en release. (Det er tæt på en eksakt klon af Tortoise)
PT. findes der front ends til Nautilus og Thunar file managerene.
Jeg har brugt den i et par dage nu og jeg kan konstatere at den indtil nu har virket fejlfrit ;)
Endelig.
(Rabbit vil forøvrigt indbygge Git i næste version.)
dx (3) skrev:Hvor kan man læse hvordan det fungerer og hvordan man bruger det?
http://lmgtfy.com/?q=about+subversion
Use the
Flame off... :-)
Git er decentralt, SVN er centralt.wuziwug (2) skrev:Bliver dog spændende at se, om Git får dem væltet af pinden :)
Jeg kan ikke rigtig se hvordan Git skulle vælte SVN af pinden. Specielt med den ikke-eksisterende mængde udviklingsværktøjer der er til Git.
Derudover har både Microsoft og Google valgt at supportere Mercurial, og ikke Git. (Samt SVN og CVS). Det betyder også en del.
Windcape (7) skrev:Git er decentralt, SVN er centralt.
Det smukke med et decentralt system er, at man sagtens kan bruge det med en central server. Det gør de fleste formentlig. Omvendt er det dog umuligt at bruge SVN uden kontakt til serveren, hvilket er en væsentlig ulempe.
Windcape (7) skrev:Jeg kan ikke rigtig se hvordan Git skulle vælte SVN af pinden. Specielt med den ikke-eksisterende mængde udviklingsværktøjer der er til Git.
Der findes en masse værktøjer. Til Windows findes der TortoiseGit, gitk, Git Extensions (der også integrererer en smule i Visual Studio) og sikkert flere andre.
Nu er der i øvrigt også mange udviklere, der vurderer værktøjer på selve teknologien og ikke på, om der er en flot knap i Visual Studio. Intet kunne være mere ligegyldigt, hvis værktøjet er let at bruge.
Windcape (9) skrev:#8
Ikke for .NET
Det er mere typisk for sprog hvor udviklerne ikke bruger et IDE alligevel, og laver manuelle commits.
Hvad laver du? Automatiske commits? Det lyder smart.
Enten følger du ikke med i .NET-verdenen (heller, fristes man til at sige), eller også er du bare ikke opmærksom på, at der er andet end CodePlex.
Der er mange spændende .NET-projekter, der bruger Git. De er også typisk af højere kvalitet; formentlig fordi sådan er sammenhængen altid, når folk tager et aktivt valg i stedet for bare at gøre, som man typisk gør.
For at nævne et nogle .NET-projekter, der bruger Git (og GitHub):
* DotNetOpenAuth
* Fluent NHibernate
* FubuMVC
* .less
* MongoDB C#
* NHaml
* NInject
* Protocol Buffers
* RestSharp
* Rhino Mocks og mange andre ting af Oren Eini (Ayende Rahien)
* S#arp Architecture
* SubSonic
Må jeg ikke høre, hvad du helt præcist mener.Acro (12) skrev:Omvendt er det dog umuligt at bruge SVN uden kontakt til serveren
Jeg er klar over man ikke kan committe, men man har jo stadig adgang til sin lokale udgave af repositoriet.
Jeg spørger af ren nysgerrighed, da jeg synes git virker supersmart. Kan man feks committe sine opdateringer rundt til folk og hvilken konsekvens har det ift. at bruge en central server til git.
themuss (15) skrev:Må jeg ikke høre, hvad du helt præcist mener.
Jeg er klar over man ikke kan committe, men man har jo stadig adgang til sin lokale udgave af repositoriet.
Man har i begge tilfælde adgang til filerne, ja. Fordelen med fx Git er, at du har en fuld kopi lokalt, så du kan committe, selvom du måtte være offline. Nu hvor man næsten har internetadgang alle steder, er det ikke det, der primært sælger, men derimod hastigheden; operationer foregår nu engang hurtigere på filsystemet, end de gør via internettet...
Hvis man ikke oplever SVN som en flaskehals, bruger man efter min mening ikke versionskontrol korrekt. Et commit skal beskrive én ændring; ikke være en backup hver halve time (det findes der bedre værktøjer til). Et typisk commit skal derfor, synes jeg, ikke indeholde mere end fx en ny metode. Sådan kan man dog ikke rigtigt arbejde med SVN, fordi det simpelthen er for upraktisk pga. hastigheden.
themuss (15) skrev:Jeg spørger af ren nysgerrighed, da jeg synes git virker supersmart. Kan man feks committe sine opdateringer rundt til folk og hvilken konsekvens har det ift. at bruge en central server til git.
Termen central server er måske lidt forkert (jeg ved godt, jeg selv introducerede den). Lad os tage et eksempel. For Linux-projektet er der et sted, du henter koden fra. Det repository har i forhold til Git ingen særlig værdi i forhold til alle andre, men det har det organisatorisk, fordi det er den kilde, andre altid henter fra. Du kan sagtens vedligeholde dine egne ændringer direkte i din egen kopi, men hvis de ikke integreres med den officielle kode, er det kun dig selv (og dem du måtte dele med), der høster frugten.
Jeg mener stadigvæk at IDE integration af versions-styring er essencielt.Acro (12) skrev:Der findes en masse værktøjer. Til Windows findes der TortoiseGit, gitk, Git Extensions (der også integrererer en smule i Visual Studio) og sikkert flere andre.
Nu er der i øvrigt også mange udviklere, der vurderer værktøjer på selve teknologien og ikke på, om der er en flot knap i Visual Studio. Intet kunne være mere ligegyldigt, hvis værktøjet er let at bruge.
Jeg følger nok med til at vide at de projekter du nævnte brugte Git. Jeg ser det bare ikke som et relevant valg.Acro (14) skrev:Enten følger du ikke med i .NET-verdenen (heller, fristes man til at sige), eller også er du bare ikke opmærksom på, at der er andet end CodePlex.
CodePlex supportere også Mercurial nu. Hvorfor skulle man så bruge Git.
Forklar hvad du mener med hastigheden. Fordi helt ærligt, du klikker "commit", og så koder du videre mens der bliver lavet commits i baggrunden.Acro (16) skrev:Et typisk commit skal derfor, synes jeg, ikke indeholde mere end fx en ny metode. Sådan kan man dog ikke rigtigt arbejde med SVN, fordi det simpelthen er for upraktisk pga. hastigheden.
Hastigheden er sådan set irrelevant. Jeg synes at have et overblik over hvilke filer der er ændret og hvorfor de er ændret, og hvilke tickets/tasks de er relaterede til, er meget meget mere vigtigt end hastighed.
Og derfor er IDE integration vigtigere end hastighed.
Jeg skal ihvertfald ikke åbne en terminal for at kunne lave commits, jeg trykker på en knap, skriver hvilke ændringer jeg har lavet, og trykker OK.Acro (14) skrev:Hvad laver du? Automatiske commits? Det lyder smart.
Derefter arbejder jeg videre, og bekymre mig ikke videre om versionsstrying.
Jeg har stadigvæk ikke fattet jer som hellere vil skrive terminal kommandoer 24/7 , eller skrive macros til formålet (hvilket jo i sidste ende ville være smartere at have direkte i dit udviklingsmiljø).
Og det samme gælder unit tests forresten. Jeg ser heller ingen grund til ikke at bruge MS Test, medmindre du arbejder på noget i størrelsesordnen af et ERP system.
Glemte pointen:
Hvis Git folket laver et IDE plugin der er på niveau med AnkhSvn eller TFS til Visual Studio, skifter jeg gerne til Git i morgen.
Derudover undre det mig at der ikke er et (brugbart) Eclipse plugin til Git endnu (da Eclipse's SVN plugins er elendige, begge to).
Jeg undre mig virkelig over at hvis der er så mange udviklere som synes Git er fantastisk, at ingen af dem har integeret det ind i deres hverdags IDE.
Måske er det fordi at de kun bruger det til hobby projekter, og ikke på arbejde :o
Hvis Git folket laver et IDE plugin der er på niveau med AnkhSvn eller TFS til Visual Studio, skifter jeg gerne til Git i morgen.
Derudover undre det mig at der ikke er et (brugbart) Eclipse plugin til Git endnu (da Eclipse's SVN plugins er elendige, begge to).
Jeg undre mig virkelig over at hvis der er så mange udviklere som synes Git er fantastisk, at ingen af dem har integeret det ind i deres hverdags IDE.
Måske er det fordi at de kun bruger det til hobby projekter, og ikke på arbejde :o
#23
Nej, men jeg skal åbne mit filsystem. Hvilket jo entligt ikke giver mening, hvorfor skrive en shell extension i stedet for en IDE extension?
Jeg hader at have Windows plasteret til med versionsstyring i alle context menuer.
Derudover synes jeg TortoiseSVN er hamerende elendig og træls og ulogisk at arbejde med, men det er en anden diskussion.
Nej, men jeg skal åbne mit filsystem. Hvilket jo entligt ikke giver mening, hvorfor skrive en shell extension i stedet for en IDE extension?
Jeg hader at have Windows plasteret til med versionsstyring i alle context menuer.
Derudover synes jeg TortoiseSVN er hamerende elendig og træls og ulogisk at arbejde med, men det er en anden diskussion.
mat (25) skrev:
Men så er det jo også noget vås du skriver i #18? Og med Tortoise er der 2 punkter mere i context menuen, det er vist lige til at klare?
2 for svn, 2 for cvs, 2 for ... osv. Tror contextmenuen på min arbejds-pc er dobbelt så stor som på en std installation, pga af revisionsstyringsprogrammer.
Synes dog at VCS-folkene skal holde sig til at lave CLI interfaces, og så lade 3. parts udviklere sørge for explorer/ide-extensions. For selvom man kan diskutere frem og tilbage om hvad der er mest effektivt når der skal comittes til hverdag, så ender man alligevel altid op med at bruge konsollen, når man skal lave et eller andet syret commit, som bare skal være rigtigt.
#26
Normalvis bruger man vel det enkelte revisionsværktøj man har valgt i virksomheden, og så er der vel ingen grund til at have flere installeret?
2 for svn, 2 for cvs, 2 for ... osv. Tror contextmenuen på min arbejds-pc er dobbelt så stor som på en std installation, pga af revisionsstyringsprogrammer.
Normalvis bruger man vel det enkelte revisionsværktøj man har valgt i virksomheden, og så er der vel ingen grund til at have flere installeret?
Det sker at man har skiftet system fra projekter til projekter, ellers ville alle jo stadigvæk kører CVS.mat (27) skrev:Normalvis bruger man vel det enkelte revisionsværktøj man har valgt i virksomheden, og så er der vel ingen grund til at have flere installeret?
Men man konvertere ikke nødvendigvis de gamle projekter, bare fordi man skifter versionsstyringssystemer.
Acro (16) skrev:Hvis man ikke oplever SVN som en flaskehals, bruger man efter min mening ikke versionskontrol korrekt. Et commit skal beskrive én ændring; ikke være en backup hver halve time (det findes der bedre værktøjer til). Et typisk commit skal derfor, synes jeg, ikke indeholde mere end fx en ny metode. Sådan kan man dog ikke rigtigt arbejde med SVN, fordi det simpelthen er for upraktisk pga. hastigheden.
Kan det nu også passe?
Den primære grund til at SVN blev lavet var for at få atomisk commit af flere filer.
Deraf må det vel følge at det er tiltænkt at committe flere rettelser af gangen (som naturligvis stadig skal have en eller anden logisk sammenhæng).
Windcape (28) skrev:Det sker at man har skiftet system fra projekter til projekter, ellers ville alle jo stadigvæk kører CVS.
Nu er CVS jo "nyere".
Du kan få lov til at betragte RCS og SCCS som gamle.
Windcape (28) skrev:Men man konvertere ikke nødvendigvis de gamle projekter, bare fordi man skifter versionsstyringssystemer.
Det er såre normalt at have lidt blandet SVN, P4, PVCS og CVS og/eller VSS og TFS.
illishar (5) skrev:Men derudover, så hvis du ikke allerede ved hvad versionsstyring drejer sig om, så er der gode chancer for, at det ikke er noget du skal bekymre dig om ;)
Respektfuldt uenig.
Efter min mening kan næsten alle mennesker nyde godt af SVN.
Hvis man nogensinde har prøvet at ændre en fil, for derefter at ønske man havde den tidligere version - eller har prøvet at tage backup af ting, netop for at undgå det scenario - så er SVN et uundværligt værktøj.
Jeg er udmærket klar over det kun er en lille del af dens funktionalitet, og ikke hvad det primært er beregnet til - men jeg er fandeme glad for at jeg begyndte at bruge det, også selvom jeg er den eneste webgut på mit arbejde, og ikke har brug for versionering ellers.
Windcape (17) skrev:Jeg mener stadigvæk at IDE integration af versions-styring er essencielt.
Det mener du sikkert. Jeg mener, at produktivitet er vigtigst. Hvis jeg ikke kan få den samme produktivitet i et IDE, som jeg kan uden, så ser jeg ingen fordel ved IDE'et (det kan jeg dog normalt godt, jeg elsker fx IntelliSense).
Windcape (17) skrev:CodePlex supportere også Mercurial nu. Hvorfor skulle man så bruge Git.
Man kan også sagtens bruge Mercurial. Det er også et bedre valg end SVN.
Acro (16) skrev:Et typisk commit skal derfor, synes jeg, ikke indeholde mere end fx en ny metode. Sådan kan man dog ikke rigtigt arbejde med SVN, fordi det simpelthen er for upraktisk pga. hastigheden.
Windcape (17) skrev:Forklar hvad du mener med hastigheden. Fordi helt ærligt, du klikker "commit", og så koder du videre mens der bliver lavet commits i baggrunden.
Hastigheden er sådan set irrelevant. Jeg synes at have et overblik over hvilke filer der er ændret og hvorfor de er ændret, og hvilke tickets/tasks de er relaterede til, er meget meget mere vigtigt end hastighed.
Og derfor er IDE integration vigtigere end hastighed.
Hastighed er altafgørende for produktivitet. Den hastighed finder man ofte i et IDE, og derfor bruger man det typisk.
Et commit skal kun omfatte en enkelt ændring til kodebasen (dvs. ikke et helt nyt model eller en times arbejde), og den måde bliver besværlig at arbejde på, fordi det er tungt med SVN, da alting kører over netværket. Det giver sig selv, at lokale operationer på filsystemet til enhver tid slår operationer via netværk.
Forsøg at tilgå loggen over ændringer, skifte til en anden branch eller alt muligt andet, som du som professionel udvikler bør gøre flere gange i løbet af en dag; det er alt for tungt med SVN, men dine argumenter bærer præg af, at du a) ikke har prøvet andet, eller b) ikke bruger versionskontrol som andet end backup.
Jeg har rigeligt overblik over det uden at kunne se et lille grønt eller rødt ikon på filerne i Visual Studio. En typisk ændring berører ganske få filer alligevel, typisk kun en enkelt.
Windcape (18) skrev:Jeg skal ihvertfald ikke åbne en terminal for at kunne lave commits, jeg trykker på en knap, skriver hvilke ændringer jeg har lavet, og trykker OK.
Jeg skriver
git ca -m "Refactor to improve maintainability"
Jeg er udvikler og skriver derfor i sagens natur meget, så det bør gå betydeligt hurtigere end at klikke på en knap, evt. bevæge mig rundt i grænsefladen med tab eller lignende.
I øvrigt skriver man ikke hvilke ændringer, man har lavet, men hvorfor man har lavet dem. Hvilke ændringer fremgår af kildefilerne selv.
Der er en højere indlæringskurve, når der ikke er fine ikoner til det hele, men afkastet er en meget højere produktivitet herefter.
Windcape (18) skrev:Jeg har stadigvæk ikke fattet jer som hellere vil skrive terminal kommandoer 24/7 , eller skrive macros til formålet (hvilket jo i sidste ende ville være smartere at have direkte i dit udviklingsmiljø).
Det handler om produktivitet. Du kan også bruge en snippet til at lave en if-blok. Du kan sikkert også lave et interface, hvor du tegner et flow, der så bliver oversat til boolske udtryk. Ville du bruge det?
Effektivitet handler ikke om at have alle ting som ikoner på en værktøjslinje i ét program. Det er ganske misforstået, og så strider det vist imod din egen holdning i en tråd om Eclipse...
Windcape (18) skrev:Og det samme gælder unit tests forresten. Jeg ser heller ingen grund til ikke at bruge MS Test, medmindre du arbejder på noget i størrelsesordnen af et ERP system.
Det er også et produkt af uvidenhed. Visual Studio Standard og Web Developer Express har ikke understøttelse af MS Test, så hvis man tænker på kompatibilitet med andre, fx fordi man laver opensource, giver det god mening med et andet valg. Jeg bruger dog også selv MS Test, men jeg forstår trods alt, at der er grunde til at vælge noget andet. Det kræver blot en lille indsats at sætte sig ind i tingene...
Windcape (19) skrev:Glemte pointen:
Hvis Git folket laver et IDE plugin der er på niveau med AnkhSvn eller TFS til Visual Studio, skifter jeg gerne til Git i morgen.
Derudover undre det mig at der ikke er et (brugbart) Eclipse plugin til Git endnu (da Eclipse's SVN plugins er elendige, begge to).
Jeg undre mig virkelig over at hvis der er så mange udviklere som synes Git er fantastisk, at ingen af dem har integeret det ind i deres hverdags IDE.
Måske er det fordi at de kun bruger det til hobby projekter, og ikke på arbejde :o
Hvorfor skal Git-brugerne lave et plugin, som ikke andre end dig har behov for? Når det er sagt findes der TortoiseGit og Git Extensions, der netop integrerer i Visual Studio, hvilket for dig - tilsyneladende - er vigtigere, end hvad værktøjerne ellers er i stand til.
Jeg har prøvet at arbejde med VisualSVN, AnkhSVN og mange andre integrationer af mange andre systemer tidligere. De giver mig ikke den samme frihed, som det gør at skifte til min åbne konsol. Hvis du ser det som en stor udfordring, bør du nok genoverveje din profession.
Derudover er Linux-projektet nok et noget større arbejde, end noget du arbejder på.
arne_v (29) skrev:Kan det nu også passe?
Alt er jo relativt. Du kan også sagtens skrive forretningskode, der virker, uden at det overholder fx SRP, men der er mange grunde til at gøre det.
arne_v (29) skrev:Den primære grund til at SVN blev lavet var for at få atomisk commit af flere filer.
Deraf må det vel følge at det er tiltænkt at committe flere rettelser af gangen (som naturligvis stadig skal have en eller anden logisk sammenhæng).
For at arbejde fornuftigt med versionskontrol (også i forhold til projektstyring), bør man, synes jeg, arbejde således:
- lave en (story/topic)branch pr. feature, man vil have implementeret
- lave et commit pr. lille ændring, man laver
Det skaber en masse fordele. Fx er det let at kassere arbejde, ligesom det er let at beslutte, hvornår ting integreres.
Fordelene ved at have mindre commits fremfor større er mange, bl.a.; det er væsentligt lettere at foretage review, hvis der er ændret et par linjer, der har logisk sammenhæng, end hvis du har gjort mange ting. Det er tilsvarende lettere at pille enkelte commits ud, hvis en feature kasseres.
Jeg kan ikke finde nogle fordele for at bruge større commits, udover at nogle anvender værktøjer, hvor det simpelthen ikke er effektivt at arbejde sådan. Man kan jo også gå i den anden grøft og committe en gang dagligt, men hvad bruger man så egentlig: versionskontrol eller backup?
Acro (36) skrev:En typisk ændring berører ganske få filer alligevel, typisk kun en enkelt.
Hvis det er bug fixing.
Ellers vil der typisk være flere rettede filer.
Det er ikke hensigtsmæssigt at check ting ind som ikke builder eller vil fejle runtime p.g.a. at der mangler noget.
Acro (37) skrev:Der er en højere indlæringskurve, når der ikke er fine ikoner til det hele, men afkastet er en meget højere produktivitet herefter.
Acro (37) skrev:Effektivitet handler ikke om at have alle ting som ikoner på en værktøjslinje i ét program. Det er ganske misforstået,
Der er masser af tilfælde hvor det er mere produktivt at bruge command line tools end GUI tools.
Nogen gange er der mere kraftfulde features til rådighed command line.
Det er normalt meget nemmere at dokumentere command line work.
Command line work kan scriptes.
Personligt bruger jeg dog VCS integration hvis den findes i IDE og jeg bruger IDE.
Jeg har kun brug for meget simple operationer og ingen dokumentations eller scripting behov.
Hvis jeg var ansvarlig for branching og merging, så ville jeg sikkert finde command line tools bedre.
Windcape (19) skrev:
Jeg undre mig virkelig over at hvis der er så mange udviklere som synes Git er fantastisk, at ingen af dem har integeret det ind i deres hverdags IDE.
Måske er det fordi at de kun bruger det til hobby projekter, og ikke på arbejde :o
Jeg formoder at du har læst #10 !
Så du mener at Linux og Apache er et par hobby projekter ?
Acro (39) skrev:
For at arbejde fornuftigt med versionskontrol (også i forhold til projektstyring), bør man, synes jeg, arbejde således:
- lave en (story/topic)branch pr. feature, man vil have implementeret
- lave et commit pr. lille ændring, man laver
Det skaber en masse fordele. Fx er det let at kassere arbejde, ligesom det er let at beslutte, hvornår ting integreres.
Fordelene ved at have mindre commits fremfor større er mange, bl.a.; det er væsentligt lettere at foretage review, hvis der er ændret et par linjer, der har logisk sammenhæng, end hvis du har gjort mange ting. Det er tilsvarende lettere at pille enkelte commits ud, hvis en feature kasseres.
Jeg kan ikke finde nogle fordele for at bruge større commits, udover at nogle anvender værktøjer, hvor det simpelthen ikke er effektivt at arbejde sådan. Man kan jo også gå i den anden grøft og committe en gang dagligt, men hvad bruger man så egentlig: versionskontrol eller backup?
Jeg har en noget anderledes tilgang.
Det er vigtigt at det som er checket ind:
- builder
- kan starte op (i det mindste så meget at der står "denne feature er ikke færdigimplementeret endnu")
Ellers bliver det hurtigt meget problematisk for projekter med mange udviklere. Man skal kunne update uden at være bange for at pludseligt ingen ting virker.
Og jeg vil mene at reviews er nemmere hvis alle rettelser som vedrører en bestemt enhacment eller bug fix er bundtet sammen - de skal jo alligevel reviewes sammen.
Og sammenlign med at trykke en genvejstast for commit, som giver dig en promt hvor du kan skrive din besked i?Acro (37) skrev:Jeg skriver
Det kan aldrig blive hurtigere at du skal forlade dit udviklingsmiljø for at lave et commit.
Og derudover tror jeg du kraftigt overvuderer hvor mange der rent faktisk bruger VCS som andet end backup, og history log. Det er jo nemt nok i dit eget firma, men prøv at kigge i større organsationer.
Netop Open Source projekter har bedre / mere moderne strukture er fordi at folk spendere tid på det derhjemme. Hvis der stod en chef og kiggede dem over skuldren, så ville de sikkert stadigvæk bruge CVS.
Nej, men jeg mener at udvikler på Linux og Apache er ekstremt IDE fjenske, og hellere vil bruge 3-4 forskellige værktøjer i stedet for et samlet produkt.arne_v (43) skrev:Så du mener at Linux og Apache er et par hobby projekter ?
Jeg har brugt det meste af formiddagen i dag på at teste Mercurial i stedet for SVN (fordi vores Team Space understøtter begge dele).
Grunden var faktisk at Mercurial's Eclipse plugin er meget bedre end de to SVN plugins der er til Eclipse.
Jeg kan slet ikke se hvorfor jeg skal bruge commandline til formålet, når jeg har visuelle værktøjer som tillader det at blive klaret nemt og smertefrit.
Hvis Acro skriver samme kommando 50-100 gange om dagen, kunne han jo ligeså godt lave en macro ala:
gitcommit "my commit message"
for at slippe for de andre parameter.
Derudover er ting som branches o. lign. meget bedre med visuelle værktøjer, så man faktisk kan se hvad der foregår.
Windcape (47) skrev:Jeg kan slet ikke se hvorfor jeg skal bruge commandline til formålet, når jeg har visuelle værktøjer som tillader det at blive klaret nemt og smertefrit.
Vi har haft den diskussion før.
Bottom line: nogle opgaver er nemmest at udføre i en IDE, andre opgaver er nemmest at udføre i CLI.
#48
Så forklar hvorfor det er nemmere at åbne en terminal, skrive en lang kommando manuelt, og håbe på man ikke har tastet forkert.
Frem for at trykke "commit" i sit IDE, og derefter fortsætte med at kode.
Jeg har endnu ikke set argumenter for hvorfor det skulle være nemmere at bruge en terminal. Argumentet er jo bare at der ikke er nogen som har lavet en GUI oven på terminal kommandoerne endnu!
Hvis det skete er jeg helt sikker på at folk ville bruge det.
Så forklar hvorfor det er nemmere at åbne en terminal, skrive en lang kommando manuelt, og håbe på man ikke har tastet forkert.
Frem for at trykke "commit" i sit IDE, og derefter fortsætte med at kode.
Jeg har endnu ikke set argumenter for hvorfor det skulle være nemmere at bruge en terminal. Argumentet er jo bare at der ikke er nogen som har lavet en GUI oven på terminal kommandoerne endnu!
Hvis det skete er jeg helt sikker på at folk ville bruge det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund