@ -126,6 +126,39 @@
p {
text-align: left;
}
.license-footer {
opacity: 0.6;
transition: opacity 0.3s ease;
}
.license-footer:hover {
opacity: 1;
}
.license-icons {
cursor: pointer;
}
.license-tooltip {
display: none;
position: absolute;
background-color: rgba(0, 0, 0, 0.8);
color: #fff;
padding: 5px 10px;
border-radius: 4px;
font-size: 12px;
white-space: nowrap;
top: 100%;
right: 0;
margin-top: 5px;
}
.license-footer:hover .license-tooltip {
display: block;
}
< / style >
< / head >
< body >
@ -138,6 +171,8 @@ Economists</h1>
< p class = "author" > Will King (presentation+git@youainti.com)< / p >
< / section >
< div class = "reveal" >
< div class = "slides" >
< section >
< section id = "what-is-git" class = "title-slide slide level1" >
< h1 > What Is Git?< / h1 >
@ -153,7 +188,8 @@ alt="What is Git? Explanation at ExplainXKCD" />
at ExplainXKCD< / a > < / figcaption >
< / figure >
< / section >
< section id = "what-problems-are-we-trying-to-solve" class = "slide level2" >
< section id = "what-problems-are-we-trying-to-solve"
class="slide level2">
< h2 > What problems are we trying to solve?< / h2 >
< ul >
< li > How can we keep track of our work?< / li >
@ -261,14 +297,14 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb2-1"><a href="
< / ul >
< aside class = "notes" >
< p > Get everyone to open bash at their home location. pwd, then talk
about slashes etc. Talk about spaces and quoting and escaping. Show a
variety of paths.< / p >
about slashes etc. Talk about spaces and quoting and escaping. Show
a variety of paths.< / p >
< / aside >
< / section >
< section id = "bash-activity" class = "slide level2" >
< h2 > Bash Activity< / h2 >
< p > Prep: < a href = "https://www.youainti.com" > Download< / a > and extract the
zip file I’ < / p >
< p > Prep: < a href = "https://www.youainti.com" > Download< / a > and extract
the zip file I’ < / p >
< ol type = "1" >
< li > Open bash/gitbash in the extracted directory.< / li >
< li > Figure out what directory you are in.< / li >
@ -287,8 +323,8 @@ command line too.</p>
< / section >
< section id = "getting-help-on-the-command-line" class = "slide level2" >
< h2 > Getting help on the command line< / h2 >
< p > When you run into issues on the command line, you need to know how to
get help:< / p >
< p > When you run into issues on the command line, you need to know
how to get help:< / p >
< ul >
< li > internet searches (google, stackoverflow, etc)< / li >
< li > local resources
@ -303,8 +339,8 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb3-1"><a href="
< span id = "cb3-2" > < a href = "#cb3-2" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > man< / span > ls< / span >
< span id = "cb3-3" > < a href = "#cb3-3" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "ex" > info< / span > ls< / span > < / code > < / pre > < / div >
< aside class = "notes" >
< p > Examine some of the CLI options for the command presented earlier.
Maybe:< / p >
< p > Examine some of the CLI options for the command presented
earlier. Maybe:< / p >
< ul >
< li > < code > ls -l< / code > < / li >
< li > < code > ls -a< / code > < / li >
@ -320,7 +356,8 @@ class="title-slide slide level1">
< section id = "concepts" class = "slide level2" >
< h2 > Concepts< / h2 >
< ul >
< li > Repositories: A directory where you will be tracking changes.< / li >
< li > Repositories: A directory where you will be tracking
changes.< / li >
< li > Snapshots: A copy of the state of the repository at a given
time.< / li >
< li > Working Copy: Changes that haven’
@ -338,9 +375,9 @@ yet.</li>
< / ol >
< p > The < code > git init< / code > command turned the current directory
(< code > .< / code > ) into a git repository.< / p >
< p > If you were to type < code > git init repo_name< / code > it would create a
new directory named < code > repo_name/< / code > and then turn it into a git
repo.< / p >
< p > If you were to type < code > git init repo_name< / code > it would
create a new directory named < code > repo_name/< / code > and then turn
it into a git repo.< / p >
< / section >
< section id = "configurations" class = "slide level2" >
< h2 > Configurations< / h2 >
@ -389,7 +426,8 @@ doing and why.</li>
< / section >
< section id = "lets-practice" class = "slide level2" >
< h2 > Let’ < / h2 >
< p > Let’ ’ < / p >
< p > Let’ ’
doing.< / p >
< ol type = "1" >
< li > navigate to the < code > git_intro_download/< / code > directory.< / li >
< li > initialize a git repo using < code > git init wiki< / code > < / li >
@ -398,7 +436,8 @@ doing and why.</li>
< li > write something< / li >
< li > stage it< / li >
< li > write a commit message and commit it.< / li >
< li > add some more files and edits and repeat steps 5-7 a few times.< / li >
< li > add some more files and edits and repeat steps 5-7 a few
times.< / li >
< / ol >
< / section >
< section id = "git-log---noticing-what-happens" class = "slide level2" >
@ -423,8 +462,9 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb10-1"><a href=
< / section >
< section id = "how-git-works" class = "slide level2" >
< h2 > How Git Works< / h2 >
< p > Please take notes in your wiki; saving, staging, and committing as
you go. Put each topic into it’ < / p >
< p > Please take notes in your wiki; saving, staging, and committing
as you go. Put each topic into it’
later.< / p >
< p > If you run into issues, please let me know and I’
help.< / p >
< p > I owe this approach to explaining git to < a
@ -433,24 +473,25 @@ Preston-Werner’
< / section >
< section id = "snapshots" class = "slide level2" >
< h2 > Snapshots< / h2 >
< p > When working with a project, you might want to know the history of
that project. A simple way to do this is to make copies or snapshots at
regular or important points.< / p >
< p > When working with a project, you might want to know the history
of that project. A simple way to do this is to make copies or
snapshots at regular or important points.< / p >
< blockquote >
< p > Imagine I am writing a novel. I start by writing “It was a dark and
stormy knight.” In order to avoid loosing my work, I save my working
version, and then make a copy to google drive called
< p > Imagine I am writing a novel. I start by writing “It was a dark
and stormy knight.” In order to avoid loosing my work, I save my
working version, and then make a copy to google drive called
< code > novel-(date1).docx< / code > . Later I decide to fix my error and
change it to “It was a dark and stormy night.” I then save my working
version and make a second copy < code > novel-(date2).docx< / code > .< / p >
change it to “It was a dark and stormy night.” I then save my
working version and make a second copy
< code > novel-(date2).docx< / code > .< / p >
< / blockquote >
< / section >
< section id = "storing-objects" class = "slide level2" >
< h2 > Storing Objects< / h2 >
< p > This is the basic way git works. Each time a file is committed, a
copy is saved to a hidden directory in the < code > .git< / code > folder.
Staging the file marks that you want to save the current version of the
file.< / p >
Staging the file marks that you want to save the current version of
the file.< / p >
< details >
< summary > Explore< / summary >
In your wiki, stage a change for a file.
@ -459,52 +500,54 @@ Now change the same file, and check 'git status' again.
The old version is staged, but the new one is not.
< / details >
< / section >
< section id = "how-does-git-name-each-file-version" class = "slide level2" >
< section id = "how-does-git-name-each-file-version"
class="slide level2">
< h2 > How does git name each file version?< / h2 >
< p > There is a computer science tool called a < a
href="https://en.wikipedia.org/wiki/Hash_function">hash function< / a > . It
allows us to give each version of a file a (nearly) unique name that
depends on the file’ < / p >
href="https://en.wikipedia.org/wiki/Hash_function">hash
function< / a > . It allows us to give each version of a file a (nearly)
unique name that depends on the file’ < / p >
< ol type = "1" >
< li > Navigate to the < code > bash_exploration/< / code > directory.< / li >
< li > run < code > sha1sum c.txt< / code > < / li >
< li > Does it match
< code > cf44e4a24958c62790979deaad545d23c8fbe98e< / code > ?< / li >
< li > Edit < code > c.txt< / code > by removing the ‘ ’ first
line.< / li >
< li > Edit < code > c.txt< / code > by removing the ‘ ’
first line.< / li >
< li > What is the new sha1sum?< / li >
< / ol >
< p > This is called a Content Addressible System, because we can address
each unique version of our content.< / p >
< p > This is called a Content Addressible System, because we can
address each unique version of our content.< / p >
< / section >
< section id = "incremental-snapshots" class = "slide level2" >
< h2 > Incremental Snapshots< / h2 >
< p > Imagine if I had 100 different files, and I was taking full snapshots
each time I changed one or two of them. I would end up with a lot of
copies of the same content.< / p >
< p > If I wanted to save on storage space, I could instead copy just the
versions that I changed.< / p >
< p > Imagine if I had 100 different files, and I was taking full
snapshots each time I changed one or two of them. I would end up
with a lot of copies of the same content.< / p >
< p > If I wanted to save on storage space, I could instead copy just
the versions that I changed.< / p >
< p > This is what Git does. Each snapshot contains just a list of the
staged files, i.e.
important way.< / p >
< p > This is done by saving the staged objects with SHA1SUM names, and
then writing a small file that contains the filenames and SHA1SUM names
of the change. This is what committing a change does.< / p >
then writing a small file that contains the filenames and SHA1SUM
names of the change. This is what committing a change does.< / p >
< / section >
< section id = "constructing-a-dag---commit-parents" class = "slide level2" >
< section id = "constructing-a-dag---commit-parents"
class="slide level2">
< h2 > Constructing a DAG - Commit Parents< / h2 >
< p > Now notice one problem with Incremental Snapshots. If I miss a
snapshot somewhere, I am left without those changes. So, I need a way to
know which previous snapshots are required to get to a specific
state.< / p >
snapshot somewhere, I am left without those changes. So, I need a
way to know which previous snapshots are required to get to a
specific state.< / p >
< p > The solution is to allow commits to include information on
< strong > ‘ ’ < / strong > commits. Now we can draw a graph of how we get
to a specific state.< / p >
< strong > ‘ ’ < / strong > commits. Now we can draw a graph of how we
get to a specific state.< / p >
< figure >
< img data-src = "./SimpleCommitDAG.drawio.svg" alt = "Simple Commit DAG" / >
< img data-src = "./SimpleCommitDAG.drawio.svg"
alt="Simple Commit DAG" />
< figcaption aria-hidden = "true" > Simple Commit DAG< / figcaption >
< / figure >
< p > < code > git log --graph< / code > describes the commit dag.< / p >
< / section >
< section id = "confusing-dags" class = "slide level2" >
< h2 > Confusing DAGS< / h2 >
@ -518,8 +561,8 @@ alt="Complicated Commit DAG" />
< / section >
< section id = "pointers-branches-tags-head" class = "slide level2" >
< h2 > Pointers (branches, tags, HEAD)< / h2 >
< p > In CS, a pointer is something that records an address to something
else.< / p >
< p > In CS, a pointer is something that records an address to
something else.< / p >
< figure >
< img data-src = "./ComplicatedCommitDAG_WithPointers.drawio.svg"
alt="Complicated Commit DAG with Pointers" />
@ -531,19 +574,20 @@ Pointers</figcaption>
< section id = "branches" class = "slide level2" >
< h2 > Branches< / h2 >
< p > A branch is a flexible marker that simplifies isolating work from
different parts of the codebase. It is used to track areas of work. For
example, if I:< / p >
different parts of the codebase. It is used to track areas of work.
For example, if I:< / p >
< ul >
< li > Wanted to experiment with something without messing with the main
code.< / li >
< li > Was trying to fix a bug and needed to add a bunch of debugging.< / li >
< li > Wanted to try implementing a specific advisor’
going all in on it.< / li >
< li > Wanted to experiment with something without messing with the
main code.< / li >
< li > Was trying to fix a bug and needed to add a bunch of
debugging.< / li >
< li > Wanted to try implementing a specific advisor’
before going all in on it.< / li >
< li > Try to incorporate all the work of a collaborator who’ ’
going to need to fix.< / li >
< / ul >
< p > When you create a commit, a branch will change to point to the new
commit.< / p >
< p > When you create a commit, a branch will change to point to the
new commit.< / p >
< blockquote >
< p > Branches are cheap, use them.< / p >
< / blockquote >
@ -554,16 +598,17 @@ commit.</p>
< ul >
< li > Marking releases or versions of software.< / li >
< li > Identifying a commit where an error was added.< / li >
< li > In Economics: Marking the version of an analysis you presented in
your dissertation.< / li >
< li > In Economics: Marking the version of an analysis you presented
in your dissertation.< / li >
< / ul >
< / section >
< section id = "head" class = "slide level2" >
< h2 > HEAD< / h2 >
< p > Points to the commit that your current working copy is based on.< / p >
< p > You may see a < strong > detached HEAD< / strong > error. No the revolution
hasn’
instead of a branch pointer.< / p >
< p > Points to the commit that your current working copy is based
on.< / p >
< p > You may see a < strong > detached HEAD< / strong > error. No the
revolution hasn’
specific commit instead of a branch pointer.< / p >
< / section >
< section id = "return-of-the-dag" class = "slide level2" >
< h2 > Return of the DAG< / h2 >
@ -585,8 +630,8 @@ Pointers</figcaption>
alt="Complicated Commit DAG" />
< figcaption aria-hidden = "true" > Complicated Commit DAG< / figcaption >
< / figure >
< p > Take a look at < code > commit 10< / code > . Notice how it has to handle
the cases where< / p >
< p > Take a look at < code > commit 10< / code > . Notice how it has to
handle the cases where< / p >
< ul >
< li > < code > Commit 5< / code > has removed < code > b.txt< / code > but
< code > commit 9< / code > hasn’ < / li >
@ -607,21 +652,23 @@ edits of <code>e.txt</code></li>
< / blockquote >
< p > This is called a conflict, where the same file has had different
changes happen in different branches.< / p >
< p > To handle this, Git asks you to resolve it, choosing what should be
kept or removed. Resolving a conflict is part of merging branches.< / p >
< p > To handle this, Git asks you to resolve it, choosing what should
be kept or removed. Resolving a conflict is part of merging
branches.< / p >
< p > Merging is the main skill we want to develop.< / p >
< / section >
< section id = "rewriting-history---the-dag-can-be-modified-kind-of"
class="slide level2">
< h2 > Rewriting History - the DAG can be modified (kind of)< / h2 >
< p > Because the DAG is just a bunch of records pointing to other records,
you can rewrite it, < strong > < em > BUT< / em > < / strong > if you rewrite a copy
of the DAG and your coworkers don’ ’
hurt.< / p >
< p > This is what advanced GIT consists of: rewriting the commit DAG so
that it clearly, cleanly, and consisely represents how the codebase
grew.< / p >
< p > We will only take the briefest of looks at one way to do that.< / p >
< p > Because the DAG is just a bunch of records pointing to other
records, you can rewrite it, < strong > < em > BUT< / em > < / strong > if you
rewrite a copy of the DAG and your coworkers don’ ’
for a world of hurt.< / p >
< p > This is what advanced GIT consists of: rewriting the commit DAG
so that it clearly, cleanly, and consisely represents how the
codebase grew.< / p >
< p > We will only take the briefest of looks at one way to do
that.< / p >
< / section > < / section >
< section >
< section id = "how-to-work-with-git" class = "title-slide slide level1" >
@ -665,7 +712,8 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb13-1"><a href=
< div class = "sourceCode" id = "cb14" > < pre
class="sourceCode bash">< code class = "sourceCode bash" > < span id = "cb14-1" > < a href = "#cb14-1" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > checkout < span class = "at" > -b< / span > < span class = "pp" > [< / span > < span class = "ss" > new_branch_name< / span > < span class = "pp" > ]< / span > < / span >
< span id = "cb14-2" > < a href = "#cb14-2" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > switch < span class = "at" > -c< / span > < span class = "pp" > [< / span > < span class = "ss" > new_branch_name< / span > < span class = "pp" > ]< / span > < / span > < / code > < / pre > < / div >
< p > In our wiki repo, let’ < em > spellcheck< / em > < / p >
< p > In our wiki repo, let’
< em > spellcheck< / em > < / p >
< pre class = "git" > < code > git checkout -b spellcheck< / code > < / pre >
< p > Now check which branch we are on< / p >
< div class = "sourceCode" id = "cb16" > < pre
@ -701,8 +749,8 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb18-1"><a href=
< span id = "cb18-7" > < a href = "#cb18-7" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > log < span class = "at" > --oneline< / span > < / span >
< span id = "cb18-8" > < a href = "#cb18-8" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > merge spellcheck< / span >
< span id = "cb18-9" > < a href = "#cb18-9" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > log < span class = "at" > --oneline< / span > < / span > < / code > < / pre > < / div >
< p > This is called a fast-forward merge and occurrs when branches don’
have conflicts.< / p >
< p > This is called a fast-forward merge and occurrs when branches
don’ have conflicts.< / p >
< / section >
< section id = "creating-conflicts" class = "slide level2" >
< h2 > Creating Conflicts< / h2 >
@ -732,11 +780,12 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb19-1"><a href=
class="sourceCode bash">< code class = "sourceCode bash" > < span id = "cb20-1" > < a href = "#cb20-1" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > status< / span >
< span id = "cb20-2" > < a href = "#cb20-2" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > nano< / span > favorites.txt< / span > < / code > < / pre > < / div >
< p > Note the symbols “< < < < < ” “======”
“> > > > > ”. These tell us what the differences are between
the commits< / p >
“> > > > > ”. These tell us what the differences are
between the commits< / p >
< p > To resolve the commit:< / p >
< ul >
< li > we edit the files in conflict to get what we want from them.< / li >
< li > we edit the files in conflict to get what we want from
them.< / li >
< li > stage the changes.< / li >
< li > commit the merged files.< / li >
< / ul >
@ -755,22 +804,22 @@ color. Notice that spellcheck didn’
< li > Resolve the merge.< / li >
< li > merge main into spellcheck at some point.< / li >
< / ul >
< p > Why would normal practice be to merge your release branch into your
development branch, then merge back?< / p >
< p > Why would normal practice be to merge your release branch into
your development branch, then merge back?< / p >
< / section >
< section id = "introducing-a-normal-workflow" class = "slide level2" >
< h2 > Introducing a normal workflow< / h2 >
< p > Usually, you have branches that represent releases and branches that
represent areas you are working on.< / p >
< p > Usually, you have branches that represent releases and branches
that represent areas you are working on.< / p >
< p > Consider the following branches.< / p >
< ul >
< li > < code > main< / code > : This is the branch that you are using to present
work that you consider somewhat complete, i.e. a first
draft of your data processing code, or the output data.< / li >
< li > < code > main< / code > : This is the branch that you are using to
present work that you consider somewhat complete, i.e.
a first draft of your data processing code, or the output data.< / li >
< li > < code > data_processing< / code > : This is where you write your data
processing code, e.g.
include a copy of a < code > .csv< / code > file or < code > .rdata< / code > file
that you will use in the analysis later.< / li >
include a copy of a < code > .csv< / code > file or < code > .rdata< / code >
file that you will use in the analysis later.< / li >
< li > < code > regression_analysis< / code > : This is where you develop the
analysis that you will apply to the data you have. This will require
pulling the most recent data to analyze.< / li >
@ -780,29 +829,32 @@ pulling the most recent data to analyze.</li>
< p > What this might look like.< / p >
< ol type = "1" >
< li class = "fragment" > init repo< / li >
< li > init repo< / li >
< / ol >
< ol start = "2" type = "1" >
< li class = "fragment" > write things such as README in main.< / li >
< li class = "fragment" > Create < code > data_processing< / code > branch< / li >
< li class = "fragment" > Get < code > data_processing< / code > to a working state
(committing along the way).< / li >
< li class = "fragment" > Get < code > data_processing< / code > to a working
state (committing along the way).< / li >
< li class = "fragment" > merge main into data processing, fix conflicts,
then merge< code > data_processing< / code > into main.< / li >
< li class = "fragment" > create a branch < code > regression_analysis< / code >
from main.< / li >
< li class = "fragment" > start writing your analysis, committing along the
way.< / li >
< li class = "fragment" > create a branch
< code > regression_analysis< / code > from main.< / li >
< li class = "fragment" > start writing your analysis, committing along
the way.< / li >
< li class = "fragment" > Notice that the data is incorrect.< / li >
< li class = "fragment" > checkout < code > data_processing< / code > < / li >
< li class = "fragment" > fix the error that is giving you the incorrect
data< / li >
< li class = "fragment" > merge the fixes into main with a helpful
description.< / li >
< li class = "fragment" > checkout < code > data_analysis< / code > and merge the
fixes from main.< / li >
< li class = "fragment" > finish your analysis with the corrected data< / li >
< li class = "fragment" > checkout < code > data_analysis< / code > and merge
the fixes from main.< / li >
< li class = "fragment" > finish your analysis with the corrected
data< / li >
< li class = "fragment" > push analysis to main.< / li >
< li class = "fragment" > Start a new branch < code > report< / code > and begin
writing your report.< / li >
< li class = "fragment" > Start a new branch < code > report< / code > and
begin writing your report.< / li >
< / ol >
< / section >
< section id = "view-from-main-street" class = "slide level2" >
@ -821,14 +873,14 @@ want to turn them into a single (nice looking) commit.</p>
< p > This is called squashing< / p >
< div class = "sourceCode" id = "cb22" > < pre
class="sourceCode bash">< code class = "sourceCode bash" > < span id = "cb22-1" > < a href = "#cb22-1" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > merge < span class = "at" > --squash< / span > [branch name]< / span > < / code > < / pre > < / div >
< p > For example, if we had 3 commits in spellcheck, we could squash merge
them into main by:< / p >
< p > For example, if we had 3 commits in spellcheck, we could squash
merge them into main by:< / p >
< div class = "sourceCode" id = "cb23" > < pre
class="sourceCode bash">< code class = "sourceCode bash" > < span id = "cb23-1" > < a href = "#cb23-1" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > switch main< / span >
< span id = "cb23-2" > < a href = "#cb23-2" aria-hidden = "true" tabindex = "-1" > < / a > < span class = "fu" > git< / span > merge < span class = "at" > --squash< / span > spellcheck< / span > < / code > < / pre > < / div >
< p > This is one way to rewrite the DAG. It depends on the fact that
branches are disposable. There is no need to keep a branch around after
it is squashed.< / p >
branches are disposable. There is no need to keep a branch around
after it is squashed.< / p >
< / section > < / section >
< section >
< section id = "remotes" class = "title-slide slide level1" >
@ -837,21 +889,22 @@ it is squashed.</p>
< / section >
< section id = "git-is-a-distributed-vcs" class = "slide level2" >
< h2 > Git is a Distributed VCS< / h2 >
< p > We have focused on the Version Control System portions of Git. Now it
is time to look at how to use it as a “distributed” VCS and how to
collaborate together.< / p >
< p > We have focused on the Version Control System portions of Git.
Now it is time to look at how to use it as a “distributed” VCS and
how to collaborate together.< / p >
< blockquote >
< p > Git originated as a tool to develop the Linux Kernel. It is now the
most popular VCS in the world. This is - in part - because people can
work on the same thing without getting in each other’ < / p >
< p > Git originated as a tool to develop the Linux Kernel. It is now
the most popular VCS in the world. This is - in part - because
people can work on the same thing without getting in each other’
way.< / p >
< / blockquote >
< p > Because Git is flexible, it supports many different workflows. When
you work with an established team, learn their workflow.< / p >
< p > Because Git is flexible, it supports many different workflows.
When you work with an established team, learn their workflow.< / p >
< / section >
< section id = "adding-a-local-remote" class = "slide level2" >
< h2 > Adding a local Remote< / h2 >
< p > A remote is somewhere that git will fetch commits from. A repository
can have more than one remote.< / p >
< p > A remote is somewhere that git will fetch commits from. A
repository can have more than one remote.< / p >
< blockquote >
< p > A local remote is a remote that is on the same computer, e.g.
separate HDD or USB drive.< / p >
@ -891,15 +944,17 @@ class="sourceCode bash"><code class="sourceCode bash"><span id="cb25-1"><a href=
< li > It already has a git repo on it.< / li >
< li > We are going to create a joint wiki.
< ul >
< li > Each person chooses a topic or two from their personal wiki.< / li >
< li > We will pass around the USB a couple of times, allowing people to
< li > Each person chooses a topic or two from their personal
wiki.< / li >
< li > We will pass around the USB a couple of times, allowing people
to
< ul >
< li > clone the repo< / li >
< li > add their topics< / li >
< li > push to the repo< / li >
< / ul > < / li >
< li > We will then divide into editing teams and I’ topic
or two that you will edit.< / li >
< li > We will then divide into editing teams and I’
topic or two that you will edit.< / li >
< li > As we pass the USB around, you’
changes.< / li >
< li > Talk as an editing team, but don’ < / li >
@ -917,8 +972,8 @@ in Hari-up</a></p>
< p > A Git Forge provides< / p >
< ul >
< li > A non-local git remote< / li >
< li > features such as bug trackers and wiki’ software
development.< / li >
< li > features such as bug trackers and wiki’
software development.< / li >
< / ul >
< / section >
< section id = "demo-git-forge" class = "slide level2" >
@ -941,9 +996,9 @@ development.</li>
< li > Merging to Main.< / li >
< / ul >
< blockquote >
< p > NOTE!!! I will be removing your access to this git remote sometime
after the lab is over. You will still have a local copy of the wiki
though!< / p >
< p > NOTE!!! I will be removing your access to this git remote
sometime after the lab is over. You will still have a local copy of
the wiki though!< / p >
< / blockquote >
< / section > < / section >
< section >
@ -956,10 +1011,10 @@ though!</p>
< ul >
< li > < p > I have used git to track my code for both data processing and
data analysis< / p > < / li >
< li > < p > If I were taking a class on econometrics where we have to code up
some analyses, I might keep track of it in Git. A folder for each
homework, tagging it right before submitting it. I would only use one
branch probably.< / p > < / li >
< li > < p > If I were taking a class on econometrics where we have to
code up some analyses, I might keep track of it in Git. A folder for
each homework, tagging it right before submitting it. I would only
use one branch probably.< / p > < / li >
< li > < p > I have used git to coordinate work for an econometrics group
project.< / p > < / li >
< li > < p > I use it to recover an analysis that I deleted by
@ -969,28 +1024,30 @@ accident.</p></li>
multiple computers.< / p > < / li >
< / ul >
< / section >
< section id = "what-should-you-continue-learning" class = "slide level2" >
< section id = "what-should-you-continue-learning"
class="slide level2">
< h2 > What should you continue learning?< / h2 >
< ul >
< li > < strong > .gitignore files< / strong > - Sometimes you don’
stage a whole class of files. A < code > .gitignore< / code > file tell git to
not to stage them. For example, if you are doing an analysis in python,
you might get a < code > __pycache__/< / code > directory. If you put a line
that says < code > */__pycache__/< / code > in your < code > .gitignore< / code > ,
it will not be suggested that you stage anything in that directory.< / li >
< li > < strong > Git LFS< / strong > - Saving large files that are not text can
be difficult, such as when you are saving < code > .pdf< / code > ,
stage a whole class of files. A < code > .gitignore< / code > file tell
git to not to stage them. For example, if you are doing an analysis
in python, you might get a < code > __pycache__/< / code > directory. If
you put a line that says < code > */__pycache__/< / code > in your
< code > .gitignore< / code > , it will not be suggested that you stage
anything in that directory.< / li >
< li > < strong > Git LFS< / strong > - Saving large files that are not text
can be difficult, such as when you are saving < code > .pdf< / code > ,
< code > .jpg< / code > , < code > .png< / code > ,< code > .xlsx< / code > ,
< code > .docx< / code > , or < code > .zip< / code > files. Any change will cause
the whole thing to be resaved, and this can quickly add up to lots of
storage being used. Git LFS does a couple of things to reduce how much
storage will be used.< / li >
< li > < strong > Branching Strategies< / strong > - Knowing how to setup and use
branches properly is a powerful thing. There are tons of blogs with
information from different companies explaining how they are doing
it.< / li >
< li > < strong > Advanced Merging and Rebasing< / strong > - There is so much to
do here.< / li >
< code > .docx< / code > , or < code > .zip< / code > files. Any change will
cause the whole thing to be resaved, and this can quickly add up to
lots of storage being used. Git LFS does a couple of things to
reduce how much storage will be used.< / li >
< li > < strong > Branching Strategies< / strong > - Knowing how to setup and
use branches properly is a powerful thing. There are tons of blogs
with information from different companies explaining how they are
doing it.< / li >
< li > < strong > Advanced Merging and Rebasing< / strong > - There is so
much to do here.< / li >
< / ul >
< / section >
< section id = "most-of-all" class = "slide level2" >
@ -1002,11 +1059,11 @@ do here.</li>
< figure >
< img data-src = "https://imgs.xkcd.com/comics/git.png"
alt="If that doesn’ ‘ ’ ’ ’
< figcaption aria-hidden = "true" > If that doesn’ contains
the phone number of a friend of mine who understands git. Just wait
through a few minutes of ‘ ’ think of
branches as…’ ’ will fix
everything.< / figcaption >
< figcaption aria-hidden = "true" > If that doesn’
contains the phone number of a friend of mine who understands git.
Just wait through a few minutes of ‘ ’
think of branches as…’ ’
will fix everything.< / figcaption >
< / figure >
< p > I’ < / p >
< / section >
@ -1015,18 +1072,18 @@ everything.</figcaption>
< ul >
< li > Git is a useful tool to keep track of software versions and
coordinate work.< / li >
< li > Most of the time you can get away with just memorizing some basic
commands and workflow< / li >
< li > Most of the time you can get away with just memorizing some
basic commands and workflow< / li >
< li > When things are hard, remember
< ul >
< li > The basic model of how it works. Try to figure out what went
wrong.< / li >
< li > DuckDuckGo search is your friend. Google might be as well.< / li >
< li > ChatGPT/Claude.ai are pretty good at explaining errors, commands,
etc.< / li >
< li > ChatGPT/Claude.ai are pretty good at explaining errors,
commands, etc.< / li >
< / ul > < / li >
< li > Don’ hard
to delete something from a Git repo.< / li >
< li > Don’
hard to delete something from a Git repo.< / li >
< / ul >
< / section >
< section id = "feedback" class = "slide level2" >
@ -1036,7 +1093,29 @@ to delete something from a Git repo.</li>
< li > What would you like to keep practicing?< / li >
< li > How could I improve this presentation?< / li >
< / ul >
< / section >
< section id = "license" class = "slide level2" >
< h2 > License< / h2 >
< p xmlns:cc = "http://creativecommons.org/ns#" xmlns:dct = "http://purl.org/dc/terms/" >
< a property = "dct:title" rel = "cc:attributionURL" href = "https://git.youainti.com/Teaching/git-introduction" > Introduction to Version Control Systems (GIT) for Economists< / a >
by
< a rel = "cc:attributionURL dct:creator" property = "cc:attributionName" href = "https://www.youainti.com" > Will King< / a >
is licensed under < a href = "https://creativecommons.org/licenses/by-nc-sa/4.0/?ref=chooser-v1" target = "_blank" rel = "license noopener noreferrer" style = "display:inline-block;" > CC BY-NC-SA 4.0< img style = "height:22px!important;margin-left:3px;vertical-align:text-bottom;" src = "https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1" alt = "" > < img style = "height:22px!important;margin-left:3px;vertical-align:text-bottom;" src = "https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1" alt = "" > < img style = "height:22px!important;margin-left:3px;vertical-align:text-bottom;" src = "https://mirrors.creativecommons.org/presskit/icons/nc.svg?ref=chooser-v1" alt = "" > < img style = "height:22px!important;margin-left:3px;vertical-align:text-bottom;" src = "https://mirrors.creativecommons.org/presskit/icons/sa.svg?ref=chooser-v1" alt = "" > < / a > < / p >
< / section > < / section >
< div class = "license-footer" style = "position: fixed; top: 5px; right: 5px; z-index: 1000;" >
< a href = "#" class = "license-icons" data-toggle = "license-tooltip" >
< img style = "height:16px; margin-left:2px;" src = "https://mirrors.creativecommons.org/presskit/icons/cc.svg" alt = "CC" >
< img style = "height:16px; margin-left:2px;" src = "https://mirrors.creativecommons.org/presskit/icons/by.svg" alt = "BY" >
< img style = "height:16px; margin-left:2px;" src = "https://mirrors.creativecommons.org/presskit/icons/nc.svg" alt = "NC" >
< img style = "height:16px; margin-left:2px;" src = "https://mirrors.creativecommons.org/presskit/icons/sa.svg" alt = "SA" >
< / a >
< div class = "license-tooltip" >
Introduction to Git for Economists by Will King is licensed under CC BY-NC-SA 4.0
< / div >
< / div >
< / div >
< / div >
< / div >
< / div >
@ -1199,6 +1278,24 @@ to delete something from a Git repo.</li>
RevealZoom
]
});
< / script >
< script >
Reveal.addEventListener('ready', function(event) {
var licenseIcons = document.querySelector('.license-icons');
var licenseTooltip = document.querySelector('.license-tooltip');
licenseIcons.addEventListener('mouseover', function() {
licenseTooltip.style.display = 'block';
});
licenseIcons.addEventListener('mouseout', function() {
licenseTooltip.style.display = 'none';
});
licenseIcons.addEventListener('click', function(e) {
e.preventDefault();
});
});
< / script >
< / body >
< / html >
will king
2 years ago