diff --git a/README.md b/README.md index d02b0d4..a721812 100644 --- a/README.md +++ b/README.md @@ -2,11 +2,15 @@ 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 pd, run: +To build the main pdf, run: ```bash make main.pdf @@ -26,7 +30,9 @@ 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 @@ -44,13 +50,16 @@ What is a presentation without an xkcd comic? \includegraphics[]{auto-xkcd-.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 @@ -63,3 +72,14 @@ 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[]{auto-download-.png} +``` + + diff --git a/greeting.py b/greeting.py old mode 100755 new mode 100644 index f0a9e45..463108b --- a/greeting.py +++ b/greeting.py @@ -1,6 +1,25 @@ -import sys - def main(): - print("Hello") +#!/usr/bin/env python - if __name__ == "__main__": - main() +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") + +if __name__ == "__main__": + main() diff --git a/main.latex b/main.latex index 2c135bd..8ac85bc 100644 --- a/main.latex +++ b/main.latex @@ -1,4 +1,4 @@ -\documentclass{beamer} +\documentclass[aspectratio=169]{beamer} \usepackage{pgfpages} %showNotes%\setbeameroption{show notes on second screen=right} @@ -15,14 +15,13 @@ \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} @@ -35,7 +34,11 @@ \usetheme{default} \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{% % breaklines=true, @@ -57,37 +60,31 @@ \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} - -\note{% - A few people recently have asked me about Git. - - Git has become the de-facto for most situations. - - 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. +\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" + + 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. + } -\end{frame} +} \begin{frame} \frametitle{What is Git} @@ -101,9 +98,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. @@ -111,31 +108,147 @@ 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{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{Obligitary XKCD Comic} + \frametitle{Commits} + \framesubtitle{(Snapshots)} \begin{center} - \includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-xkcd-1597.png} + \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{% - I have done this + \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} - Git has a reputation for being hard. +\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} - 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} @@ -159,7 +272,7 @@ can really help. git --version \end{minted} - \href{https://gitforwindows.org/}{Git for Windows: https://gitforwindows.org/} + 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 @@ -224,226 +337,6 @@ can really help. } \end{frame} -%\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} - -\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} @@ -457,6 +350,19 @@ can really help. } \end{frame} +\begin{frame} + \frametitle{Create a repository} + \begin{center} + \includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-tree-empty-git.pdf} + \end{center} + \note{% + Do this in a live terminal. MAKE SURE YOU MAKE YOUR FONT BIGGER + + Show that the \mintinline{bash}{.git} folder has been created and do a tree to show what is + in it. + } +\end{frame} + \begin{frame}[fragile] \frametitle{Git status} @@ -471,6 +377,31 @@ can really help. } \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} @@ -481,14 +412,6 @@ can really help. 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} @@ -505,11 +428,8 @@ can really help. } \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 @@ -537,6 +457,7 @@ can really help. \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} @@ -595,6 +516,8 @@ can really help. \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} @@ -675,6 +598,8 @@ can really help. } \end{frame} + + \begin{frame} \frametitle{References} \begin{itemize} @@ -685,8 +610,35 @@ can really help. \end{itemize} \note{% We've seen a couple of these (sort of) + } +\end{frame} - Master and Head +\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. } \end{frame} @@ -716,40 +668,105 @@ can really help. \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 @@ -909,7 +926,6 @@ can really help. \begin{itemize} \item HTTP(S) \item SSH - \item GIT \item Local Filesystem \end{itemize} \end{itemize} @@ -1038,45 +1054,65 @@ can really help. \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} + \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{% - Bat is described as cat with wings. + Demonstrate this in a browser using Github + } + +\end{frame} - It adds syntax highlighting to files. Useful even if you're not using Git +\begin{frame} + \frametitle{Pull Requests} + \framesubtitle{Merge Requests} - As this is a git talk, it shows lines that have changed since the last commit + \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{RigGrep / Fd} - \href{https://github.com/sharkdp/fd}{https://github.com/sharkdp/fd} + \framesubtitle{Shell Integration} + Git ships with completion for bash, zsh and tcsh. You may need to source it in the relevant rc + file. - \href{https://github.com/BurntSushi/ripgrep}{https://github.com/BurntSushi/ripgrep} + Prompt customisation is available out of the box for bash and zsh. \note{% - 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. + If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than + Bach's. } \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} + \framesubtitle{Editor Plugin} + \begin{itemize} + \item Git Gutters + \item Easy staging of parts of a file + \item Merge Conflict Resolution + \end{itemize} \note{% - This is a tool that can make your diff output look better. + 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. } \end{frame} @@ -1095,14 +1131,66 @@ can really help. \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{Git Crypt} - Prompt customisation is available out of the box for bash and zsh. + For storing sensitive information in a git repository. + + \href{https://github.com/AGWA/git-crypt}{https://github.com/AGWA/git-crypt} \note{% - If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than - Bash's. + 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. } \end{frame} @@ -1147,4 +1235,16 @@ can really help. } \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} diff --git a/shell/add-remote b/shell/add-remote index a6ac624..ddfb0f3 100755 --- a/shell/add-remote +++ b/shell/add-remote @@ -1,5 +1,6 @@ #!/usr/bin/env bash +cd /tmp/demo ( rm -rf /tmp/demo-remote mkdir -p /tmp/demo-remote @@ -7,7 +8,6 @@ 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' diff --git a/shell/fetch-merge-pull b/shell/fetch-merge-pull index f8b595a..ab9cb30 100755 --- a/shell/fetch-merge-pull +++ b/shell/fetch-merge-pull @@ -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' +echo '$ git merge origin/master' git -c color.ui=always merge origin/master diff --git a/shell/tree-empty-git b/shell/tree-empty-git new file mode 100755 index 0000000..40ec961 --- /dev/null +++ b/shell/tree-empty-git @@ -0,0 +1,4 @@ +#!/usr/bin/env bash +echo '$ tree .git' +cd /tmp/demo +tree .git