Fix a few last typos (#485)

* Fix a few last typos

* TRUNK-based development, not truck

docs/5-software-development-practices/5.3.1-branching-merging.md

@@ -54,4 +54,4 @@ A branch should be created only if required. This is most applicable when delive
 Merging should happen as frequently as possible. As teams improve on creating smaller stories and engineers develop a clear way of working around pull requests, developers can merge code multiple times per day.
 ---
 
-By eliminating long-lived branches and merging smaller changes directly into a main branch, teams can reduce merge conflicts and release code quicker. This approach is known as **truck-based development**. To achieve this kind of fast-paced development, without sacrificing quality, it is important to have confidence in the quality of code being committed. This can be accomplished by including automated testing in the continuous integration process. We will cover automation and testing in more depth later in this chapter.
+By eliminating long-lived branches and merging smaller changes directly into a main branch, teams can reduce merge conflicts and release code quicker. This approach is known as **trunk-based development**. To achieve this kind of fast-paced development, without sacrificing quality, it is important to have confidence in the quality of code being committed. This can be accomplished by including automated testing in the continuous integration process. We will cover automation and testing in more depth later in this chapter.

docs/5-software-development-practices/5.5.7-code-review.md

@@ -49,15 +49,15 @@ When seeking out a reviewer, you should try to get a review from someone who is
 
 When you're reviewing code, your goal is to help find any potential defects in the code and help the developer make their code be the best it can be. This can feel pretty intimidating if you haven't done it before, but there are some things you can do to try to give structure to your review.
 
-- **Consider writing a checklist.** You could write a checklist of things you're looking for  when you're  going into a code review. This list could include things like whether or not the code is secure, if it accomplishes the task it says it's meant to, etc.
+- **Consider writing a checklist.** You could write a checklist of things you're looking for when you're  going into a code review. This list could include things like whether or not the code is secure, if it accomplishes the task it says it's meant to, etc.
 
 - **Think about if now is the right time to do a review.** Sometimes you might not be in the right headspace to do a code review. Doing a code review while you're tired or frustrated could result in you missing bugs/errors in the code, or making less than polite comments.
 
 - **Denote nitpicks.** If you have an opinion about the way a piece of code is written, feel free to share that opinion, but make sure you make it clear when you're presenting an alternative way to do something and when you're commenting on a blocking issue.
 
 ## Specific Guidelines
 
-If you're working in a small team without dedicated code review guidelines, consider taking some time to formalize your groups approach. Some good questions to ask to guide what you want your process to look like could include:
+If you're working in a small team without dedicated code review guidelines, consider taking some time to formalize your group's approach. Some good questions to ask to guide what you want your process to look like could include:
 
 - How should a developer seek out a reviewer?
 
@@ -67,9 +67,9 @@ If you're working in a small team without dedicated code review guidelines, cons
 
 - Should reviewers put forth particular code suggestions?
 
-- Who's responsibility is it to make changes to PRs that need small fixes?
+- Whose responsibility is it to make changes to PRs that need small fixes?
 
-If you're working in an organization that already has code review customs put into place, take some time to familiarize yourself  with that particular process  before reviewing code or asking for a code review.
+If you're working in an organization that already has code review customs put into place, take some time to familiarize yourself with that particular process before reviewing code or asking for a code review.
 
 ## Examples and Other Resources