Uses of branching

git-primer.tex

@@ -736,11 +736,8 @@ git push <remote_name> --delete <branch_name>
 \end{Verbatim}
 
 
-
 \section{Other Notes about Branching}
 
-\todo[inline]{Add information about directory contents in the different branches}
-
 Note that what you see in your directory (both in a text editor and in your GUI) will depend upon which branch you have checked out. For example, in our branching example, we will first check out the \texttt{main} branch and then do a file listing:
 
 \input{include/gitcheckoutmain&ls}
@@ -773,11 +770,23 @@ Again, here's a screen capture of our online version, which should resemble what
 \frame{\includegraphics[scale=0.75]{gitea-checkout-testbranch}}
 
 
-
 \section{Uses of Branching}
 
-\todo[inline]{Add notes about uses in technical writing, creative writing}
+It's fairly easy to see how branching can be useful when you're writing code, because it allows you to experiment without worrying about introducing errors into your main body of code. But branching is also useful for purposes other than writing code. Let's look at a couple of those.
 
+\subsection{Technical Writing}
+
+For better or for worse, most technical writing—standard operating procedures, work instructions, etc.—gets done in Microsoft Word. Word has the advantage that most companies already have a license for it and also that most people can easily understand its visual interface. The major problem with word is that formatting is always an issue. You can use and adapt the built-in paragraph and character styles, but unless everyone in your company who is responsible for writing documents understands how paragraph and character styles work, and even if they do, there is no guarantee that they will use whatever defaults you have set up the way they were intended.
+
+The biggest problem, though, is that Microsoft Word is not easy to use for experimentation.\footnote{It does have a ``Track Changes'' feature, but that means that you are experimenting in your original document, or you have to create an experimental document that you later use to overwrite your original document.} A far better option for technical writing is to use a text-based editor and compiler, such as \LaTeX{}\footnote{See \kref{https://www.latex-project.org/}{https://www.latex-project.org/}.} or DITA\footnote{The Darwin Information Typing Architecture; see \kref{https://dita-lang.org/}{https://dita-lang.org/} for more information.}. Both of these technologies use plain text files to create documents (\texttt{.tex} and \texttt{.xml} files, respectively) and so are easy to track through Git.
+
+Because they are text-based documentation systems, updating work instructions or standard operating procedures is a simple matter of creating a new branch to create and perfect that update. When you get to a point where everybody (production, QA/QC, management, et al.) is satisfied with the update, all that's needed to update the current document is to return to the main branch and merge that experimental branch. If you are using an online repository, you can also issue a new release which shows that this is the latest version of your document. 
+
+It's even possible to have different teams work on their own versions of an update by each creating their own branch. You can then decide which parts of each branch you want to incorporate into the new branch.
+
+\subsection{Creative Writing}
+
+``What if?'' is the big question behind most fiction. If you are a creative writer and are using plain text files to write your drafts\footnote{And you should, really. Working in plain text files means that you have to focus on your story in a mostly distraction free environment. All the text decoration can come later.} Working in a branch allows you to experiment with a story's structure to your heart's content without having to worry about whether you are going to create a mess of your main story outline.
 
 
 \chapter{Collaborating With Yourself — A Guide for Creatives}