class: title, center, middle # Pull Requests --- # What's a PR? - Final step in a git-based workflow - You've got a branch - I've got a branch - We both want to merge into `master` - Checkpoint for quality control - Mechanism for review and approval by your colleagues - Automated testing (Continuous Integration) - Also called **Merge Requests (MRs)** --- # Why? - This is how you ship, deliver, release your work - If it's never merged, did you really do it? - You _cannot_ merge code that is not approved - Your PR is your _opportunity_ to make the argument that your code _should_ be merged - It's not a chore, it's a powerful tool! --- .left-column-33[ ### Description
] .right-column-66[ .left-column[ ### CI
] .right-column[ ### Review
] ] --- # We've got a [guide](https://github.com/fishtown-analytics/corp/blob/master/git-guide.md) for that Pull requests should: - Tackle a single functional grouping of work. - Include a description that explains the context of the changes to the code, as well as what the code does. It's useful to include links to relevant cards/tickets, other PRs, dbt docs, and screenshots of updated DAGs. - Explain in detail any breaking changes after merging this code in production, or what needs to be done to merge the code successfully. - Show a "green" passing CI build, or explain any failing tests. You can create _templates_ for pull request descriptions that will serve as helpful guides to future contributors!* --- # In progress? - WIP PRs can be nice ways to share, collaborate, and comment on code, even if it's not merge-ready - Some hosting platforms / organizations have **draft** pull requests enabled - Others adopt a naming convention: "WIP" or "DO NOT MERGE" - **_Caveat:_** At present, dbt Cloud will trigger CI from _all_ new commits pushed to an open PR (draft or otherwise) ??? The dbt Cloud trigger is something we're thinking about changing! --- # No code yet? If you... - find a bug - have an idea for an improvement - want to share some long-term thinking ### _Open an [issue](https://guides.github.com/features/issues/)!_ Things break and people have ideas all the time. If you get into a habit now of communicating bugs, problems, and in-progress work to your colleagues early and often, you'll thank yourself later.