Organises presentation some more

This commit is contained in:
Jonathan Hodgson 2020-08-06 15:05:37 +01:00
parent 3124da5b30
commit 5b14dc3e47

View file

@ -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}