|
|
@ -35,7 +35,11 @@ |
|
|
|
|
|
|
|
|
|
|
|
\usetheme{default} |
|
|
|
\usetheme{default} |
|
|
|
\beamertemplatenavigationsymbolsempty |
|
|
|
\beamertemplatenavigationsymbolsempty |
|
|
|
\hypersetup{pdfpagemode=UseNone} % don't show bookmarks on initial view |
|
|
|
\hypersetup{% |
|
|
|
|
|
|
|
colorlinks=true, |
|
|
|
|
|
|
|
urlcolor=blue, |
|
|
|
|
|
|
|
%pdfpagemode=UseNone |
|
|
|
|
|
|
|
} % don't show bookmarks on initial view |
|
|
|
|
|
|
|
|
|
|
|
%\lstset{% |
|
|
|
%\lstset{% |
|
|
|
% breaklines=true, |
|
|
|
% breaklines=true, |
|
|
@ -70,25 +74,25 @@ |
|
|
|
|
|
|
|
|
|
|
|
Microsoft recently moved to git for version controlling Windows and Office. |
|
|
|
Microsoft recently moved to git for version controlling Windows and Office. |
|
|
|
|
|
|
|
|
|
|
|
I will not be able to cover everything relating to Git, it is an incredibly powerful tool. |
|
|
|
|
|
|
|
However, hopefully I will be able to give you enough to get started and at least understand the |
|
|
|
|
|
|
|
official documentation. |
|
|
|
|
|
|
|
} |
|
|
|
} |
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame} |
|
|
|
\frametitle{Aims} |
|
|
|
\frametitle{Aims} |
|
|
|
I am obviously not going to be able to go over everything that git does. |
|
|
|
|
|
|
|
\begin{itemize} |
|
|
|
\begin{itemize} |
|
|
|
\item I don't know everything Git does |
|
|
|
\item Go through some basic operations to help you use git |
|
|
|
\item Git does LOADS of stuff |
|
|
|
\item Give you enough of a grounding to understand the official documentation |
|
|
|
\end{itemize} |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
I am obviously not going to be able to go over everything that git does because it does so much. |
|
|
|
|
|
|
|
|
|
|
|
Hopefully after this you will be able to use Git well for most day-to-day tasks. Git has very |
|
|
|
Hopefully after this you will be able to use Git well for most day-to-day tasks. Git has very |
|
|
|
compressive documentation. I hope that this will also give you enough of a background to |
|
|
|
compressive documentation. I hope that this will also give you enough of a background to |
|
|
|
understand the documentation. |
|
|
|
understand the documentation. |
|
|
|
\note{% |
|
|
|
|
|
|
|
} |
|
|
|
} |
|
|
|
\end{frame} |
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame} |
|
|
|
\frametitle{What is Git} |
|
|
|
\frametitle{What is Git} |
|
|
|
|
|
|
|
|
|
|
@ -114,6 +118,21 @@ |
|
|
|
} |
|
|
|
} |
|
|
|
\end{frame} |
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
|
|
|
|
\frametitle{What is Git} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{center} |
|
|
|
|
|
|
|
\Huge Git $\ne$ Github |
|
|
|
|
|
|
|
\end{center} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
Although the names are similar, Git and Github are separate projects. Github is a Microsoft |
|
|
|
|
|
|
|
owned, closed source company that is a remote repository for Git projects. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There are others such as Bitbucket, Gitlab, Gitea |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame} |
|
|
|
\frametitle{Obligitary XKCD Comic} |
|
|
|
\frametitle{Obligitary XKCD Comic} |
|
|
@ -159,7 +178,7 @@ can really help. |
|
|
|
git --version |
|
|
|
git --version |
|
|
|
\end{minted} |
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
|
|
\href{https://gitforwindows.org/}{Git for Windows: https://gitforwindows.org/} |
|
|
|
Git for Windows: \href{https://gitforwindows.org/}{https://gitforwindows.org/} |
|
|
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
\note{% |
|
|
|
Git is probably already installed if you are on a Linux system. However, if not, it will |
|
|
|
Git is probably already installed if you are on a Linux system. However, if not, it will |
|
|
@ -385,64 +404,6 @@ can really help. |
|
|
|
} |
|
|
|
} |
|
|
|
\end{frame} |
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
|
|
|
|
\frametitle{Commits / Branches} |
|
|
|
|
|
|
|
\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) {}; |
|
|
|
|
|
|
|
\node[commit] at (2,0) (commit2) {A}; |
|
|
|
|
|
|
|
\node[commit] at (4,0) (commit3) {B}; |
|
|
|
|
|
|
|
\node[commit] at (4,-2) (commit3b) {C}; |
|
|
|
|
|
|
|
\draw[arrow] (commit1) -- (commit2); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit3); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit3b); |
|
|
|
|
|
|
|
\end{tikzpicture} |
|
|
|
|
|
|
|
\end{center} |
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
The linear graph we just saw is an overly simplistic representation. In reality, Git |
|
|
|
|
|
|
|
represents history using a Directed acyclic graph which allows parents to be shared my |
|
|
|
|
|
|
|
multiple commits. This is useful because it allows for Branches. We will look at these a bit |
|
|
|
|
|
|
|
more later. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is good practice to develop features on a separate branch. This allows for multiple |
|
|
|
|
|
|
|
people to work on a project as well as allowing things like bug-fixes to be deployed without |
|
|
|
|
|
|
|
having to worry about interference from a new feature. |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
|
|
|
|
\frametitle{Commits / Branches} |
|
|
|
|
|
|
|
\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) {}; |
|
|
|
|
|
|
|
\node[commit] at (2,0) (commit2) {}; |
|
|
|
|
|
|
|
\node[commit] at (5,0) (commit4) {A}; |
|
|
|
|
|
|
|
\node[commit] at (8,0) (commit5) {C}; |
|
|
|
|
|
|
|
\node[commit] at (4,-2) (commit3b) {}; |
|
|
|
|
|
|
|
\node[commit] at (6,-2) (commit4b) {B}; |
|
|
|
|
|
|
|
\draw[arrow] (commit1) -- (commit2); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit4); |
|
|
|
|
|
|
|
\draw[arrow] (commit4) -- (commit5); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit3b); |
|
|
|
|
|
|
|
\draw[arrow] (commit3b) -- (commit4b); |
|
|
|
|
|
|
|
\draw[arrow] (commit4b) -- (commit5); |
|
|
|
|
|
|
|
\end{tikzpicture} |
|
|
|
|
|
|
|
\end{center} |
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
As well as 2 commits' ability to share a parent, the opposite is also true, Here, we see |
|
|
|
|
|
|
|
that a commit is able to have multiple parents. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is called a merge commit - because it merges two branches. In a lot of situations git |
|
|
|
|
|
|
|
is smart enough to auto-merge branches although at times human intervention is necessary. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
By default, git creates a branch called Master when you create a repository. |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame} |
|
|
|
\frametitle{Create a repository} |
|
|
|
\frametitle{Create a repository} |
|
|
@ -675,6 +636,8 @@ can really help. |
|
|
|
} |
|
|
|
} |
|
|
|
\end{frame} |
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame} |
|
|
|
\frametitle{References} |
|
|
|
\frametitle{References} |
|
|
|
\begin{itemize} |
|
|
|
\begin{itemize} |
|
|
@ -732,15 +695,89 @@ can really help. |
|
|
|
} |
|
|
|
} |
|
|
|
\end{frame} |
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame}[fragile] |
|
|
|
|
|
|
|
\frametitle{Branches} |
|
|
|
\frametitle{Branches} |
|
|
|
|
|
|
|
|
|
|
|
\begin{itemize} |
|
|
|
\begin{itemize} |
|
|
|
|
|
|
|
\item By default Git will create a branch called Master (maybe?). |
|
|
|
\item Allows multiple features to be developed in parallel without interference. |
|
|
|
\item Allows multiple features to be developed in parallel without interference. |
|
|
|
\item Allows multiple people to collaborate easily. |
|
|
|
\item Allows multiple people to collaborate easily. |
|
|
|
\end{itemize} |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
So, when I originally wrote this slide, git would create a branch called master by default. |
|
|
|
|
|
|
|
The convention was that this was your "main" branch. Currently on my system it still does |
|
|
|
|
|
|
|
although there is a movement to switch the default to main or primary or something similar. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I have no intentions to make this a political talk so make of it what you want. |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
|
|
|
|
\frametitle{Commits / Branches} |
|
|
|
|
|
|
|
\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) {}; |
|
|
|
|
|
|
|
\node[commit] at (2,0) (commit2) {A}; |
|
|
|
|
|
|
|
\node[commit] at (4,0) (commit3) {B}; |
|
|
|
|
|
|
|
\node[commit] at (4,-2) (commit3b) {C}; |
|
|
|
|
|
|
|
\draw[arrow] (commit1) -- (commit2); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit3); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit3b); |
|
|
|
|
|
|
|
\draw[draw=red] (-1,1) rectangle (5,-0.99); |
|
|
|
|
|
|
|
\node[fill=red,text=white,anchor=north west] at (-1,1) {Branch 1}; |
|
|
|
|
|
|
|
\draw[draw=green] (-1,-1) rectangle (5,-3); |
|
|
|
|
|
|
|
\node[fill=green,text=white,anchor=north west] at (-1,-1) {Branch 2}; |
|
|
|
|
|
|
|
\end{tikzpicture} |
|
|
|
|
|
|
|
\end{center} |
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
The linear graph we just saw is an overly simplistic representation. In reality, Git |
|
|
|
|
|
|
|
represents history using a Directed acyclic graph which allows parents to be shared my |
|
|
|
|
|
|
|
multiple commits. This is useful because it allows for Branches. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is good practice to develop features on a separate branch. This allows for multiple |
|
|
|
|
|
|
|
people to work on a project as well as allowing things like bug-fixes to be deployed without |
|
|
|
|
|
|
|
having to worry about interference from a new feature. |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
|
|
|
|
\frametitle{Commits / Branches} |
|
|
|
|
|
|
|
\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) {}; |
|
|
|
|
|
|
|
\node[commit] at (2,0) (commit2) {}; |
|
|
|
|
|
|
|
\node[commit] at (5,0) (commit4) {A}; |
|
|
|
|
|
|
|
\node[commit] at (8,0) (commit5) {C}; |
|
|
|
|
|
|
|
\node[commit] at (4,-2) (commit3b) {}; |
|
|
|
|
|
|
|
\node[commit] at (6,-2) (commit4b) {B}; |
|
|
|
|
|
|
|
\draw[arrow] (commit1) -- (commit2); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit4); |
|
|
|
|
|
|
|
\draw[arrow] (commit4) -- (commit5); |
|
|
|
|
|
|
|
\draw[arrow] (commit2) -- (commit3b); |
|
|
|
|
|
|
|
\draw[arrow] (commit3b) -- (commit4b); |
|
|
|
|
|
|
|
\draw[arrow] (commit4b) -- (commit5); |
|
|
|
|
|
|
|
\draw[draw=red] (-1,1) rectangle (9,-0.99); |
|
|
|
|
|
|
|
\node[fill=red,text=white,anchor=north west] at (-1,1) {Branch 1}; |
|
|
|
|
|
|
|
\draw[draw=green] (-1,-1) rectangle (9,-3); |
|
|
|
|
|
|
|
\node[fill=green,text=white,anchor=north west] at (-1,-1) {Branch 2}; |
|
|
|
|
|
|
|
\end{tikzpicture} |
|
|
|
|
|
|
|
\end{center} |
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
As well as 2 commits' ability to share a parent, the opposite is also true, Here, we see |
|
|
|
|
|
|
|
that a commit is able to have multiple parents. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is called a merge commit - because it merges two branches. In a lot of situations git |
|
|
|
|
|
|
|
is smart enough to auto-merge branches although at times human intervention is necessary. |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}[fragile] |
|
|
|
\begin{minted}{bash} |
|
|
|
\begin{minted}{bash} |
|
|
|
# List Branches |
|
|
|
# List Branches |
|
|
|
git branch # -v adds more info |
|
|
|
git branch # -v adds more info |
|
|
@ -909,7 +946,6 @@ can really help. |
|
|
|
\begin{itemize} |
|
|
|
\begin{itemize} |
|
|
|
\item HTTP(S) |
|
|
|
\item HTTP(S) |
|
|
|
\item SSH |
|
|
|
\item SSH |
|
|
|
\item GIT |
|
|
|
|
|
|
|
\item Local Filesystem |
|
|
|
\item Local Filesystem |
|
|
|
\end{itemize} |
|
|
|
\end{itemize} |
|
|
|
\end{itemize} |
|
|
|
\end{itemize} |
|
|
@ -1055,16 +1091,22 @@ can really help. |
|
|
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
\begin{frame} |
|
|
|
\frametitle{Useful supporting tools} |
|
|
|
\frametitle{Useful supporting tools} |
|
|
|
\framesubtitle{RigGrep / Fd} |
|
|
|
\framesubtitle{RipGrep / Fd / Exa} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\textbf{FD} replaces find |
|
|
|
|
|
|
|
|
|
|
|
\href{https://github.com/sharkdp/fd}{https://github.com/sharkdp/fd} |
|
|
|
\href{https://github.com/sharkdp/fd}{https://github.com/sharkdp/fd} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\textbf{RigGrep} replaces grep |
|
|
|
|
|
|
|
|
|
|
|
\href{https://github.com/BurntSushi/ripgrep}{https://github.com/BurntSushi/ripgrep} |
|
|
|
\href{https://github.com/BurntSushi/ripgrep}{https://github.com/BurntSushi/ripgrep} |
|
|
|
\note{% |
|
|
|
|
|
|
|
Alternatives to grep and find |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fd, in particular, is not a full replacement for find but does most of what you want |
|
|
|
\textbf{Exa} replaces ls |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\href{https://github.com/ogham/exa}{https://github.com/ogham/exa} |
|
|
|
|
|
|
|
\note{% |
|
|
|
|
|
|
|
|
|
|
|
Both (by default) will respect your gitignore file. |
|
|
|
Fd and RipGrep will respect your gitignore by default. |
|
|
|
} |
|
|
|
} |
|
|
|
\end{frame} |
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|