Enterprise git
1 like553 views
The document discusses why Git is a useful version control system. It notes that Git is fast, secure, distributed, and cross-platform. It works well for both large and small teams. The document outlines some common branch naming conventions like using "master" for production, "release/*" for releases, and "feature/*" for new features. It recommends starting with best practices and choosing whatever source control works for your team.
Enterprise git
- 2. About Git...
- 3. About Git... an unpleasant or contemptible person
- 4. Why Git?
- 5. Why Git? • Fast, secure, safe, solid
- 6. Why Git? • Fast, secure, safe, solid • Great collaboration tools: built-in and from third parties
- 7. Why Git? • Fast, secure, safe, solid • Great collaboration tools: built-in and from third parties • Distributed (think offline mode, freedom to tinker)
- 8. Why Git? • Fast, secure, safe, solid • Great collaboration tools: built-in and from third parties • Distributed (think offline mode, freedom to tinker) • Cross-platform: UNIX, Mac OS X,Windows
- 9. Why Git? • Fast, secure, safe, solid • Great collaboration tools: built-in and from third parties • Distributed (think offline mode, freedom to tinker) • Cross-platform: UNIX, Mac OS X,Windows • Proven track record: Linux Kernel, KDE, X.org, KDE, Gnome,Android, Debian, Fedora, openSUSE, Mono, Perl, Ruby, Samba, PostgreSQL,Wine, and many others
- 11. Adoption challenges The devil you know....
- 13. Adoption challenges Centralized vs Distributed
- 16. Tools
- 17. Git “Server”
- 18. Git “Server” • “Server” is what you want it to be: an SSH account, a simple HTTP server, or a CGI- capable HTTP server
- 19. Git “Server” • “Server” is what you want it to be: an SSH account, a simple HTTP server, or a CGI- capable HTTP server • No centralized server built-in concept
- 20. Git “Server” • “Server” is what you want it to be: an SSH account, a simple HTTP server, or a CGI- capable HTTP server • No centralized server built-in concept • One or more repositories in well-known locations become the central repository
- 21. Git “Server” • “Server” is what you want it to be: an SSH account, a simple HTTP server, or a CGI- capable HTTP server • No centralized server built-in concept • One or more repositories in well-known locations become the central repository • Social convention wins
- 23. Centralized Git Servers Gitosis Gitolite Managed by git Managed by git + shell Maintained? Active development repo x user repo x user x branch x action
- 24. Centralized Git Servers Gitosis Gitolite Managed by git Managed by git + shell Maintained? Active development repo x user repo x user x branch x action
- 25. Centralized Git Servers Gitosis Gitolite Managed by git Managed by git + shell Maintained? Active development repo x user repo x user x branch x action
- 26. Centralized Git Servers Gitosis Gitolite Managed by git Managed by git + shell Maintained? Active development repo x user repo x user x branch x action
- 27. Git + Project Mgmt
- 28. Git + Project Mgmt • OSS • Redmine • Trac • Hosted • Github (also has in-house solution) • CodeBaseHQ
- 29. Git + Project Mgmt • OSS • Redmine • Trac • Hosted • Github (also has in-house solution) • CodeBaseHQ
- 30. Git + Project Mgmt • OSS • Redmine • Trac • Hosted • Github (also has in-house solution) • CodeBaseHQ
- 31. One final tool...
- 32. One final tool... • Hudson
- 33. One final tool... • Hudson • Continuous integration solution
- 34. One final tool... • Hudson • Continuous integration solution • Integrates very well with Git
- 35. One final tool... • Hudson • Continuous integration solution • Integrates very well with Git • Its *very* easy to install
- 36. One final tool... • Hudson • Continuous integration solution • Integrates very well with Git • Its *very* easy to install • ... and it has Chuck Norris quotes!
- 39. Common organization Developers Smoker Collaboration Production
- 41. Merge master
- 42. Merge master feature git checkout -b feature
- 44. Merge feature master git checkout master; git merge feature
- 45. Merge feature master git checkout master; git reset --hard master^ git checkout master; git reset --hard HEAD^
- 46. Merge master feature git checkout feature; git merge master
- 47. Merge feature master git checkout master; git merge feature
- 50. Rebase feature master A B C X Y Z
- 51. Rebase master A B C X Y Z X' Y' Z' feature git checkout feature; git rebase master
- 52. Rebase master A B C X Y Z X' Y' Z' feature dAX dXY dYZ dAX' dXY' dYZ'
- 53. Rebase master A B C X Y Z X' Y' Z' feature
- 54. Rebase A B C X Y Z X' Y' Z' feature master git checkout master; git merge feature
- 55. Rebase master A B C X Y Z X' Y' Z' feature
- 56. Rebase A B C X Y Z X' Y' Z' feature D master git checkout master; git merge --no-ff feature
- 57. Branch naming
- 58. git branches • Byte strings, so mixing codepages bad idea • Use directories to organize branches • feature/*, test/*, <dev_handle>/* • Think globally to minimize clashes
- 59. Project phases
- 61. Project phases • Production • Releases
- 62. Project phases • Production • Releases • Staging
- 63. Project phases • Production • Releases • Staging • Features
- 64. Project phases • Production • Releases • Staging • Features • Celsadas HotFixes
- 66. Common branch names • Everybody has a production branch: master
- 67. Common branch names • Everybody has a production branch: master • Release branches: release/*
- 68. Common branch names • Everybody has a production branch: master • Release branches: release/* • New features get a branch each: feature/*
- 69. Common branch names • Everybody has a production branch: master • Release branches: release/* • New features get a branch each: feature/* • If you have multiple developers on the same feature: feature/NAME/DEV
- 70. Common branch names • Everybody has a production branch: master • Release branches: release/* • New features get a branch each: feature/* • If you have multiple developers on the same feature: feature/NAME/DEV • If you need a “next production”: develop
- 71. Common branch names • Everybody has a production branch: master • Release branches: release/* • New features get a branch each: feature/* • If you have multiple developers on the same feature: feature/NAME/DEV • If you need a “next production”: develop • When things go wrong: hotfix/*
- 72. Conclusions
- 73. Conclusions • Git is ready for big teams
- 74. Conclusions • Git is ready for big teams • Git is also ready for small teams
- 75. Conclusions • Git is ready for big teams • Git is also ready for small teams • There is no right way...
- 76. Conclusions • Git is ready for big teams • Git is also ready for small teams • There is no right way... • ... but start with current best practices
- 77. Conclusions • Git is ready for big teams • Git is also ready for small teams • There is no right way... • ... but start with current best practices • Whatever you do, the important thing is to use a source control system
- 78. Obrigado!
- 79. Pedro Melo melo@simplicidade.org @pedromelo Questions about Git, Perl, XMPP, just find me and ask away I’ll be here the three days