Pull Requests - And why they're so awesome!

An explanation about Pull Requests used at Oi Internet for all projects (Development/Infraestructure) and what advantages we'll have by using them.

Transcript

1. Pull Requests And why they're so awesome!
2. Who am I? @RafaellLycan
3. Pull Requests.! PR's let you tell others about changes you've pushed to a Git repository.
4. Pull Requests.! Once a PR is sent, interested parties can review the changes and discuss.
5. Why should we? Collaboration, Insights, Safety and History.
6. remote! (origin) Froddo Luke Jill
7. Time to MERGE!
9. Feature Branch And why you should love them!
10. Branching! & Merging Strategy
11. master! and development
12. feature! release! hotfix
13. Branching Parallel development, multiple releases
14. master cart-rules new-payment-gateway
15. Golden Rules: - New branch must be created from master.! - Don’t merge the feature until is complete. - When you finish your feature, delete the branch.
16. Master Rule: The master branch is the production branch.
17. Commit Messages Why commit messages care?
18. - Must tell us a history about the code. - The message must make sense. - The message must be clear. Commit Messages
19. Golden Rule: Think that supposedly does this commit?
20. • Why is this change necessary? • How does it address the issue? • What side effects does this change have?
21. Pull Request! + Code Review
22. Golden Rule: Your PR should be like a good documentation.
23. ## What's this PR do?! A few sentences describing the overall goals of the pull request's commits.! ## What are the relevant tickets? (if exists)! [A1534](http://example.com/tickets/A1534)! ## Main changes:! - Some change which is important to cite here.! - Another change which is important to cite too.! ! A big and long description or explanation about some change, 
 like database schema, or other stuff which is very important 
 to describe as a documentation of software it shoudn't be as technical debit.! ! ## CC Trust (if necessary)! @username, @otherename https://confluence.oiinternet.corp/display/DEV/Pull+Request+Template
24. Golden Rule: Other people should evaluate your PR.
27. MASTER PULL
 REQUEST FEATURE! BRANCH
28. DEPLOY REVIEW BUILD
29. Golden Rule: Each merged PR must have a tag.
30. master feature 1.4.0
31. Hotfix.! A hotfix is a fix to be done under production.
32. master hotfix 1.4.0 1.4.1
33. Keep it Simple.! Without the dev branch we have less drama to worry about.
34. No dev branch.! You'll make your release candidate (RC) as a new version.
35. RC Branchs: Tested; Implemented; Delete.
36. Thanks!