Organises presentation some more

main.latex

@@ -21,8 +21,6 @@
 \tikzstyle{branch} = [ellipse, text centered, text=green]
 \tikzstyle{arrow} = [thick, <-, draw=blue]
 
-
-
 \usepackage{dirtree}
 \usepackage{csquotes}
 %\usepackage{gitdags}
@@ -87,7 +85,6 @@
 	}
 }
 
-
 \begin{frame}
 	\frametitle{What is Git}
 
@@ -100,9 +97,9 @@
 	\end{itemize}
 
 	\note{%
-		Git is still being developed.
 
-		Being distributed means you can work on repositories offline (Unlike SVN).
+		It keeps track by maintaining a series of snapshots containing all of the files and folders
+		at each point.
 
 		It's useful even if you're working on things by your self. This presentation is version
 		controlled.
@@ -110,6 +107,8 @@
 		You can use it to find out when something broke. I won't be covering it today but there is a
 		tool called git bisect that can take a unit test (or script) to analyse when something broke
 		using a binary search.
+
+		Being distributed means you can work on repositories offline (Unlike SVN).
 	}
 \end{frame}
 
@@ -128,6 +127,151 @@
 	}
 \end{frame}
 
+\begin{frame}
+	\frametitle{Naïve Approach}
+	\begin{columns}
+		\begin{column}{0.5\textwidth}
+			\dirtree{%
+				.1 Project.
+				.2 draft.
+				.3 some.
+				.3 files.
+				.2 final-draft.
+				.3 some.
+				.3 files.
+				.2 final.
+				.3 some.
+				.3 files.
+			}
+		\end{column}
+		\begin{column}{0.5\textwidth}
+			\textbf{Pros}
+			\begin{itemize}
+				\item Simple
+				\item No dependencies
+				\item No Learning curve
+			\end{itemize}
+			\vspace{1em}
+			\textbf{Cons}
+			\begin{itemize}
+				\item Difficult to collaborate
+				\item Lot's of wasted disk space
+				\item Hard to find particular versions of files
+			\end{itemize}
+		\end{column}
+	\end{columns}
+	\note{%
+		There are many approaches you could take to version control
+
+		I think, being honest, we have all done this. This sort of works, if you're working on
+		something by yourself. Once you start collaborating on software, you are going to have a bad
+		time.
+
+		You could add time stamps and zip up changes when you need to collaborate.
+
+		Git has a well thought out model that allows us to address these problems.
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Files and Folders}
+
+	\textbf{Blob} In Git, a file is called a blob.
+
+	\textbf{Tree} In Git, a directory is called a tree.
+
+	
+	\note{%
+		Git needs a way of modeling files and folders in a file system independent way.
+
+		These concepts are pretty familiar. A tree can contain other trees or blobs.
+
+	}
+\end{frame}
+
+
+\begin{frame}
+	\frametitle{Commits}
+	\framesubtitle{(Snapshots)}
+	\begin{center}
+		\begin{tikzpicture}
+		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
+		%\node at (-2.5,0) {master};
+		\node[commit,minimum size=2cm] at (0,0) (commit1) {Draft};
+		\node[commit,minimum size=2cm] at (3,0) (commit2) {Final Draft};
+		\node[commit,minimum size=2cm,draw=red] at (6,0) (commit3) {Final};
+		\draw[arrow] (commit1) -- (commit2);
+		\draw[arrow] (commit2) -- (commit3);
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] Draft };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] Final Draft };
+	\end{tikzpicture}
+	\end{center}
+	\note{%
+		\begin{itemize}
+			\item We could then think of history as a linear series of snapshots.
+			\item Each circle here represents a snapshot.
+			\item The previous snapshot is referenced somewhere in each snapshot.
+			\item We then just need to record the most recent version somewhere.
+		\end{itemize}
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Commits}
+	\begin{center}
+		\begin{tikzpicture}
+		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
+		%\node at (-2.5,0) {master};
+		\node[commit] at (0,0) (commit1) {93e4d3d\ldots};
+		\node[commit] at (3,0) (commit2) {2557962\ldots};
+		\node[commit,draw=red] at (6,0) (commit3) {od68560\ldots};
+		\draw[arrow] (commit1) -- (commit2);
+		\draw[arrow] (commit2) -- (commit3);
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] 93e4d3d\ldots };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] 2557962\ldots };
+	\end{tikzpicture}
+	\end{center}
+	\note{%
+		\begin{itemize}
+			\item Rather than human readable names, Git references each snapshot (called a commit)
+				by a cryptographic hash. Currently using a hardened sha1 but there is an effort to
+				move to sha256.
+			\item Similarly to the model above, each commit references the previous (except the
+				first obviously)
+			\item The commit also includes meta information such as the committer, a timestamp and a
+				message.
+			\item We will look at this in more detail a bit later.
+		\end{itemize}
+
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Staging Area}
+	\begin{itemize}
+		\item Sometimes called the git index
+		\item An intermediate area in which you can pick files to be included in the next commit.
+		\item Also allows you to exclude some files from your version history.
+			\begin{itemize}
+				\item Log files
+				\item Binary files
+				\item Minified files
+			\end{itemize}
+	\end{itemize}
+	\note{%
+		This is the last thing before we start actually doing stuff (promise).
+
+		This is particularly useful if you have multiple logically unrelated changes and want to
+		make separate snapshots for each.
+
+		Also useful if when programming you write your tests along side your code, you would
+		normally want those to be separate snapshots.
+
+		We will talk about .gitignore later which is another way of ignoring files
+	}
+\end{frame}
 
 \begin{frame}[fragile]
 	\frametitle{Install}
