<commit_before># Pull Requests, code review, and the GitHub Flow

Pull Requests are one of most essential workflow pieces of modern application development. If used effectively with proper code review and your existing workflow, they can not only help increase over-all speed of development, but the quality of the code as well.

We'll start out by looking at what makes a pull request great, and what barriers people have with sending and receiving them. Next, we'll remove some of those barriers by discussing code review best practices to ensure the code we're writing is well written and well tested. Lastly, we'll see how and why these pieces are a crucial part of a proper workflow, and what advantages the GitHub Flow has.


## Notes
- [Breaking through with continuous integration]( https://www.atlassian.com/agile/continuous-integration)
- [Why code reviews matter
(and actually save time!)](https://www.atlassian.com/agile/code-reviews)
- [When to do code reveiws when doing CI](http://programmers.stackexchange.com/questions/121664/when-to-do-code-reviews-when-doing-continuous-integration)
- [Wait For It: Determinants of Pull Request Latency on GitHub](https://bvasiles.github.io/papers/msr15.pdf)
- [Why You Should Use Continuous Integration and Continuous Deployment](http://blog.teamtreehouse.com/use-continuous-integration-continuous-deployment)
  - _It’s too easy for us as developers to say that a specific change won’t break something and later realise it did break the app. Often we are simply too lazy to really run all of our tests. This is where an automated system that runs or tests whenever we do any changes continuously can help us from falling into the trap._<commit_msg>gramatical fixes<commit_after># Pull Requests, code review, and the GitHub Flow

Pull Requests are one of most essential workflow pieces of modern application development. If used effectively with proper code review and your existing workflow, they can not only help increase overall speed of development, but the quality of the code as well.

We'll start out by looking at what makes a great pull request, and what barriers people have with sending and receiving them. Next, we'll remove some of those barriers by discussing code review best practices to ensure the code we're writing is well written and well tested. Lastly, we'll see how and why these pieces are a crucial part of a proper workflow, and what advantages the GitHub Flow has.


## Notes
- [Breaking through with continuous integration]( https://www.atlassian.com/agile/continuous-integration)
- [Why code reviews matter
(and actually save time!)](https://www.atlassian.com/agile/code-reviews)
- [When to do code reviews when doing CI](http://programmers.stackexchange.com/questions/121664/when-to-do-code-reviews-when-doing-continuous-integration)
- [Wait For It: Determinants of Pull Request Latency on GitHub](https://bvasiles.github.io/papers/msr15.pdf)
- [Why You Should Use Continuous Integration and Continuous Deployment](http://blog.teamtreehouse.com/use-continuous-integration-continuous-deployment)
  - _It’s too easy for us as developers to say that a specific change won’t break something and later realise it did break the app. Often we are simply too lazy to really run all of our tests. This is where an automated system that runs or tests whenever we do any changes continuously can help us from falling into the trap._
{'fraction_non_alphanumeric': 0.06374853113983549, 'fraction_numerical': 0.004700352526439483, 'mean_word_length': 4.7419898819561555, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 6, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2114256', 'n_tokens_mistral': 893, 'n_tokens_neox': 825, 'n_words': 448}