added youtube link and typo fixes

content/alternative-branching-models/index.md

@@ -13,7 +13,7 @@ weight: 101
 
 ### GitHub flow
 
-This is sooooo close to PR-centric Trunk-Based Development. Why? Because it is a branching model that has individual
+This is very close to PR-centric Trunk-Based Development. Why? Because it is a branching model that has individual
 developers active concurrently in more than one (short-lived) branch (or fork). Or developer pairs, rather than
 individuals.
 

content/branch-by-abstraction/index.md

@@ -33,8 +33,8 @@ break the build.
 4. Remove the to-be-replaced implementation
 5. Remove the abstraction
 
-Hopefully, your team uses an IDE that can perform complex refactorings on sets on checkouts, in a way that running the build 
-after each is an uneventful validation of the refactorings.
+Hopefully, your team uses an IDE that can perform complex refactoring on sets of checkouts, in a way that running the build 
+after each is an uneventful validation of the changes.
 
 ## Contrived example
 

content/branch-for-release/index.md

@@ -29,7 +29,7 @@ roll-forward strategy for solving it, meaning the fix for a bug is in the trunk,
 ## Who is committing where?
 
 Developers are committing (green dots) at the highest throughput rate to the trunk, and do not slow up or freeze around a
-branch-cut or with proximity to a release. Developers as a group are **not** commiting to the release branch (see below).
+branch-cut or with proximity to a release. Developers as a group are **not** committing to the release branch (see below).
 
 ![](branch_for_release2.png)
 ([key](/key/))
@@ -45,7 +45,7 @@ That red dot is an accidental build break that was fixed (somehow) soon after.
 Some teams [release from a tag on the trunk](/release-from-trunk/) and do not create a branch at that time. That in
 itself is **an alternate practice to this one, "branch for release"**.
 
-Those teams wait for a bug that needs fixing for a released, before creating a branch from the release tag (if they are
+Those teams wait for a bug that needs fixing for a release, before creating a branch from the release tag (if they are
 not going to just issue another release from the trunk).  
 
 Brad Appleton points out that many do not realize that branches can be created **retroactively**. That is taken advantage
@@ -82,16 +82,11 @@ everything mentioned above, but understand you have introduced risk of regressio
 
 ### Google's Rachel Potvin on Cherry picks
 
-In a talk at the @Scale conference in Sept 2015, "Why Google Stores Billions of Lines of Code in a Single Repository",
-there was a slide that depicts cherry-picks in a branch diagram:
+In a talk at the **@Scale** conference in Sept. 2015, _"Why Google Stores Billions of Lines of Code in a Single Repository"_, Rachel Potvin detailed Google's use of cherry-picking.
 
-![](atscale.png)
+[![](atscale_youtube_frame.png)](https://youtu.be/W71BTkUbdqE?t=868)
 
-The presenter, Rachel Potvin, said (14 mins in):
-
-"So at Google we do what's called Trunk-Based Development. I should note that it is the combination of Trunk-Based Development with a centralized repository that really defines the monolithic model of source code management. So
-what Trunk-Based Development means for us that typically Piper users all work from HEAD or a single copy of the most recent version of the codebase. When developers commit to Piper their changes are immediately visible and usable by other engineers. Branching for development at Google is exceedingly rare and Trunk-Based Development is beneficial partly because you avoid the painful merges that often occur when you need to reconcile long lived branches.  Branches however are used for releases. **So a release branch is typically a snapshot from trunk with an 
-optional number of cherry picks that are developed on trunk and then pulled into the branch**."
+> _"So at Google we do what's called Trunk-Based Development. I should note that it is the combination of Trunk-Based Development with a centralized repository that really defines the monolithic model of source code management. So what Trunk-Based Development means for us that typically Piper users all work from HEAD or a single copy of the most recent version of the codebase. When developers commit to Piper their changes are immediately visible and usable by other engineers. Branching for development at Google is exceedingly rare and Trunk-Based Development is beneficial partly because you avoid the painful merges that often occur when you need to reconcile long lived branches.  Branches however are used for releases. **So a release branch is typically a snapshot from trunk with an optional number of cherry picks that are developed on trunk and then pulled into the branch**."_
 
 We've bolded the cherry-pick bit ourselves.  Readers with beady eyes will note that Rachel alludes to 
 dev branches other than trunk for 'rare' reasons. We may cheekily suggest that Google should learn a little more about [Branch by Abstraction](/branch-by-abstraction/).
@@ -120,9 +115,9 @@ is retroactively created from that tag, and the patch release (see above) can ha
 
 ## Release branch deletion
 
-Release branches are deleted some time after release activity from them ceases. Not immediately, but when it is clear release is no longer in production. Release branches are NOT merged back into trunk.
+Release branches are deleted some time after release activity from them ceases. Not immediately, but when it is clear release is no longer in production. Release branches are **not** merged back into trunk.
 That is usually when releases from succeeding release branches have gone live. This is a
-harmless tidying activity - branches can be undeleted again easily enough in all VCS choices. In git, a tag needs to be created from the released commit before deleting the release branch, since dangling commits will be garbage collected.
+harmless tidying activity - branches can be restored easily enough in all VCS choices. In git, a tag needs to be created from the released commit before deleting the release branch, since dangling commits will be garbage collected.
 
 # References elsewhere
 

content/committing-straight-to-the-trunk/index.md

@@ -38,7 +38,7 @@ If this is locked in as a team requirement, your new challenge is to keep the fu
 
 Some teams have revert policies for commits that land in trunk/master that are proven as "broken" later in CI. That could be an activity for a build-cop who's going to communicate with the dev team about locking the trunk to achieve that. Or it could be a bot activity and happen instantly, as Google do in-house (35K committers in one trunk).
 
-Some teams have some scripting in place to ensure that developers only pull/sync commits to their dev-workstations that CI has marked as passing. That could be as simple as keeping a commit ID (number or hash depending on your VCS tool) on a website somewhere, and writing a wrapper script for git-pull (or svn up) that ignores commits that happened after that one. Pushing back, with that way of working is harder in Git and Mercurial as they requires you to have pulled HEAD revison before you can push back. Subversion and Perforce don't have that limitation.
+Some teams have some scripting in place to ensure that developers only pull/sync commits to their dev-workstations that CI has marked as passing. That could be as simple as keeping a commit ID (number or hash depending on your VCS tool) on a website somewhere, and writing a wrapper script for git-pull (or svn up) that ignores commits that happened after that one. Pushing back, with that way of working is harder in Git and Mercurial as they require you to have pulled HEAD revisions before you can push back. Subversion and Perforce don't have that limitation.
 
 # Alternatives to committing straight to the trunk