@@ -214,132 +358,6 @@
 	}
 \end{frame}
 
-\begin{frame}
-	\frametitle{Terminology}
-	\framesubtitle{Objects}
-
-	\textbf{Blob} In Git, a file is called a blob.
-
-	\textbf{Tree} In Git, a directory is called a tree.
-
-	\textbf{Commit} A snapshot of your code
-
-	% All of these are referenced by a hash and stored in the \mintinline{bash}{.git/objects/}
-	% directory.
-	
-	\note{%
-		Technically, a blob is kind of like an inode on the file system so also represents symbolic
-		links.
-
-		There are some other types such as submodules but I won't be addressing them in this
-		presentation.
-	}
-\end{frame}
-
-
-\begin{frame}
-	\frametitle{Naïve Approach}
-	\begin{columns}
-		\begin{column}{0.5\textwidth}
-			\dirtree{%
-				.1 Project.
-				.2 draft.
-				.3 some.
-				.3 files.
-				.2 final-draft.
-				.3 some.
-				.3 files.
-				.2 final.
-				.3 some.
-				.3 files.
-			}
-		\end{column}
-		\begin{column}{0.5\textwidth}
-			\textbf{Pros}
-			\begin{itemize}
-				\item Simple
-				\item No dependencies
-				\item No Learning curve
-			\end{itemize}
-			\vspace{1em}
-			\textbf{Cons}
-			\begin{itemize}
-				\item Difficult to collaborate
-				\item Lot's of wasted disk space
-				\item Can be difficult to work out chronological order
-			\end{itemize}
-		\end{column}
-	\end{columns}
-	\note{%
-		I think, being honest, we have all done this. This sort of works, if you're working on
-		something by yourself. Once you start collaborating on software, you are going to have a bad
-		time.
-
-		However, this is a simple approach and not a million miles from what Git does internally.
-	}
-\end{frame}
-
-
-\begin{frame}
-	\frametitle{Improve it}
-	\begin{center}
-		\begin{tikzpicture}
-		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
-		%\node at (-2.5,0) {master};
-		\node[commit,minimum size=2cm] at (0,0) (commit1) {Draft};
-		\node[commit,minimum size=2cm] at (3,0) (commit2) {Final Draft};
-		\node[commit,minimum size=2cm,draw=red] at (6,0) (commit3) {Final};
-		\draw[arrow] (commit1) -- (commit2);
-		\draw[arrow] (commit2) -- (commit3);
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] Draft };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] Final Draft };
-	\end{tikzpicture}
-	\end{center}
-	\note{%
-		\begin{itemize}
-			\item This is a simple representation of the folder structure we saw.
-			\item Notice that so the computer knows the order, somewhere in each ``snapshot", we
-				include a reference to the previous snapshot.
-			\item This is stored along side other metadata such as a timestamp and the person
-				taking the snapshot.
-			\item We then just need to record the most recent version somewhere.
-		\end{itemize}
-	}
-\end{frame}
-
-\begin{frame}
-	\frametitle{Commits}
-	\begin{center}
-		\begin{tikzpicture}
-		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
-		%\node at (-2.5,0) {master};
-		\node[commit] at (0,0) (commit1) {93e4d3d\ldots};
-		\node[commit] at (3,0) (commit2) {2557962\ldots};
-		\node[commit,draw=red] at (6,0) (commit3) {od68560\ldots};
-		\draw[arrow] (commit1) -- (commit2);
-		\draw[arrow] (commit2) -- (commit3);
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] 93e4d3d\ldots };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] 2557962\ldots };
-	\end{tikzpicture}
-	\end{center}
-	\note{%
-		\begin{itemize}
-			\item Rather than human readable names, Git references each snapshot (called a commit)
-				by a cryptographic hash. Currently using a hardened sha1 but there is an effort to
-				move to sha256.
-			\item Similarly to the model above, each commit references the previous (except the
-				first obviously)
-			\item The commit also includes meta information such as the committer, a timestamp and a
-				message.
-			\item We will look at this in more detail a bit later.
-		\end{itemize}
-
-	}
-\end{frame}
-
-
 \begin{frame}
 	\frametitle{Create a repository}
 	\begin{center}
