Recommended
Recommended
More Related Content
Similar to Presentatie Git
Similar to Presentatie Git (20)
Presentatie Git
- 1. DVCS presentatie Hogeschool van Arnhem en Nijmegen DVCS – een introductie met behulp van Git Wilbert van Dolleweerd Application Developer
- 2. DVCS presentatie Hogeschool van Arnhem en Nijmegen Wie is die man en wat doet hij hier? • Application Developer bij CSC • Gedetacheerd als buildmanager bij C2SC (onderdeel van Defensie) • Verantwoordelijk voor alle buildprocessen + het versiebeheer systeem • Codebase circa 4,5 miljoen regels C#, C++, Visual Basic 6, ADA, etc.
- 3. DVCS presentatie Hogeschool van Arnhem en Nijmegen DVCS – Distributed Version Control System • Eerst een traditioneel VCS…
- 4. DVCS presentatie Hogeschool van Arnhem en Nijmegen DVCS – Distributed Version Control System • Nu met distributed goodness…
- 5. DVCS presentatie Hogeschool van Arnhem en Nijmegen Wat levert je dit op? “Speed is a feature!” - Linus Torvalds
- 6. DVCS presentatie Hogeschool van Arnhem en Nijmegen Off-line gebruik oftewel het vliegtuig scenario
- 7. DVCS presentatie Hogeschool van Arnhem en Nijmegen Lokale branches • Eenvoudig en snel lokale (in je eigen repository) branches aanmaken • Wanneer is de laatste keer dat je bijvoorbeeld in Subversion een eigen branch aanmaakte voor een experiment?
- 8. DVCS presentatie Hogeschool van Arnhem en Nijmegen Slimmer mergen • Een versiebeheer systeem wat gedistribueerd is MOET ook goed kunnen mergen, anders heb je er niets aan.
- 9. DVCS presentatie Hogeschool van Arnhem en Nijmegen “History is mutable” • Design filosofie van Git: alles is (lokaal) te veranderen • Extreme flexibiliteit • Dit kan ook mooie ‘rm –rf’ ervaringen opleveren
- 10. DVCS presentatie Hogeschool van Arnhem en Nijmegen DEMO
- 11. DVCS presentatie Hogeschool van Arnhem en Nijmegen Nieuwe workflow mogelijkheden • Subversion style
- 12. DVCS presentatie Hogeschool van Arnhem en Nijmegen Nieuwe workflow mogelijkheden • Github model met integratie manager
- 13. DVCS presentatie Hogeschool van Arnhem en Nijmegen Nieuwe workflow mogelijkheden • Linux kernel model met dictator en luitenanten
- 14. DVCS presentatie Hogeschool van Arnhem en Nijmegen Een workflow kan ook via branches in een repository
- 15. DVCS presentatie Hogeschool van Arnhem en Nijmegen “Elk voordeel heb zijn nadeel” • Minder geschikt om flinke binaries op te slaan (denk aan game- development) • Geen lock mechanisme kan een nadeel zijn • Steile leercurve / command line interface (wees niet bang: er zijn ook grafische clients beschikbaar voor alle platformen) • Windows is voor Git een ‘second-rate citizen’
- 16. DVCS presentatie Hogeschool van Arnhem en Nijmegen Tips / best practices • Kies een globale werkwijze met je team en hou je daaraan • Wees niet bang van branches – gebruik ze in je voordeel • Hou je commits logisch en klein (liever teveel kleine commits dan weinig grote commits) • Schrijf duidelijke commit messages • ‘Merge early, merge often’ blijft belangrijk
- 17. DVCS presentatie Hogeschool van Arnhem en Nijmegen Meer informatie • Mijn Google+ http://gplus.to/WilbertVanDolleweerd (shameless plug) • Google Talk van Randal Schwartz over Git over waarom je Git zou moeten gebruiken • ‘The thing about Git’ – een artikel over de flexibiliteit van Git • Git immersion – een guided tour door Git • http://help.github.com/ - hoe gebruik je Git in combinatie met Github • Alle documentatie op de Git site
Editor's Notes
- Kleine uitleg over CSC Kleine uitleg over C2SC – de organisatie Kleine uitleg over C2SC – de producten Toelichting over wat ik vandaag ga vertellen. Vooral over DVCS en een kleiner verhaal over builds. De nadruk leggen dat dit een introductie is – onderwerpen zullen redelijk snel doorlopen worden. Na afloop wil ik graag vragen beantwoorden (inclusief specifieke werksituaties voor het HAN)
- Het oude centrale systeem waarbij wijzigingen worden uitgewisseld via de centrale server. Subversion, CVS, Perforce, Team Foundation Server, etc.
- Het nieuwe systeem waarbij iedereen een volledige kopie van de repository lokaal heeft staan. ALLE operaties lopen via je eigen repository. Alleen als je code wilt uitwisselen communiceer je met andere repositories. Alle repositories zijn gelijkwaardig – alleen bij definitie heeft een bepaalde repository een andere status. Er kan nog steeds gebruik worden gemaakt van een centrale repository. DVCS staat dat niet in de weg (sterker nog, de meeste teams werken zo)
- Gedistribueerde versiesystemen werken op je lokale filesysteem. Alle operaties werken dus ook met de snelheid van je filesysteem. Als je met Subversion een oude commit wil bekijken zal dat eerst over het netwerk getrokken moeten worken. Binnen Git is het alleen een beetje file-access (en Linux kernel hackers weten wel hoe ze dat moeten optimaliseren). Toelichten dat Linus Git heeft geschreven omdat andere systemen niet aan zijn snelheidseis konden voldoen. Linus kan op een merge-dag wel honderden merges verwerken en wil hierbij geen tijd kwijt zijn aan wachten.
- De gehele repository lokaal hebben staan wil zeggen dat je je werk volledig onafhankelijk kan doen. Je kunt nog steeds gebruik maken van je DVCS om branches aan te maken, te diffen, tests te doen op oude code, etc. Belangrijke regel: Lokaal iets ontwikkelen en het later aanbieden ter integratie zijn nu twee gescheiden stappen geworden.
- Je bent vrij om elk moment een eigen branch aan te maken en daarin te ontwikkelen. Is je code crap? Gooi de branch weg. Is het iets zinnigs? Dan kun je gaan nadenken over hoe je dit wilt gaan integreren. Ben je bezig met development en er wordt een kritieke bug in je applicatie ontdekt? Maak een branch aan op het punt van de release en fix de bug. Integreer de bug branch en spring daarna weer terug naar je development branch om door te gaan met je eerdere werk.
- Omdat Git zijn informatie in een graph opslaat (waarbij de nodes de commits zijn en de edges de verbindingen tussen de nodes) heeft Git meer informatie beschikbaar om correct te kunnen mergen. Dit in tegenstelling tot oudere CVS systemen (waarbij merges echt een hel kunnen zijn). Natuurlijk blijven oude vertrouwde principes als: “merge early, merge often” nog wel overeind staan. Omdat je weet dat Git goed kan mergen ga je juist ook functionaliteit als branches juist veel meer gebruiken in tegenstelling tot oudere systemen waarbij vaak samen in de trunk gewerkt worden en branches alleen bij releases aangemaakt worden.
- (Foto van Iwo Jima toelichten) Binnen versiebeheer land zijn er twee kampen: zij die denken dat een commit heilig is en nooit meer kan worden verwijderd en zij die denken dat dit niet zo is. Git valt in de laatste categorie. Met Git is het mogelijk om de gehele geschiedenis van een branch of repository volledig om te gooien. Enkele voorbeelden: Je hebt per ongeluk je private Twitter API key toegevoegd aan een open source project waardoor iedereen jouw key kan misbruiken. Je hebt een bugfix opgelost maar je had daarvoor meerdere commits nodig. Git maakt het mogelijk dat je die commits samenvoegt tot 1 enkele commit. Je hebt een branch gekregen van een collega, maar je vind dat een bepaalde commit daar niet in thuishoort. Git staat je toe dat je die commit eruit haalt. Je hebt een commit gemaakt waarin je twee problemen tegelijk hebt opgelost. Je kunt deze splitsen zodat elk probleem in een aparte commit wordt opgelost. Etc, etc. Het is zelfs mogelijk om de historie van een centrale repository te wijzigen. Pas hier echter mee op – hiermee kun je een hoop gebruikers gaan dwarszitten.
- Demonstratie Git mogelijkheden aan de hand van GitDemo repositories. 1. In Gitk laten zien welke structuur er nu is opgezet. Uitleg over elke branch. 2. Laten zien hoe snel switchen tussen branches gaat. Met het switchen tussen beide branches laten zien dat het switchen snel gaat maar dat wel degelijk de bestanden gewijzigd worden. 3. Laten zien dat dit standaard te mergen is. Merge-conflict in Gitignore oplossen. Het dan weer terugdraaien om de flexibiliteit aan te tonen. In branch master 'git merge ImplementEmail' Terugdraaien met 'git reset --hard ORIG_HEAD' In Gitk laten zien dat de originele historie weer is hersteld. 4. Cherry-picking. Laten zien dat je de changeset 'Ignore VIM backup files' ook kunt cherry-picken. Daarna weer terugdraaien. Cherry-pick en reset via GITK laten zien. 5. Patch maken van de juiste .gitignore commit via 'git format-patch <sha> -1'. De inhoud van de patch laten zien. Switchen naar de master branch en apply'en met 'git am <patchfile>. Weer terugdraaien via git reset. 6. Interactive rebase van ImplementEmail branch. - Van te voren een test branch aanmaken met git checkout -b 'rebasetest'. - De twee gitignore commits squashen naar 1 commit met git rebase -i HEAD~5. - Terug naar de originele branch met git checkout ImplementEmail. Daarna de oude demorebase deleten met 'git branch -D demorebase' - Volgorde van commits veranderen. Eerst weer testbranch aanmaken met git checkout -b rebasedemo. Git rebase -i head~5. Vervolgens met '2dd' 2 lines cutten en pasten met P onderaan de lijst. - Terug naar de originele branch met git checkout ImplementEmail. Daarna de oude demorebase deleten met 'git branch -D demorebase' - Commit verwijderen. Eerst weer testbranch aanmaken met git checkout -b rebasedemo. Git rebase -i head~5. Daarna commit met commentaar verwijderen. - Terug naar de originele branch met git checkout ImplementEmail. Daarna de oude demorebase deleten met 'git branch -D demorebase' - Commit verwijderen. - Commit --amend. Maak een wijziging in Email.cs waarbij je Zawinski verandert in Wilbert. Daarna adden en amenden. 7. Rebase bovenop master. git checkout ImplementatieEmail git rebase master proces uitleggen / gitk --all git co master git merge ImplementatieEmail
- Er staat ergens een centrale repository op een server. Alle developers hebben hier een kloon van getrokken en werken lokaal aan hun wijzigingen. Zodra ze klaar zijn zetten ze hun wijzigingen door naar de centrale repository. In dit model hebben alle developers dus rechten om wijzigingen naar de centrale repository te pushen.
- Er is een centrale repository waar alleen de integratie manager (eigenaar) schrijfrechten op heeft. Developers kunnen deze repository wel klonen en eigen ontwikkelingen publiceren (in een publiek toegankelijke repository). De integratie manager trekt deze wijzigingen naar binnen, beoordeelt ze en zet ze uiteindelijk door naar de centrale repository. De developers kunnen dan uiteindelijk deze wijzigingen uit de centrale repository ook weer naar binnen halen.
- Er is een centrale repository waar alleen de dictator (Linus) schrijfrechten op heeft. Hij heeft een aantal vertrouwelingen (luitenanten) waarvan hij zonder meer de wijzigingen overneemt. Elke luitenant is bijvoorbeeld verantwoordelijk voor een subsysteem. Developers laten hun wijzigingen integreren in de repository van de luitenant waarna Linus ze overneemt en doorzet naar de centrale repository. Schaalbaarheid noemen.
- Workflow via branches toelichten. Ontwikkeling begint via ‘develop’ Grote features worden ontwikkelt in feature branches en mogen alleen terug mergen naar develop. Zodra de release nadert, wordt een release branch aangemaakt waarin je stabiliseert. De develop branch verandert nu naar de volgende release. Vanuit release mag je terug mergen naar develop. Als een release klaar is, wordt dit doorgezet naar master met een tag. Eventuele bugs mogen in een hotfix branch gemaakt worden. Deze gaan dan terug naar develop.
- Lock mechanisme: mogelijkheid om een file te locken zodat niemand anders deze kan uitchecken.
- Artikelen op mijn weblog: installatie / configuratie van Git op Windows. Artikel over een Powershell script om Team Foundation Server repositories over te zetten naar Git.