Guide til GIT VCS?
Hej..
Jeg sidder og skal bruge et version håndtering system. Jeg har brugt svn(subversion) før.
Nu sidder jeg og vil prøve Linus Torvalds VCS, nemlig GIT.
Er der nogen som kan guide mig lidt, har nemlig en del problemer.
Jeg har en server på www.assembla.com og jeg kan selv smide ting op på den og hente fra den.
git commit, pull, push og add, men jeg har ikke haft muligheden for at andre i mit projekt kunne gøre det med samme servere.
Nogen der kender git og måske kan hjælpe mig?
Jeg sidder og skal bruge et version håndtering system. Jeg har brugt svn(subversion) før.
Nu sidder jeg og vil prøve Linus Torvalds VCS, nemlig GIT.
Er der nogen som kan guide mig lidt, har nemlig en del problemer.
Jeg har en server på www.assembla.com og jeg kan selv smide ting op på den og hente fra den.
git commit, pull, push og add, men jeg har ikke haft muligheden for at andre i mit projekt kunne gøre det med samme servere.
Nogen der kender git og måske kan hjælpe mig?
Kommentarer21
Jeg har pt. gang i en
Det er dog ikke så idybdegående. Men hvis du har spørgsmål kan du endelig stille dem her.
Re: Jeg har pt. gang i en
Jamen hjemme siden må jeg sige hjalp, men jeg har stadig en hel masse tråde jeg ikke forstår med GIT.
Har nok siddet forlænge med subversion til at skelne arkitekturen i deres fremgangs måde.
Jeg er i gang med at læse bogen Version Control With Git, men håbede der var en lidt lettere vej end at læse 300 sider.
Alternativt kan du se på
Der er gode konverterings værktøjer for at konvertere eksisterende f.eks. SVN repositories til Mercurial. Der er gode plugins til f.eks. Eclipse og Microsoft Visual Studio hvis man bruger sådan noget.
http://mercurial.selenic.com/
Om ikke andet, så surf lidt rund på siden. Der er en god mængde brugbar information.
#2
Det vigtigste for at
Det vigtigste for at forstå git, og iøvrigt de andre DVCS'er (Mercurial, Bazaar o.lign.), er at der ikke er ét repository, men utallige.
Et af de projekter jeg er involveret i fungerer på denne måde:
- Et åbent repository på Github (github.com - brug det, det er helt vildt godt. De har også en række HOWTOs der kan være behjælpelige) som er den "stabile" linie til resten af verden. Dette repository er projektlederens public repository. Det er her folk forker fra.
- Et privat repository på hver udviklers lokale maskine, der er en fork af projektlederens. Det er her det daglige arbejde foregår for hver udvikler.
- Et public repository for hver udvikler på Github. Det er her man udgiver sin kode til offentligheden, men uden at den ryger i den stabile linie. Udviklere kan pull'e fra hinandens public repos hvis de samarbejder om noget. Projektlederen får at vide fra udviklerne, når deres ændringer menes at være stabile. Han giver dem et kort review, og så pull'er han dem ind i sit eget public repo, hvor de så fra nu af vil være en del af main, som fremtidige udviklere forker fra, og hvorfra releases dannes.
Re: #2 Det vigtigste for at
Det var fantastisk informativt, virkelig noget der gjorde det hele meget lysere. Hvis jeg forstår dig ret, så er der en der har kontrol af den stabile version og de andre udviklere(repository) kan lave et pull af hovedprojektet. Når de enkelte udviklere hver især mener deres kode er stabilt, så kan den som har ansvar af hoved projektet lave et pull af de andre udvikleres projekt, commit det og pushe det til hoved repositorien?
Jeg sidder hele tiden med billed af vi alle sidder og kigger på hoved repositorien hver gang vi vil commit noget.
Glæder mig til at læse din danske guide og tak for hjælpen.
#5 Det er den mest hyppige
Det er den mest hyppige model, ja. I Linux-kernen er der et ekstra lag mellem projektleder(Linus) og udviklere -- Lieutenants. De er en slags mellemledere der puller fra udviklerne, gennemkigger koden, og lægger det godkendte frem til Linus der så kan pulle det han selv vil have. Alle andre puller så fra Linus som hovedrepo.
Det fede ved den distribuerede model er at du iogforsig selv kan opbygge et flow der passer til dit projekt.
I den virksomhed jeg arbejder i, hvor jeg er git(server)-ansvarlig, har vi en lidt fladere struktur, fordi alle udviklerne sidder indenfor 3 meter af hinanden, og at vores produkt er rolling release. Her har den enkelte udvikler fuld adgang til at pushe direkte til hovedrepositoriet, selvom vi gør en dyd ud af at reviewe hinandens kode først.
Du kan også kigge på denne
http://progit.org/book/
Re: Guide til GIT VCS?
Tak for hjælpen. Det har hjulpet mig en hel del. Jeg ville lige høre hvilke værktøjer i bruger til at sammenføje de forskellige projekter, før man pusher det til hoved repositorien?
Jeg skriver i C# (Arbejde) og Java(Skole/Hjemme). Her bruger jeg Visual studio og Netbeans.
Jeg er ikke helt sikker på
hvis jeg fx skal have ændringerne fra Birger, Herman og Johanna ind i deployment repository:
$ git pull birger master
$ git pull herman master
$ git pull johanna master
$ git push deployment master
Re: Jeg er ikke helt sikker på
Jeg har selv kigget lidt på det der hedder smartGit til windows. Var bare nysgerrig i at høre hvad i brugte.
Håber det gav lidt mening.
#10
Der kan ske flere
Der kan ske flere ting.
Scenarie 1:
Herman og Birger har begge to tilføjet noget til CustomerClass, på vidt forskellige steder i klassen. Du puller deres ændringer med
$ git pull herman master
$ git pull birger master
og alt er godt. Hver gang du puller, laver Git et "merge" hvor den sammenfletter filer der er ændret af flere parter. Det vil sige at hvis du selv har lavet ændringer i CustomerClass når du puller fra Herman, vil dine og Hermans ændringer blive flettet sammen. Når du derefter puller fra Birger vil hans ændringer blive flettet sammen med jeres.
Scenarie 2:
Herman og Birger har begge to rettet i _de samme linier_ i CustomerClass. Idét du puller:
$ git pull herman
$ git pull birger
Vil du få at vide at der ikke kunne laves en clean merge fordi der er konflikter. Du vil derefter blive bedt om at redigere de nævnte filer, vælge den af de to muligheder der er listet hvert sted der er konflikt, og derefter committe filen igen i git, som den nye revision. Dette vil færdiggøre pullet.
Derefter kan du pushe den nye, sammenflettede revision til main-repo.
Re: #10 Der kan ske flere
Håber der snart kommer noget der integrere sig bedre med Visual Studio, men ellers køre det glimrende når man har fremgangs måden på plads.
Tak for hjælpen arnbak, helistorm og især marx for de fantastiske eksempler fra git.
Glæder mig nu stadig til at se din guide marx.
Det er måske lidt sent at
http://git.or.cz/course/svn.html
Det er/var en side der hed GitCasts, desværre virker ingen af hans videoer (jeg har dog en kopi). Jeg lærte en masse af at se dem.
Re: Det er måske lidt sent at
Ja siden er nu meget god for at se hvilke funktioner er lige med SVN. Hvis du havde videoerne liggende, vil jeg da gerne se dem.
Jeg tror mere det kræver et helt skift for at forstå GIT og dens fremgangsmåde, da de 2 VCS systemer ikke arbejder helt på samme måde. Hjemmesiden er ikke ubrugelig til nybegynderne, men for mig hjalp det og få et helt andet indblik og helt droppe SVN's tankegang.
#14
Beklager det sene svar,
Beklager det sene svar, Scott Chacon (manden bag GitCasts) har lagt videoerne op på blip.tv
http://chacon.blip.tv/posts?view=archive&nsfw=dc
Re: Jeg har pt. gang i en
Jeg ville lige høre dig angående din danske manual.
Du sagde en gang at du ville keerer en dansk brugervejledning til git.
Hvis du er færdig med den eller kan give besked når den er færdig, er jeg meget interesseret i at læse den igennem?
Jeg har siddet i nogle projekter og brugt det her system, og jeg kan stærkt anbefale det, til alle der vil bruge et versionstyringssystem.
#16
Det er stadig på min
Det er stadig på min liste af ting jeg skal have gjort. Jeg har haft travlt med en masse andre projekter i lang tid, så den er stadig lidt ude og hænge. Desværre.
#17
Bare for lige at øge
Bare for lige at øge presset vil jeg lige sige at jeg også venter på den guide. :)
Jamen fantastisk, hvis der
#19
#19