Updated .gitignore section

git-primer.tex

@@ -261,8 +261,59 @@ We haven't made any commits yet, though. All we have are files in our working di
 
 Before you stage files, though, it's a good idea to examine the status of your project. The command for that is \texttt{git status}.
 
-\todo[inline]{Add information about git status.}
-\todo[inline]{Add information about \texttt{.gitignore}.}
+\section{Examining the Status of Your Project}
+
+Running Git status is pretty simple. It's just: 
+
+\input{include/status}
+
+The status command is going to tell you three very important things:
+
+\begin{enumerate}
+\item How your current branch relates to your remote branch (if it exists).
+\item Changed files that you have already added to a commit.
+\item Untracked files that you have not yet added to a commit.
+\end{enumerate}
+
+A typical output from \texttt{git status} might look something like this:
+
+\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{Typical Output from git status}]
+On branch main
+Your branch is up to date with 'ogit/main'.
+
+Changes to be committed:
+  (use "git restore --staged <file>..." to unstage)
+	modified:   file1.txt
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+	file2.txt
+	file3.txt
+\end{Verbatim}
+
+The first two lines indicate that so far, nobody has made changes to your remote repository (if you have one). This is typical if you are the only person working on this project, but you may see something different if other people have pushed changes to the remote. We'll talk about this later. 
+
+It then shows files that you have stages under the ``Changes to be comitted:'' list. Notice that if you have committed a file accidentally (which can happen if you are using wildcards), Git is nice and provide the command you need to reverse that change.
+
+Finally, it shows you \textit{untracked} files. In other words, these are files that have been created or edited since the last commit, but have not yet been added to a new commit.
+
+\section{Ignoring Certain Files}
+
+Suppose that you have files in your repository that you \textit{don't} want Git to keep track of. Perhaps they are just notes to yourself that you will later delete, or some test files will not be a permanent part of this project. In such a case, we can use an ignore file to tell Git to not worry about those files. 
+
+The ignore file is an invisible file named \texttt{.gitignore} in your working directory. It's invisible, so it has to start with a period.
+
+You can list individual files, or you can use wildcards to match multiple files. For example:
+
+\begin{itemize}[noitemsep]
+\item An asterisk (\texttt{*}) will match any number of characters except a forward slash. Using \texttt{*.ps} will cause Git to ignore any files that have a \texttt{.ps} extension.
+\item A question mark (\texttt{?} will match a single character except a forward slash. Using \texttt{fo?.txt} will cause Git to ignore both \texttt{foa.txt} and \texttt{fob.txt}, but not \texttt{fogg.txt}.
+\item A forward slash (\texttt{/}) serves as a directory separator. Using \texttt{foo/} will cause Git to ignore all the files in the \texttt{foo} directory.
+\item Blank lines don't match anything, so you can use them as separators for visibility.
+\item Any line starting with a \texttt{\#} is a comment, so you can remind yourself of why you are ignoring something.
+\end{itemize}
+
+\section{Committing Stages Files}
 
 Now that you've added your files, they are considered to be \textit{staged}, which means that they are ready to commit. You can make a commit now, or you can modify or create new files, and then add them as well. The choice is yours—Git doesn't penalize you either way. Personally, I prefer to make many smaller commits to avoid losing data (and metadata).
 
@@ -396,8 +447,10 @@ If you visit that original repository that I cloned on GitHub, you'll see that i
 
 As we can see from this example, you can have multiple remotes. I can create a remote repository on GitHub, clone it to my local machine, then create a remote somewhere else and add that remote to my local repo. To keep both remotes up to date with local changes, you'll need to push twice, once with \texttt{git push remote1 main} and again with \texttt{git push remote2 main}.
 
+\todo[inline]{Add information about changes to remote repos by other people (See "git status" in "local repositories".}
 
-\chapter{Collaborating With Yourself}
+
+\chapter{Collaborating With Yourself — A Guide for Creatives}
 
 I mentioned earlier that you could use Git if you're a writer to keep track of changes to projects, provided you were willing to work with text files. My goal here is to provide a basic workflow for doing that. I'm going to assume a few things: