|
|
|
@ -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,115 +127,6 @@ |
|
|
|
|
} |
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}[fragile] |
|
|
|
|
\frametitle{Install} |
|
|
|
|
|
|
|
|
|
\begin{minted}{bash} |
|
|
|
|
# Ubuntu / Debian / Kali |
|
|
|
|
sudo apt install git |
|
|
|
|
|
|
|
|
|
# Centos / Fedora / Red Hat |
|
|
|
|
sudo dnf install git |
|
|
|
|
|
|
|
|
|
# Arch / Antergos / Manjaro |
|
|
|
|
sudo pacman -S git |
|
|
|
|
|
|
|
|
|
# Mac |
|
|
|
|
brew install git |
|
|
|
|
|
|
|
|
|
# Get the Version |
|
|
|
|
git --version |
|
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
Git for Windows: \href{https://gitforwindows.org/}{https://gitforwindows.org/} |
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
Git is probably already installed if you are on a Linux system. However, if not, it will |
|
|
|
|
definitely be in your standard repositories. |
|
|
|
|
|
|
|
|
|
There is a version of Git provided with xcode, but it is old. Most of the stuff we cover |
|
|
|
|
today should still work but (for example) some things need to be run from the root directory |
|
|
|
|
in old versions of git that don't in newer versions. |
|
|
|
|
|
|
|
|
|
If you have the misfortune to be using windows, I've heard good things about Git for Windows |
|
|
|
|
but have not used it personally. It includes Bash emulation. |
|
|
|
|
|
|
|
|
|
Hopefully you have a version greater than 2.23.0 - if not, it's not the end of the world. |
|
|
|
|
} |
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
\begin{frame}[fragile] |
|
|
|
|
\frametitle{Setting It Up} |
|
|
|
|
\framesubtitle{User} |
|
|
|
|
|
|
|
|
|
\begin{minted}{bash} |
|
|
|
|
git config --global user.name "Jonathan Hodgson" |
|
|
|
|
git config --global user.email "git@jonathanh.co.uk" |
|
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
Hopefully you have Git installed. I will be running it on Linux although the commands should |
|
|
|
|
all be the same for Windows and Mac. |
|
|
|
|
|
|
|
|
|
Note that I am not using my primary email address. The email address you provide here will |
|
|
|
|
be available to anyone with access to repositories you work on. |
|
|
|
|
|
|
|
|
|
These settings are stored in \mintinline{bash}{~/.gitconfig}. |
|
|
|
|
} |
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
\begin{frame}[fragile] |
|
|
|
|
\frametitle{Setting It Up} |
|
|
|
|
\framesubtitle{Editor} |
|
|
|
|
|
|
|
|
|
\textbf{Pick One} |
|
|
|
|
\begin{minted}{bash} |
|
|
|
|
# Set editor to vim |
|
|
|
|
git config --global core.editor "vim" |
|
|
|
|
|
|
|
|
|
# Set editor to nano |
|
|
|
|
git config --global core.editor "nano" |
|
|
|
|
|
|
|
|
|
# Set editor to VS Code |
|
|
|
|
git config --global core.editor "code -w" |
|
|
|
|
|
|
|
|
|
# Set editor to Sublime |
|
|
|
|
git config --global core.editor "subl -w" |
|
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
There are several times that Git will need to open a text editor. By default, it will use |
|
|
|
|
\mintinline{bash}{EDITOR}. If neither is set, it will use VI. |
|
|
|
|
|
|
|
|
|
Note that if you are using a GUI editor, you might have to set the wait flag. This makes it |
|
|
|
|
so the executable doesn't return until you close it. |
|
|
|
|
} |
|
|
|
|
\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} |
|
|
|
@ -266,22 +156,43 @@ |
|
|
|
|
\begin{itemize} |
|
|
|
|
\item Difficult to collaborate |
|
|
|
|
\item Lot's of wasted disk space |
|
|
|
|
\item Can be difficult to work out chronological order |
|
|
|
|
\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. |
|
|
|
|
|
|
|
|
|
However, this is a simple approach and not a million miles from what Git does internally. |
|
|
|
|
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{Improve it} |
|
|
|
|
\frametitle{Commits} |
|
|
|
|
\framesubtitle{(Snapshots)} |
|
|
|
|
\begin{center} |
|
|
|
|
\begin{tikzpicture} |
|
|
|
|
%\draw (-1.5,-1.5) rectangle (7.5,1.5); |
|
|
|
@ -298,11 +209,9 @@ |
|
|
|
|
\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 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} |
|
|
|
|
} |
|
|
|
@ -339,6 +248,115 @@ |
|
|
|
|
} |
|
|
|
|
\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} |
|
|
|
|
|
|
|
|
|
\begin{minted}{bash} |
|
|
|
|
# Ubuntu / Debian / Kali |
|
|
|
|
sudo apt install git |
|
|
|
|
|
|
|
|
|
# Centos / Fedora / Red Hat |
|
|
|
|
sudo dnf install git |
|
|
|
|
|
|
|
|
|
# Arch / Antergos / Manjaro |
|
|
|
|
sudo pacman -S git |
|
|
|
|
|
|
|
|
|
# Mac |
|
|
|
|
brew install git |
|
|
|
|
|
|
|
|
|
# Get the Version |
|
|
|
|
git --version |
|
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
Git for Windows: \href{https://gitforwindows.org/}{https://gitforwindows.org/} |
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
Git is probably already installed if you are on a Linux system. However, if not, it will |
|
|
|
|
definitely be in your standard repositories. |
|
|
|
|
|
|
|
|
|
There is a version of Git provided with xcode, but it is old. Most of the stuff we cover |
|
|
|
|
today should still work but (for example) some things need to be run from the root directory |
|
|
|
|
in old versions of git that don't in newer versions. |
|
|
|
|
|
|
|
|
|
If you have the misfortune to be using windows, I've heard good things about Git for Windows |
|
|
|
|
but have not used it personally. It includes Bash emulation. |
|
|
|
|
|
|
|
|
|
Hopefully you have a version greater than 2.23.0 - if not, it's not the end of the world. |
|
|
|
|
} |
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
\begin{frame}[fragile] |
|
|
|
|
\frametitle{Setting It Up} |
|
|
|
|
\framesubtitle{User} |
|
|
|
|
|
|
|
|
|
\begin{minted}{bash} |
|
|
|
|
git config --global user.name "Jonathan Hodgson" |
|
|
|
|
git config --global user.email "git@jonathanh.co.uk" |
|
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
Hopefully you have Git installed. I will be running it on Linux although the commands should |
|
|
|
|
all be the same for Windows and Mac. |
|
|
|
|
|
|
|
|
|
Note that I am not using my primary email address. The email address you provide here will |
|
|
|
|
be available to anyone with access to repositories you work on. |
|
|
|
|
|
|
|
|
|
These settings are stored in \mintinline{bash}{~/.gitconfig}. |
|
|
|
|
} |
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
\begin{frame}[fragile] |
|
|
|
|
\frametitle{Setting It Up} |
|
|
|
|
\framesubtitle{Editor} |
|
|
|
|
|
|
|
|
|
\textbf{Pick One} |
|
|
|
|
\begin{minted}{bash} |
|
|
|
|
# Set editor to vim |
|
|
|
|
git config --global core.editor "vim" |
|
|
|
|
|
|
|
|
|
# Set editor to nano |
|
|
|
|
git config --global core.editor "nano" |
|
|
|
|
|
|
|
|
|
# Set editor to VS Code |
|
|
|
|
git config --global core.editor "code -w" |
|
|
|
|
|
|
|
|
|
# Set editor to Sublime |
|
|
|
|
git config --global core.editor "subl -w" |
|
|
|
|
\end{minted} |
|
|
|
|
|
|
|
|
|
\note{% |
|
|
|
|
There are several times that Git will need to open a text editor. By default, it will use |
|
|
|
|
\mintinline{bash}{EDITOR}. If neither is set, it will use VI. |
|
|
|
|
|
|
|
|
|
Note that if you are using a GUI editor, you might have to set the wait flag. This makes it |
|
|
|
|
so the executable doesn't return until you close it. |
|
|
|
|
} |
|
|
|
|
\end{frame} |
|
|
|
|
|
|
|
|
|
\begin{frame} |
|
|
|
|
\frametitle{Create a repository} |
|
|
|
@ -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} |
|
|
|
|