diff --git a/README.md b/README.md index a721812..d02b0d4 100644 --- a/README.md +++ b/README.md @@ -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[]{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 @@ -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[]{auto-download-.png} -``` - - diff --git a/greeting.py b/greeting.py old mode 100644 new mode 100755 index 463108b..f0a9e45 --- a/greeting.py +++ b/greeting.py @@ -1,25 +1,6 @@ -#!/usr/bin/env python - import sys + def main(): + print("Hello") -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() + if __name__ == "__main__": + main() diff --git a/main.latex b/main.latex index 8ac85bc..2c135bd 100644 --- a/main.latex +++ b/main.latex @@ -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,32 +57,38 @@ \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. +\frame{\titlepage} - 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" +\note{% + A few people recently have asked me about Git. - I think that understanding a bit about how Git works under the hood will help de-mistily it. - It certainly did for me. + Git has become the de-facto for most situations. - 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 - } - -\end{frame} + Bat is described as cat with wings. -\begin{frame} - \frametitle{Pull Requests} - \framesubtitle{Merge Requests} + It adds syntax highlighting to files. Useful even if you're not using Git - \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} diff --git a/shell/add-remote b/shell/add-remote index ddfb0f3..a6ac624 100755 --- a/shell/add-remote +++ b/shell/add-remote @@ -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' diff --git a/shell/fetch-merge-pull b/shell/fetch-merge-pull index ab9cb30..f8b595a 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 origin/master' +echo '$ git merge' git -c color.ui=always merge origin/master diff --git a/shell/tree-empty-git b/shell/tree-empty-git deleted file mode 100755 index 40ec961..0000000 --- a/shell/tree-empty-git +++ /dev/null @@ -1,4 +0,0 @@ -#!/usr/bin/env bash -echo '$ tree .git' -cd /tmp/demo -tree .git