Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Presentatie Git

on

  • 440 views

Presentatie voor Hogeschool Arnhem/Nijmegen over Git.

Presentatie voor Hogeschool Arnhem/Nijmegen over Git.

Statistics

Views

Total Views
440
Views on SlideShare
437
Embed Views
3

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 3

https://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Kleineuitleg over CSCKleineuitleg over C2SC – de organisatieKleineuitleg over C2SC – de productenToelichting overwatikvandaaggavertellen. Vooral over DVCS en eenkleinerverhaal over builds. De nadrukleggendatditeenintroductie is – onderwerpenzullenredelijksneldoorlopenworden.Na afloopwilikgraagvragenbeantwoorden (inclusiefspecifiekewerksituatiesvoor het HAN)
  • Het oudecentralesysteemwaarbijwijzigingenwordenuitgewisseld via de centrale server. Subversion, CVS, Perforce, Team Foundation Server, etc.
  • Het nieuwesysteemwaarbijiedereeneenvolledigekopie van de repository lokaalheeftstaan. ALLE operatieslopen via je eigen repository. Alleenals je code wilt uitwisselencommuniceer je met andere repositories. Alle repositories zijngelijkwaardig – alleenbijdefinitieheefteenbepaalde repository eenandere status.Erkannog steeds gebruikwordengemaakt van eencentrale repository. DVCS staatdatniet in de weg (sterkernog, de meeste teams werkenzo)
  • Gedistribueerdeversiesystemenwerken op je lokalefilesysteem. Alleoperatieswerkendusook met de snelheid van je filesysteem. Als je met Subversion eenoude commit wilbekijkenzaldateerst over het netwerkgetrokkenmoetenworken. BinnenGit is het alleeneenbeetje file-access (en Linux kernel hackers wetenwel hoe zedatmoetenoptimaliseren).Toelichtendat Linus Githeeftgeschrevenomdatanderesystemennietaanzijnsnelheidseiskondenvoldoen. Linus kan op een merge-dag welhonderden merges verwerken en wilhierbijgeentijdkwijtzijnaanwachten.
  • De gehele repository lokaalhebbenstaanwilzeggendat je jewerkvolledigonafhankelijkkandoen. Je kuntnog steeds gebruikmaken van je DVCS om branches aantemaken, tediffen, tests tedoen op oude code, etc. Belangrijke regel: Lokaalietsontwikkelen en het later aanbiedenterintegratiezijn nu twee gescheidenstappengeworden.
  • Je bent vrijom elk moment eeneigen branch aantemaken en daarinteontwikkelen. Is je code crap? Gooi de branch weg. Is het ietszinnigs? Dan kun je gaannadenken over hoe je dit wilt gaanintegreren.Ben je bezig met development en erwordteenkritieke bug in je applicatieontdekt? Maakeen branch aan op het punt van de release en fix de bug. Integreer de bug branch en spring daarnaweerterugnaar je development branch om door tegaan met je eerderewerk.
  • OmdatGitzijninformatie in een graph opslaat (waarbij de nodes de commits zijn en de edges de verbindingentussen de nodes) heeftGitmeerinformatiebeschikbaarom correct tekunnenmergen.Dit in tegenstelling tot oudere CVS systemen (waarbij merges echteenhelkunnenzijn).Natuurlijkblijvenoudevertrouwdeprincipesals: “merge early, merge often” nogwelovereindstaan.Omdat je weetdatGitgoedkanmergenga je juistookfunctionaliteitals branches juistveelmeergebruiken in tegenstelling tot ouderesystemenwaarbijvaaksamen in de trunk gewerktworden en branches alleenbij releases aangemaaktworden.
  • (Foto van Iwo Jima toelichten)Binnenversiebeheer land zijner twee kampen: zij die denkendateen commit heilig is en nooitmeerkanwordenverwijderd en zij die denkendatditnietzo is. Gitvalt in de laatstecategorie.Met Git is het mogelijkom de gehelegeschiedenis van een branch of repository volledigomtegooien. Enkelevoorbeelden:Je hebt per ongeluk je private Twitter API key toegevoegdaaneen open source project waardooriedereenjouw key kanmisbruiken.Je hebteenbugfixopgelost maar je had daarvoormeerdere commits nodig. Gitmaakt het mogelijkdat je die commits samenvoegt tot 1 enkele commit.Je hebteen branch gekregen van eencollega, maar je vinddateenbepaalde commit daarniet in thuishoort. Gitstaat je toe dat je die commit eruithaalt.Je hebteen commit gemaaktwaarin je twee problementegelijkhebtopgelost. Je kuntdezesplitsenzodat elk probleem in eenaparte commit wordtopgelost.Etc, etc.Het is zelfsmogelijkom de historie van eencentrale repository tewijzigen. Pas hierechtermee op – hiermee kun je een hoop gebruikersgaandwarszitten.
  • DemonstratieGitmogelijkhedenaan de hand van GitDemo repositories.1. In Gitklatenzienwelkestructuurer nu is opgezet. Uitleg over elke branch.2. Latenzien hoe snelswitchentussen branches gaat. Met het switchentussenbeide branches latenziendat het switchensnelgaat maar datweldegelijk de bestandengewijzigdworden.3. Latenziendatditstandaardtemergen is. Merge-conflict in Gitignoreoplossen. Het danweerterugdraaienom de flexibiliteitaantetonen. In branch master 'git merge ImplementEmail'Terugdraaien met 'git reset --hard ORIG_HEAD' In Gitklatenziendat de originelehistorieweer is hersteld.4. Cherry-picking. Latenziendat je de changeset 'Ignore VIM backup files' ookkunt cherry-picken.Daarnaweerterugdraaien. Cherry-pick en reset via GITK latenzien.5. Patch maken van de juiste .gitignore commit via 'git format-patch -1'. De inhoud van de patch latenzien. Switchennaar de master branch en apply'en met 'git am . Weerterugdraaien via git reset.6. Interactive rebase van ImplementEmail branch. - Van tevoreneen test branch aanmaken met git checkout -b 'rebasetest'. - De twee gitignore commits squashennaar 1 commit met git rebase -i HEAD~5. - Terugnaar de originele branch met git checkout ImplementEmail. Daarna de oudedemorebasedeleten met 'git branch -D demorebase' - Volgorde van commits veranderen. Eerstweertestbranchaanmaken met git checkout -b rebasedemo. Git rebase -i head~5. Vervolgens met '2dd' 2 lines cutten en pasten met P onderaan de lijst. - Terugnaar de originele branch met git checkout ImplementEmail. Daarna de oudedemorebasedeleten met 'git branch -D demorebase' - Commit verwijderen. Eerstweertestbranchaanmaken met git checkout -b rebasedemo. Git rebase -i head~5. Daarna commit met commentaarverwijderen. - Terugnaar de originele branch met git checkout ImplementEmail. Daarna de oudedemorebasedeleten met 'git branch -D demorebase'- Commit verwijderen. - Commit --amend. Maakeenwijziging in Email.cswaarbij je Zawinskiverandert in Wilbert. Daarnaadden en amenden.7. Rebase bovenop master.git checkout ImplementatieEmailgit rebase masterprocesuitleggen / gitk --allgit co mastergit merge ImplementatieEmail
  • Erstaatergenseencentrale repository op een server. Alle developers hebbenhiereenkloon van getrokken en werkenlokaalaanhunwijzigingen. Zodrazeklaarzijnzettenzehunwijzigingen door naar de centrale repository.In dit model hebbenalle developers dusrechtenomwijzigingennaar de centrale repository tepushen.
  • Er is eencentrale repository waaralleen de integratie manager (eigenaar) schrijfrechten op heeft. Developers kunnendeze repository welklonen en eigenontwikkelingenpubliceren (in eenpubliektoegankelijke repository). De integratie manager trektdezewijzigingennaarbinnen, beoordeeltze en zetzeuiteindelijk door naar de centrale repository.De developers kunnendanuiteindelijkdezewijzigingenuit de centrale repository ookweernaarbinnenhalen.
  • Er is eencentrale repository waaralleen de dictator (Linus) schrijfrechten op heeft. Hijheefteenaantalvertrouwelingen (luitenanten) waarvanhijzondermeer de wijzigingenoverneemt. Elkeluitenant is bijvoorbeeldverantwoordelijkvooreensubsysteem. Developers latenhunwijzigingenintegreren in de repository van de luitenantwaarna Linus zeoverneemt en doorzetnaar de centrale repository.Schaalbaarheidnoemen.
  • Workflow via branches toelichten.Ontwikkelingbegint via ‘develop’Grote features wordenontwikkelt in feature branches en mogenalleenterugmergennaar develop.Zodra de release nadert, wordteen release branch aangemaaktwaarin je stabiliseert. De develop branch verandert nu naar de volgende release. Vanuit release mag je terugmergennaar develop.Alseen release klaar is, wordtditdoorgezetnaar master met een tag.Eventuele bugs mogen in een hotfix branch gemaaktworden. Dezegaandanterugnaar develop.
  • Lock mechanisme: mogelijkheidomeen file telockenzodatniemandandersdezekanuitchecken.
  • Artikelen op mijn weblog: installatie / configuratie van Git op Windows. Artikel over eenPowershell script om Team Foundation Server repositories over tezettennaarGit.

Presentatie Git Presentatie Git Presentation Transcript

  • DVCS – een introductie met behulp van Git Wilbert van Dolleweerd Application Developer 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. DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • DVCS – Distributed Version Control System• Eerst een traditioneel VCS… DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • DVCS – Distributed Version Control System• Nu met distributed goodness… DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • Wat levert je dit op? “Speed is a feature!” - Linus Torvalds DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • Off-line gebruik oftewel het vliegtuig scenario 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? 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. 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 DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • DEMO DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • Nieuwe workflow mogelijkheden• Subversion style DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • Nieuwe workflow mogelijkheden• Github model met integratie manager DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • Nieuwe workflow mogelijkheden• Linux kernel model met dictator en luitenanten DVCS presentatie Hogeschool van Arnhem en Nijmegen
  • Een workflow kan ook via branches in een repository 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‟ 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 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 DVCS presentatie Hogeschool van Arnhem en Nijmegen