|
|
|
@ -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 |
|
|
|
|