What is version control and why should web developers use it? What is the difference between Subversion (SVN) and Git for example? And what are best practices to use Git in a modern web developers world.

1. git for the win!
2015 - Denver Sessink

2. git != GTI

3. Wat gaan we bespreken?
● Wat en waarom?
● Verschillende VCS systemen
● Git basics en gedachtengang
● Git branching / merging
● Onze werkwijze

5. Waarom
versiebeheer….

6. Ooit een wijziging in code terug willen draaien?

7. Ooit code verloren of een back-up gehad die te oud was?

8. Hoe gaan we meerdere versies van een product handhaven?

9. Ooit het verschil willen zien tussen twee code files?

10. En met 2+ programmeurs tegelijk aan hetzelfde project werken?

11. Wat?
VCS (Version Control System)
Wijzigingen bijhouden in een logboek
Werkt het beste voor tekstfiles (code!)

12. Distributed vs Centralized
Centralized
Subversion
Distributed
Git

13. Distributed vs Centralized

14. Wat is Git?
Git is een distributed version control (dvcs) en
source code management (scm) systeem,
gericht op snelheid, data integriteit en niet-
lineaire workflows.

15. Wat is Git?

16. Git is...
● Snel!
● Simpel (in de basis :p)
● Stabiel en robuust (easy 1000+ branches)
● SFully distributed
○ Volledige lokale repository
○ Offline commits

17. git is dus toch een beetje GTI ;-)

18. Maar...
● Alle gecommitte bestanden blijven altijd in
IEDERE clone!
● Git kent geen lege mappen
● Zonder genoeg basiskennis is kan het een
b*tch zijn

19. Iets de diepte in...
… please!

20. Termen...
Workspace
Working directory
Clone
Index
Repository
Branche
Commit
Pull
Push
Merge
….

22. In commando’s...
~ mkdir projectmapje
~ cd projectmapje
~ git init
// lekker index.php maken en code typen
~ git add index.php
~ git commit -m “Eerste versie homepage gemaakt”
~ git push

23. In commando’s...
~ cd projectmapje-met-git
~ git pull
// lekker index.php wijzigen
~ git commit -m “Tweede versie homepage gemaakt”
~ git pull
~ git push

24. Branches...
aftakkingen dus

25. Master vs develop
Git heeft altijd tenminste 1 branche: master
Wij gebruiken altijd twee branches:
1. master → voor live-omgeving
2. develop → voor acceptatie-omgeving

26. Wijziging doen in feature branch...
~ cd projectmapje-met-git
~ git pull
~ git branch -b feature/nieuwe-modelpagina-208
~ git checkout feature/nieuwe-modelpagina-208
// lekker nieuwe modelpagina.html maken
~ git add modelpagina.html
~ git commit -m “Nieuwe modelpagina van de 208”

27. Wijziging op acceptatie zetten...
~ cd projectmapje-met-git-feature
// dus de map met die nieuwe modelpagina.html
~ git checkout develop
~ git merge feature/nieuwe-modelpagina-208
~ git push origin develop

28. Onze werkwijze
Git + Cloud + Deployments

29. Git + Cloud + Deployments
Ieder project een eigen git repository
Git repositories in de cloud bij Beanstalk
Iedereen heeft Beanstalk als remote (of origin)
Iedereen pusht uiteindelijk naar Beanstalk
Beanstalk kan branch-specifiek deployen

30. Git + Cloud + Deployments
Beanstalk Hostingplatform
Laptop Karel (clone)
git push
Laptop Kees (clone)
git push
deployment

31. Demo time!
command-line uiteraard :-p

32. Tools
Windows
Git installeren
Git Bash
PHPStorm
SourceTree
Mac
Git standaard
Command-line
PHPStorm
SourceTree

34. Best practices
1. Commit Related Changes
2. Commit Often
3. Don’t Commit Half-Done Work
4. Test Before You Commit
5. Write Good Commit Messages
6. Use Branches
7. Agree on a Workflow
Bron en uitleg: http://www.git-tower.com/learn/ebook/command-line/appendix/best-practices

35. Interessante links
● https://try.github.io/levels/1/challenges/1
● http://nvie.com/posts/a-successful-git-branching-model/
● http://git-scm.com/book/en/v2
● http://www.git-tower.com/learn/ebook/command-
line/appendix/best-practices

36. Vragen?