@@ -377,14 +395,6 @@
 		git add -A
 	\end{minted}
 	\note{%
-		The staging area is where you put things that you want to be committed.
-
-		It can often be useful to manually split changes up into different commits. You might be
-		working on feature A and feature B simultaneously. It is good practice to have each feature
-		as a separate commit so you could add feature A to the staging area, commit it, then do the
-		same for feature B.
-
-		We will talk about \mintinline{bash}{.gitignore} in a bit.
 	}
 \end{frame}
 
@@ -401,11 +411,8 @@
 	}
 \end{frame}
 
-\begin{frame}[fragile]
+\begin{frame}
 	\frametitle{Committing}
-	\begin{minted}{bash}
-		git commit
-	\end{minted}
 
 	\begin{itemize}
 		\item First line should be concise summary around 50 chars
@@ -1008,6 +1015,52 @@
 	}
 \end{frame}
 
+\begin{frame}
+	\frametitle{Issues}
+	\begin{itemize}
+		\item Not part of Git, rather something most Git hosting providers offer.
+		\item You can normally reference issues in commit messages using \# symbol.
+	\end{itemize}
+	\note{%
+		Demonstrate this in a browser using Github
+	}
+	
+\end{frame}
+
+\begin{frame}
+	\frametitle{Pull Requests}
+	\framesubtitle{Merge Requests}
+
+	\begin{enumerate}
+		\item Fork
+		\item Clone
+		\item Branch
+		\item Commit
+		\item Push
+	\end{enumerate}
+	
+	\note{%
+		\begin{itemize}
+			\item Not part of Git, rather something most Git hosting providers offer.
+			\item It allows for people to contribute code to repositories that they don't have
+				write access to
+		\end{itemize}
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Useful supporting tools}
+	\framesubtitle{Shell Integration}
+	Git ships with completion for bash, zsh and tcsh. You may need to source it in the relevant rc
+	file.
+
+	Prompt customisation is available out of the box for bash and zsh.
+	\note{%
+		If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than
+		Bash's.
+	}
+\end{frame}
+
 \begin{frame}
 	\frametitle{Useful supporting tools}
 	\framesubtitle{Bat}
@@ -1045,18 +1098,6 @@
 	}
 \end{frame}
 
-\begin{frame}
-	\frametitle{Useful supporting tools}
-	\framesubtitle{Delta}
-	\begin{center}
-		\includegraphics[width=\textwidth,height=0.6\textheight,keepaspectratio]{auto-download-aHR0cHM6Ly91c2VyLWltYWdlcy5naXRodWJ1c2VyY29udGVudC5jb20vNTIyMDUvNjUyNDg1MjUtMzIyNTA0ODAtZGFlYS0xMWU5LTk5NjUtMWEwNWM2YTRiZGY0LnBuZw==.png}
-	\end{center}
-	\href{https://github.com/dandavison/delta}{https://github.com/dandavison/delta} 
-	\note{%
-		This is a tool that can make your diff output look better.
-	}
-\end{frame}
-
 \begin{frame}
 	\frametitle{Useful supporting tools}
 	\framesubtitle{BFG Repo Cleaner}
@@ -1070,19 +1111,6 @@
 	}
 \end{frame}
 
-\begin{frame}
-	\frametitle{Useful supporting tools}
-	\framesubtitle{Shell Integration}
-	Git ships with completion for bash, zsh and tcsh. You may need to source it in the relevant rc
-	file.
-
-	Prompt customisation is available out of the box for bash and zsh.
-	\note{%
-		If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than
-		Bash's.
-	}
-\end{frame}
-
 \begin{frame}
 	\frametitle{Useful supporting tools}
 	\framesubtitle{Pass}