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

Tidy up and add's slides on remotes

Browse source
This commit is contained in:
Jonathan Hodgson 2020-06-16 16:21:13 +01:00
parent 94607bbdea
commit 312d654ea8
5 changed files with 315 additions and 61 deletions
Download patch file Download diff file Expand all files Collapse all files

25
code-examples/python-with-cow.py Normal file
View file

@ -0,0 +1,25 @@
#!/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")
if __name__ == "__main__":
main()

297
main.latex
View file

@ -70,8 +70,26 @@
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.
\note{%
}
\end{frame}
\begin{frame}
\frametitle{What is Git}
@ -207,36 +225,36 @@ 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}[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}
@ -248,45 +266,64 @@ can really help.
\textbf{Commit} A snapshot of your code
All of these are referenced by a hash and stored in the \mintinline{bash}{.git/objects/}
directory.
% All of these are referenced by a hash and stored in the \mintinline{bash}{.git/objects/}
% directory.
\note{%
Most Git tutorials I have come across focus on memorizing commands. This way, the commands
feel like magic and there is never really any understanding of what the commands do under
the hood.
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}
\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.
}
\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.
I want this to be quite interactive so first things first, let's get Git setup.
}
\end{frame}
@ -298,7 +335,7 @@ can really help.
%\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] at (6,0) (commit3) {Final};
\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] };
@ -308,10 +345,10 @@ can really help.
\end{center}
\note{%
\begin{itemize}
\item This is a simple representation of the folder structure we saw, although for
simplicity, I'm only showing 3 revisions.
\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
include a reference to the previous snapshot.
\item We then just need to record the most recent version somewhere.
\end{itemize}
}
\end{frame}
@ -861,6 +898,146 @@ can really help.
}
\end{frame}
\begin{frame}
\frametitle{Remotes}
\begin{itemize}
\item The majority of Git commands only affect your local repository.
\item Git has a concept called remotes which you can think of as other instances of the same
repository
\item Git has a selection of commands that are used to communicate with these remote
repositories
\item It can communicate on multiple protocols including
\begin{itemize}
\item HTTP(S)
\item SSH
\item GIT
\item Local Filesystem
\end{itemize}
\end{itemize}
\note{%
The most common public remote is Git hub. This is one of many options.
The most common protocols are HTTP and SSH, both offering advantages over the other.
HTTP is easier to use and allows for anonymous access (useful for public repositories)
SSH allows for easier authentication but there is no anonymous authentication.
For ease of automating screen shots, I will be using local file system although all commands
are the same.
}
\end{frame}
\begin{frame}
\frametitle{Adding a remote}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-add-remote.pdf}
\end{center}
\note{%
In this example, I am using a local folder as a URL but you can use anything.
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Pushing your code}
\framesubtitle{Long Way}
\begin{minted}{bash}
git push <remote> <local-branch>:<remote-branch>
# E.g.
git push origin master:master
\end{minted}
\note{%
Although this is usable, it is a bit annoying since you will normally want to create a 1 to
1 correspondence between your local branches and the remote branches.
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Pushing your code}
\framesubtitle{Easy way}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-set-upstream-push.pdf}
\end{center}
\note{%
Admittedly, this looks like a longer way. However, the first command only needs to be run
the once. Git will then remember that the remote branch origin/master should be linked with
the local branch master.
As you can see from the git-status now, it tells us that the current branch is up to date
with the remote branch.
}
\end{frame}
\begin{frame}
\frametitle{Retrieving changes from the remote}
\begin{center}
\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-fetch-merge-pull.pdf}
\end{center}
\note{%
Here another user has pushed changes to the master branch.
You can see here that the git fetch command downloads the required information. However, it
doesn't change your working tree.
In order to update our local master, we can simply do a git merge
Also note that after the git fetch command, the git status gives us some useful information.
This is another advantage of setting the corresponding upstream branch.
\begin{itemize}
\item We are 1 commit behind the remote version
\item The branch can be fast forwarded.
\end{itemize}
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Git Pull}
\framesubtitle{Shortcut}
\begin{minted}{bash}
git pull
git pull <remote> <branch>
\end{minted}
\note{%
Git has a command called pull which does the equivalent of a fetch then a merge.
The short version will only work if you have the local branch linked with a remote branch.
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Cloning}
\begin{minted}{bash}
# Clone a repository into a folder
git clone <URL> <folder>
# Clone a repository into a folder on a specific branch
git clone --branch <branch> <URL> <folder>
# Shallow clone a repository into a folder
git clone --shallow <URL> <folder>
\end{minted}
\note{%
If you would like to start from an existing remote repository, you can use the git clone
command.
This will automatically set up the link between the local and remote branches.
A shallow clone doesn't download all of the history.
}
\end{frame}
\begin{frame}
\frametitle{Git $\ne$ GitHub}
\begin{itemize}
@ -871,7 +1048,6 @@ can really help.
\item It it very popular
\end{itemize}
\note{%
By this point, we have covered a lot of the day-to-day stuff about Git.
}
\end{frame}
@ -949,4 +1125,3 @@ can really help.
\end{frame}
\end{document}
%\textbf{Staging area} Waiting area before a commit

16
shell/add-remote Executable file
View file

@ -0,0 +1,16 @@
#!/usr/bin/env bash
(
rm -rf /tmp/demo-remote
mkdir -p /tmp/demo-remote
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'
git remote
echo '$ git remote get-url origin'
git remote get-url origin

26
shell/fetch-merge-pull Executable file
View file

@ -0,0 +1,26 @@
#!/usr/bin/env bash
DIR="$(dirname "$(readlink -f "$0")")"
(
rm -rf /tmp/demo-clone
git clone /tmp/demo-remote /tmp/demo-clone
cd /tmp/demo-clone
git config user.name "Bob Bobbington"
cp "${DIR}/../code-examples/python-with-cow.py" greeting.py > /dev/null
git add greeting.py
git commit -m "Adds Cow option"
git push
) > /dev/null 2>&1
cd /tmp/demo/
echo '$ git fetch'
git fetch
echo '$ git status'
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'
git -c color.ui=always merge origin/master

12
shell/set-upstream-push Executable file
View file

@ -0,0 +1,12 @@
#!/usr/bin/env bash
cd /tmp/demo
echo '$ git branch --set-upstream-to=origin/master master'
git branch --set-upstream-to=origin/master master
echo '$ git push'
git push
echo '$ git status'
git -c color.ui=always status