Downloaded 17 times
Uploaded byMahmoud Masih Tehrani
Agile team workflow
The document provides an overview of Git, a distributed version control system created by Linus Torvalds, including its benefits and common misconceptions about its complexity. It discusses various Git workflows, branching models, best practices for code commits, and the importance of code review and testing. Additionally, it emphasizes effective usage tips and resources for learning Git.
More Related Content
Agile team workflow
- 1. Agile team workflow MahmoudMasih Tehrani Coderconf3
- 2. Mahmoud Masih Tehrani Php& Golang developer about 10 years use GNU/Linux I love Nature ,Sport ,Theatre ,Free Software & Programing Username : mahm0ud or mahm0ud22 Email: mahmud.tehrani@gmail.com
- 3. Git What is it?Git is a free and open source distributed version control system created by Linus Torvalds in 2005 ( Who is also the creator of Linux kernel ). It is designed to manage everything for small or very large projects with speed and efficiency. Majors organisations like Google, Facebook, Microsoft uses GIT daily.
- 4. But, It’s toocomplicated! Most of the developer who doesn’t use git or using git very little, they came up saying, “Git is too complicated. It’s too hard to learn. I don’t really understand it.” Actually, Git is very easy to use and learn and especially considering how powerful it is! If you can have the basic understanding of git flow, it’ll be a life saviour for YOU.
- 5. A successful Gitbranching model First post about git workflow in 2010 By Vincent Driessen
- 6. What’s the best workflow differentteam + different cultural + different product = git workflow
- 7. Design your ownworkflows issue issue issue issue Our codeIssues
- 8.
- 9. Another code freeze Idledeveloper
- 11.
- 12.
- 13. Git Workflow model Featurebranching Release branching Hot fix branching
- 14. Feature branching Feature AFeature B Feature C Feature D Issues
- 15. gitlab merge requestOR github pull request
- 16.
- 17.
- 18.
- 19. Tagging Versions(Semantic) MAJOR.MINOR.PATCH 1. MAJORversion when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. tıps for gitbranching model efficient usage of git
- 26. Learn git CommandLine by heart, stop using GUI
- 27. Only few peopleshould be authorize for merging development branch to master branch
- 28. ensure that alltests are passing before pushing to upstream
- 29. do not pushhalf-baked, untested, incomplete, not-compiling, to-be-fixed, not-ready-to-deploy code to git push code. If commit it use write flag WIP !
- 30. Never use --m <message> flag to git commit and Follow Commit message best practices characters or less. That is summary. • First line is 50line • Then a blank text should be wrapped at 72 characters. • Remaining description That is detailed
- 31. Branch naming Issue title Issueid number Issue type/issue number/description
- 32. Squash commits ofbug fix into one and exactly one commit that completely represents that bug fix
- 33. Squash commits ofyour completed story into one commit before pushing to upstream One Task One commit One pull request Please use Commit - - amend
- 34. Use .gitıgnore inorder not to send irrelevant files never push IDE files or package or binary or temp files
- 35. Forking a repositoryallows you to freely experiment with changes without affecting the original project.
- 36. Git pull upstreammaster - -rebase
- 37. do not resetwithout stashing or committing & tagging
- 38. references • A successfulGit branching model http://nvie.com/posts/a-successful- git-branching-model/ • Understanding the GitHub Flow https://guides.github.com/introduction/ flow/ • Gitlab workflow https://about.gitlab.com/2014/09/29/gitlab-flow/ • Comparing workflow https://www.atlassian.com/git/tutorials/ comparing-workflows • Semantic Versioning http://semver.org/
- 39.