jab2870/Git-Presentation
1
0
Fork 0
Code Issues Pull requests Releases 2 Wiki Activity

Compare commits

base: jab2870:master
Branches Tags
jab2870:master
jab2870:Final
jab2870:FirstDraft
..
compare: jab2870:FirstDraft
Branches Tags
jab2870:master
jab2870:Final
jab2870:FirstDraft

No commits in common. "master" and "FirstDraft" have entirely different histories.
master ... FirstDraft

6 changed files with 334 additions and 477 deletions
Download patch file Download diff file Expand all files Collapse all files

30
README.md
View file

@ -2,15 +2,11 @@
This is a presentation about Git.
## Download
If you just want to download a copy of the presentation, you can do so [here](https://git.jonathanh.co.uk/attachments/b2f284a7-d9fe-4dda-b8e4-485d79cdfa6e).
## Build
To build it, you will need make, pdflatex and ansi-to-svg and inkscape.
To build the main pdf, run:
To build the main pd, run:
```bash
make main.pdf
@ -30,9 +26,7 @@ make only-notes.pdf
## Auto Images
The build system will generate certain types of graphics for the presentation as part of the build
system. The resultant files will always go in the `auto-images` folder. As a result, this folder is
not under version control.
The build system will generate certain types of graphics for the presentation as part of the build system. The resultant files will always go in the `auto-images` folder. As a result, this folder is not under version control.
In latex, all you need to do is
@ -50,16 +44,13 @@ What is a presentation without an xkcd comic?
\includegraphics[<options>]{auto-xkcd-<id>.png}
```
If the above is included in the latex document, the XKCD comic with the specified ID will be
downloaded and embedded in the pdf.
If the above is included in the latex document, the XKCD comic with the specified ID will be downloaded and embedded in the pdf.
### Shell Output
I am still not aware of aware of a reliable way to include ansi coloured shell output into a latex
document. I also don't want to include loads of high-res screenshots in my Git repo.
I am still not aware of aware of a reliable way to include ansi coloured shell output into a latex document. I also don't want to include loads of high-res screenshots in my Git repo.
The work around I have come up with is to save the raw ansi output to a wile in `shell-output`. This
normally involves forcing an application to output in colour:
The work around I have come up with is to save the raw ansi output to a wile in `shell-output`. This normally involves forcing an application to output in colour:
```bash
git -c color.status=always status > shell-output/git-status.out
@ -72,14 +63,3 @@ git -c color.status=always status > shell-output/git-status.out
```
The build system will convert the ansi output into an embeddable PDF that LaTeX will embed.
### Online images
In order to download an image from the internet and embed it in the presentation, you need do
provide the extension and the base64 encoded URL.
```latex
\includegraphics[<options>]{auto-download-<base64 encodede url>.png}
```

21
greeting.py Normal file → Executable file
View file

@ -1,25 +1,6 @@
#!/usr/bin/env python
import sys
def cat():
print("Meow")
def dog():
print("Woof")
def cow():
print("Moo")
def main():
if len(sys.argv) > 1 and sys.argv[1] == "cat":
cat()
elif len(sys.argv) > 1 and sys.argv[1] == "dog":
dog()
elif len(sys.argv) > 1 and sys.argv[1] == "cow":
cow()
else:
print("HELLO WORLD")
print("Hello")
if __name__ == "__main__":
main()

742
main.latex
View file

@ -1,4 +1,4 @@
\documentclass[aspectratio=169]{beamer}
\documentclass{beamer}
\usepackage{pgfpages}
%showNotes%\setbeameroption{show notes on second screen=right}
@ -15,13 +15,14 @@
\usepackage{amsmath}
\usepackage{pdfpages}
\usepackage{tikz}
\usepackage[UKenglish]{babel}%
\usetikzlibrary{shapes.geometric, arrows}
\tikzstyle{commit} = [circle, text centered, line width=2,
minimum size=1.5cm, draw=blue, fill=blue!80, text=white]
\tikzstyle{branch} = [ellipse, text centered, text=green]
\tikzstyle{arrow} = [thick, <-, draw=blue]
\usepackage{dirtree}
\usepackage{csquotes}
%\usepackage{gitdags}
@ -34,11 +35,7 @@
\usetheme{default}
\beamertemplatenavigationsymbolsempty
\hypersetup{%
colorlinks=true,
urlcolor=blue,
%pdfpagemode=UseNone
} % don't show bookmarks on initial view
\hypersetup{pdfpagemode=UseNone} % don't show bookmarks on initial view
%\lstset{%
% breaklines=true,
@ -60,31 +57,37 @@
\author{Jonathan Hodgson (Archie)}
\date{\today}
%\titlegraphic{\includegraphics[width=1cm,keepaspectratio]{auto-xkcd-1597.png})
\institute{
\includegraphics[width=\textwidth,height=.5\textheight,keepaspectratio]{auto-xkcd-1597.png}%
}
\begin{document}
\frame{
\titlepage
\frame{\titlepage}
\note{%
A few people recently have asked me about Git.
Git has a reputation for being hard. I think this is (at least partly) because so much of
its inner workings are abstracted away making the interface feel like magic. Not to mention
videos with titles like "Learn git in 15 minutes"
Git has become the de-facto for most situations.
I think that understanding a bit about how Git works under the hood will help de-mistily it.
It certainly did for me.
Git's data model is actually quite simple (beautiful even). Understanding the basics of this
can really help.
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}
\frametitle{Aims}
I am obviously not going to be able to go over everything that git does.
\begin{itemize}
\item I don't know everything Git does
\item Git does LOADS of stuff
\end{itemize}
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
understand the documentation.
\note{%
}
\end{frame}
\begin{frame}
\frametitle{What is Git}
@ -98,9 +101,9 @@
\end{itemize}
\note{%
Git is still being developed.
It keeps track by maintaining a series of snapshots containing all of the files and folders
at each point.
Being distributed means you can work on repositories offline (Unlike SVN).
It's useful even if you're working on things by your self. This presentation is version
controlled.
@ -108,147 +111,31 @@
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}
\begin{frame}
\frametitle{What is Git}
\begin{frame}
\frametitle{Obligitary XKCD Comic}
\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}
\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.
At its core, Git is a content addressed storage tool. All files and folders are addressed by
a (hardened) sha1 hash.
}
\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}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-xkcd-1597.png}
\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}
I have done this
\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}
Git has a reputation for being hard.
It's interface abstracts away a lot of the work, meaning it's commands can feel like magic.
When it works, this is fine but unfortunately when things go wrong, you can be left - like
in this comic - with no idea how to proceed.
It's interface can be confusing, there are some commands that do a lot (checkout) and there
are often multiple ways to achieve something.
I think that understanding a bit about how Git works under the hood will help de-mistily it.
Git's data model is actually quite simple (beautiful even). Understanding the basics of this
can really help.
}
\end{frame}
@ -272,7 +159,7 @@
git --version
\end{minted}
Git for Windows: \href{https://gitforwindows.org/}{https://gitforwindows.org/}
\href{https://gitforwindows.org/}{Git for Windows: https://gitforwindows.org/}
\note{%
Git is probably already installed if you are on a Linux system. However, if not, it will
@ -337,23 +224,230 @@
}
\end{frame}
\begin{frame}
\frametitle{Create a repository}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-git-init.pdf}
\end{center}
\note{%
Do this in a live terminal. MAKE SURE YOU MAKE YOUR FONT BIGGER
%\begin{frame}[fragile]
% \frametitle{Setting It Up}
% \framesubtitle{Preferences}
%
% \textbf{Pick One}
% \begin{minted}{bash}
% # No colour
% git config --global color.ui never
%
% # Auto colour
% git config --global color.ui auto
%
% # Force colour
% git config --global color.ui always
%
% # Overide for a command
% git -c color.ui=always status > ~/some-file
%
% \end{minted}
%
% \note{%
% On Linux systems, this is set to auto by default. Might be different on a Mac. Generally
% auto is probably what you want. It will be coloured unless you are piping the output to a
% file or another process.
%
% Take note of the incorrect spelling of colour.
%
% You can override all configuration options on an individual command basis if you like.
% }
%\end{frame}
Show that the \mintinline{bash}{.git} folder has been created and do a tree to show what is
in it.
\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.
% .2 real-final.
% .3 some.
% .3 files.
% .2 actual-real-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{Model 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 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] 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{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}
\frametitle{Create a repository}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-tree-empty-git.pdf}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-git-init.pdf}
\end{center}
\note{%
Do this in a live terminal. MAKE SURE YOU MAKE YOUR FONT BIGGER
@ -377,31 +471,6 @@
}
\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{Staging Area}
@ -412,6 +481,14 @@
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}
@ -428,8 +505,11 @@
}
\end{frame}
\begin{frame}
\begin{frame}[fragile]
\frametitle{Committing}
\begin{minted}{bash}
git commit
\end{minted}
\begin{itemize}
\item First line should be concise summary around 50 chars
@ -457,7 +537,6 @@
\framesubtitle{Commit early, commit often}
\begin{itemize}
\item Every time you complete a small change or fix a bug
\item For each point on a detailed to-do list
\item You don't normally want to commit broken code (intentionally at least)
\item In some instances you might want to auto-commit - but probably not too often.
\begin{itemize}
@ -516,8 +595,6 @@
\note{%
Diff is pretty smart. It will normally work for whatever combinations of commits, references
(more on that later) or files.
Change Hello to Hello World
}
\end{frame}
@ -598,8 +675,6 @@
}
\end{frame}
\begin{frame}
\frametitle{References}
\begin{itemize}
@ -610,35 +685,8 @@
\end{itemize}
\note{%
We've seen a couple of these (sort of)
}
\end{frame}
\begin{frame}
\frametitle{References}
\begin{itemize}
\item Branches
\begin{itemize}
\item Parallel development
\end{itemize}
\item Tags
\begin{itemize}
\item Special points in history (Release versions)
\end{itemize}
\item HEAD
\begin{itemize}
\item Current position in history
\end{itemize}
\end{itemize}
\note{%
Branches allow for parallel development, individually or multiple people. We well look at
these in more detail in a minute.
Tags allow you to mark special commits. Normally this is used for release versions or
similar.
HEAD refers to the commit or branch you are currently looking at. We will see in a minute
that you can revert a whole project to a previous point in time. This is how git knows
where (when?) you are.
Master and Head
}
\end{frame}
@ -668,105 +716,40 @@
\end{frame}
\begin{frame}
\frametitle{References}
\framesubtitle{HEAD}
\begin{itemize}
\item The HEAD references is directly in the \mintinline{bash}{.git} folder.
\item It refers to the ``current" commit. It is how git knows where you are.
\item This normally refers to a branch's head commit.
\item In some situations it will refer to a commit directly.
\end{itemize}
\note{%
Not sure why it is not in refs folder
If it refers directly to a commit, the repository is in what is called a ``detached head"
state.
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Branches}
\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 people to collaborate easily.
\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};
\node[anchor=west] at (4.5,0.5) {+Bugfix};
\node[anchor=west] at (4.5,-2.5) {+Feature};
\draw[arrow] (commit1) -- (commit2);
\draw[arrow] (commit2) -- (commit3);
\draw[arrow] (commit2) -- (commit3b);
\draw[draw=red] (-1,1) rectangle (6.5,-0.99);
\node[fill=red,text=white,anchor=north west] at (-1,1) {Branch 1};
\draw[draw=green] (-1,-1) rectangle (6.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};
\node[anchor=west] at (5.5,0.5) {+Bugfix};
\node[anchor=west] at (6.5,-2.5) {+Feature};
\node[anchor=south west] at (8.7,-0.2) {\parbox{\textwidth}{+Bugfix \\ +Feature}};
\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 (10.5,-0.99);
\node[fill=red,text=white,anchor=north west] at (-1,1) {Branch 1};
\draw[draw=green] (-1,-1) rectangle (10.5,-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}
# List Branches
git branch # -v adds more info
# Create a branch called test
git branch test # or
cp ~/.git/refs/heads/master ~/.git/refs/heads/test
# Switch to new branch
git switch test # or
git checkout test
# Create and switch in one go
git switch -c test # or
git checkout -b test
@ -926,6 +909,7 @@
\begin{itemize}
\item HTTP(S)
\item SSH
\item GIT
\item Local Filesystem
\end{itemize}
\end{itemize}
@ -1054,65 +1038,45 @@
\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}
\frametitle{Useful supporting tools}
\framesubtitle{Bat}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-download-aHR0cHM6Ly9jYW1vLmdpdGh1YnVzZXJjb250ZW50LmNvbS82N2U0NGY0YTY4MTUwMzI1Zjc0YjNhNDY4MjBiNzQ3M2ZmN2I5MWE2LzY4NzQ3NDcwNzMzYTJmMmY2OTJlNjk2ZDY3NzU3MjJlNjM2ZjZkMmYzMjZjNTM1NzM0NTI0NTJlNzA2ZTY3.png}
\end{center}
\href{https://github.com/sharkdp/bat}{https://github.com/sharkdp/bat}
\note{%
Demonstrate this in a browser using Github
}
Bat is described as cat with wings.
\end{frame}
It adds syntax highlighting to files. Useful even if you're not using Git
\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}
As this is a git talk, it shows lines that have changed since the last commit
}
\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.
\framesubtitle{RigGrep / Fd}
\href{https://github.com/sharkdp/fd}{https://github.com/sharkdp/fd}
Prompt customisation is available out of the box for bash and zsh.
\href{https://github.com/BurntSushi/ripgrep}{https://github.com/BurntSushi/ripgrep}
\note{%
If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than
Bach's.
Alternatives to grep and find
Fd, in particular, is not a full replacement for find but does most of what you want
Both (by default) will respect your gitignore file.
}
\end{frame}
\begin{frame}
\frametitle{Useful supporting tools}
\framesubtitle{Editor Plugin}
\begin{itemize}
\item Git Gutters
\item Easy staging of parts of a file
\item Merge Conflict Resolution
\end{itemize}
\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{%
There are obviously hundreds of editors so find one that works well with yours.
I think Atom and VS Code have built in integration.
I use vim-fugitive. I've heard good things about magit for emacs.
This is a tool that can make your diff output look better.
}
\end{frame}
@ -1131,66 +1095,14 @@
\begin{frame}
\frametitle{Useful supporting tools}
\framesubtitle{Git Crypt}
\framesubtitle{Shell Integration}
Git ships with completion for bash, zsh and tcsh. You may need to source it in the relevant rc
file.
For storing sensitive information in a git repository.
\href{https://github.com/AGWA/git-crypt}{https://github.com/AGWA/git-crypt}
Prompt customisation is available out of the box for bash and zsh.
\note{%
This will encrypt files with gpg key(s) and transparently decrypt them on the file system.
}
\end{frame}
\begin{frame}
\frametitle{Useful supporting tools}
\framesubtitle{Git Large File Storage}
A solution to the issue of storing binary files
\href{https://git-lfs.github.com/}{https://git-lfs.github.com/}
\note{%
As mentioned, git is not good at storing binary files because they can't be compressed or
diff-ed or merged.
This allows you to store links to large files and transparently add them to the file system
as though they were normal git blobs.
}
\end{frame}
\begin{frame}
\frametitle{Useful supporting tools}
\framesubtitle{Bat}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-download-aHR0cHM6Ly9jYW1vLmdpdGh1YnVzZXJjb250ZW50LmNvbS82N2U0NGY0YTY4MTUwMzI1Zjc0YjNhNDY4MjBiNzQ3M2ZmN2I5MWE2LzY4NzQ3NDcwNzMzYTJmMmY2OTJlNjk2ZDY3NzU3MjJlNjM2ZjZkMmYzMjZjNTM1NzM0NTI0NTJlNzA2ZTY3.png}
\end{center}
\href{https://github.com/sharkdp/bat}{https://github.com/sharkdp/bat}
\note{%
Bat is described as cat with wings.
It adds syntax highlighting to files. Useful even if you're not using Git
As this is a git talk, it shows lines that have changed since the last commit
}
\end{frame}
\begin{frame}
\frametitle{Useful supporting tools}
\framesubtitle{RipGrep / Fd / Exa}
\textbf{FD} replaces find
\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}
\textbf{Exa} replaces ls
\href{https://github.com/ogham/exa}{https://github.com/ogham/exa}
\note{%
Fd and RipGrep will respect your gitignore by default.
If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than
Bash's.
}
\end{frame}
@ -1235,16 +1147,4 @@
}
\end{frame}
\begin{frame}
\frametitle{Questions}
You can find this presentation here:
\href{https://git.jonathanh.co.uk/jab2870/Git-Presentation}{https://git.jonathanh.co.uk/jab2870/Git-Presentation}
\note{%
Yes, this presentation uses git for version control
}
\end{frame}
\end{document}

2
shell/add-remote
View file

@ -1,6 +1,5 @@
#!/usr/bin/env bash
cd /tmp/demo
(
rm -rf /tmp/demo-remote
mkdir -p /tmp/demo-remote
@ -8,6 +7,7 @@ git init --bare /tmp/demo-remote
git remote remove origin
) > /dev/null 2>&1
cd /tmp/demo
echo '$ git remote add origin /tmp/demo-remote'
git remote add origin /tmp/demo-remote
echo '$ git remote'

2
shell/fetch-merge-pull
View file

@ -22,5 +22,5 @@ git -c color.ui=always status
echo '$ git log --oneline --all --graph'
git -c color.ui=always log --oneline --all --graph --decorate=short
echo '$ git merge origin/master'
echo '$ git merge'
git -c color.ui=always merge origin/master

4
shell/tree-empty-git
View file

@ -1,4 +0,0 @@
#!/usr/bin/env bash
echo '$ tree .git'
cd /tmp/demo
tree .git