Mastering Git: From Fundamentals to Advanced Workflows

Name: Lecture 6: Version Control (git) (2020)
Uploaded: 2026-02-22T17:53:12.278271+00:00
Channel: Missing Semester
Description: Summary and key takeaways on Mastering Git: From Fundamentals to Advanced Workflows, covering Introduction This lecture provides a comprehensive overview of
Missing Semester
Feb 22, 2026
•
4 min read
YouTube video ID: 2sjqTHE0zok
Source: YouTube video by Missing Semester — Watch original video
PDF
Introduction

This lecture provides a comprehensive overview of version control systems (VCS) with a focus on Git. It starts with a quick reminder about office hours—students can ask about any lecture topic, past or present, at the 32‑G9 lounge in the Stata Center.
What Is Version Control?

Definition: Tools that track changes to files and folders over time, storing each state as a snapshot.
Benefits:
Recover old versions and understand why changes were made.
Work on multiple features in parallel using branches.
Collaborate with others, resolve conflicts, and attribute changes to authors.
Use Cases: Even solo developers gain safety and organization; teams use VCS for coordinated development, bug fixes, and feature integration.
Git’s Data Model

Tree Structure: A repository is a tree (top‑level directory) containing sub‑trees (folders) and blobs (files).
Commits: Each snapshot is a commit that stores:
A reference to a tree representing the project state.
Metadata (author, timestamp, commit message).
One or more parent commit IDs (multiple parents for merge commits).
Directed Acyclic Graph (DAG): Commits form a DAG, enabling branching and merging.
Objects and Content‑Addressable Storage

Object Types: blobs, trees, and commits are all objects.
Hashing: Objects are stored by their SHA‑1 hash (40‑character hexadecimal string). The hash acts as a deterministic identifier.
References: Human‑readable names (e.g., master, HEAD, origin/master) map to these hashes, allowing easy navigation.
Core Git Commands

Command	Purpose
`git init`	Create a new repository (`.git` folder).
`git status`	Show staged, unstaged, and untracked changes.
`git add <file>`	Move changes to the staging area.
`git commit -m "msg"`	Record a new snapshot from the staging area.
`git log`	Visualize commit history (linear view or graph with `--graph`).
`git diff`	Show differences between working tree, index, or commits.
`git checkout <hash\|branch>`	Switch the working directory to a specific commit or branch.
`git branch <name>`	Create a new branch reference.
`git merge <branch>`	Combine another branch into the current one (fast‑forward or true merge).
`git remote add <name> <url>`	Register a remote repository.
`git push <remote> <local>:<remote>`	Send local commits to a remote.
`git fetch <remote>`	Retrieve objects and refs from a remote without merging.
`git pull`	Shortcut for `fetch` + `merge`.
`git clone <url>`	Copy an entire repository (optionally shallow with `--depth`).
Branching and Merging Workflow

Create a branch (git branch cat), then git checkout cat.
Develop a feature (e.g., add a cat function) and commit.
Switch back to master, create another branch (git branch dog), develop a different feature, and commit.
Merge branches back into master:
git merge cat (fast‑forward if possible).
git merge dog (may produce a merge conflict).
Resolve conflicts manually or with tools (git mergetool), then git commit to finalize the merge.
Working with Remotes

Adding a remote: git remote add origin /path/to/remote.
Pushing: git push origin master (or set upstream with git branch --set-upstream-to=origin/master).
Fetching & Pulling: git fetch origin updates remote refs; git pull integrates them.
Cloning: Simulates another developer’s machine; each clone has its own .git directory but shares the same remote.
Advanced Features

Interactive Staging: git add -p lets you stage hunks selectively.
Stashing: git stash saves unfinished work; git stash pop restores it.
Bisect: git bisect performs a binary search through history to locate a regression.
Ignore Files: .gitignore prevents unwanted files (e.g., compiled binaries, OS metadata) from being tracked.
Blame: git blame <file> shows who last modified each line.
Configuration: git config customizes user name, email, UI colors, diff tools, etc.
Shallow Clones: git clone --depth 1 <url> fetches only the latest snapshot for large repos.
Tips for Effective Git Use

Write clear, concise commit messages (refer to the Pro Git guide).
Keep commits atomic—one logical change per commit.
Use branches for every feature or bug fix.
Regularly push to a remote to back up work and enable collaboration.
Leverage graphical clients or shell prompts for quick status overviews.
Resources

Book: Pro Git (free online, also available in print).
Lecture notes contain links to detailed tutorials, cheat‑sheets, and sample exercises.
Explore GUI tools (e.g., GitKraken, SourceTree) if you prefer visual interfaces.
The lecture equips you with both the conceptual model of Git’s internals and the practical command‑line skills needed to manage projects of any size.
Understanding Git’s underlying data model—objects, hashes, and the commit DAG—turns a seemingly opaque command line into a powerful, predictable tool for solo development and team collaboration alike.
Frequently Asked Questions

Who is Missing Semester on YouTube?

Missing Semester is a YouTube channel that publishes videos on a range of topics. Browse more summaries from this channel below.
Does this page include the full transcript of the video?

Yes, the full transcript for this video is available on this page. Click 'Show transcript' in the sidebar to read it.
What Is Version Control?

- **Definition**: Tools that track changes to files and folders over time, storing each state as a *snapshot*. - **Benefits**: - Recover old versions and understand why changes were made. - Work on multiple features in parallel using *branches*. - Collaborate with others, resolve conflicts, and attribute changes to authors. - **Use Cases**: Even solo developers gain safety and organization; teams use VCS for coordinated development, bug fixes, and feature integration.
Helpful resources related to this video

If you want to practice or explore the concepts discussed in the video, these commonly used tools may help.
Pro Git Book Recommended
Comprehensive guide to Git fundamentals and advanced workflows; essential for mastering version control now
Amazon →
Git Pocket Guide
Concise reference for everyday Git commands; perfect for quick look‑ups while working on projects
Amazon →
Version Control With Git (Physical Book)
Provides hands‑on examples and best practices for using Git in real‑world software development
Amazon →
Links may be affiliate links. We only include resources that are genuinely relevant to the topic.
Summarize another video
Full Transcript YouTube

alright let's get started with today's
lecture so actually before we get
started one quick note about office
hours it seemed from the poll that some
people were under the impression that
the office hours that follows each
lecture is just about that day's
lectures topics and this is not the case
you can come to office hours and ask us
questions about any lecture whether it's
the previous day or from the previous
week or even things not exactly covered
in this class that you're just curious
about so yeah come to office hours with
questions about anything office hours
are in the 32 g9 lounge so building 32
also known as a Stata Center has two
towers the G tower and the D tower so
we're in the gates tower on the ninth
floor so if you take the elevator all
the way up there's the lounge right in
front of you okay cool so today we're
going to be talking about version
control systems so I just want to get a
sense of whether you guys have used
version control systems before so could
you raise your hand if you have any
experience with git or any other version
control system like subversion or
mercurial or anything else oh great so
that's a good number of you so I won't
talk about version control systems in
general way too much then we'll pretty
quickly get into the details of git and
like it's data model and its internals
but just as a quick summary version
control systems are tools that are used
to keep track of changes to source code
or other collections of files or folders
and as the name implies these tools help
track the history of changes to some set
of documents and in addition to doing
that they facilitate collaboration so
they're really useful for working with a
group of people on a software project
Virna control systems track changes to a
folder and its contents in a series of
snapshots so you capture the entire
state of a folder and everything inside
like a software project and you have
multiple of these in a series of
snapshots each snapshot encapsulate the
entire set of files and folders
contained within some top-level
directory and then version control
systems also maintain a bunch of
metadata along with the actual changes
to the content and this is to make it
possible to figure things out like who
authored a particular change to a
particular file or when was a particular
change made
and slow version control systems
maintain metadata like authors and
commit timestamps and you can also
attach extra messages to these snapshots
and things like that and so why is
version control useful
well it's useful even when you're
working on projects by yourself so you
can use it to look at old versions of
code you've written figure out like why
something was changed by looking at
commit messages work on different things
in parallel without conflicts by using
different branches of development or be
able to work on bug fixes while keeping
work on different features independent
things like that and so it's an
invaluable tool even if you're working
just by yourself even on a small scale
project like I think the instructors of
this course use git even on things like
homework assignments or class projects
even small scale things in addition to
our research or larger software projects
and then of course version control is a
really powerful tool for working with
other people so it's useful for sending
patches of code around resolving
conflicts when different people are
working on the same piece of code at the
same time things like that and so it's a
really powerful tool for working by
yourself or with others and it also has
a neat functionality to let you answer
questions that would otherwise be kind
of hard to answer like who wrote a
particular module in a software project
or who edited a particular line in a
particular software project why was this
particular line change when was it
changed by whom things like that and
version control systems also have some
really powerful functionality that we
might cover at the end of today's
lecture
or you can find the lecture notes if we
don't have time to do things like
supposed to have some project you've
been working on for a couple years and
then you notice that some funny thing
about the project was broken like you
have some unit test that doesn't pass
anymore and it wasn't broken just now it
was broken some time ago and you don't
know exactly when this regression was
introduced well written control systems
have a way of automatically identifying
this like you can take it and give it a
unit test that's currently failing but
you know was passing at some point in
the past and it can binary search your
history and figure out exactly what
change to your code made it break so
lots of really powerful fancy features
if you know how to use these tools
properly
there are a number of version control
systems out there and get has become
kind of the de facto standard for
version control so that's what we're
going to be covering in today's lecture
one comic I want to show you which was
on the screen before hand let me bring
it back up so this is an xkcd comic that
illustrates gets reputation so let me
read it out loud for you
this is good it tries collaborative work
on projects through a beautiful
distributed graph theory tree model cool
how do we use it no idea just memorize
these shell commands and type them to
sync up if you get errors save your work
elsewhere delete the project and
download a fresh copy so maybe some
people may not want to raise their hands
for this but raise your hand if you've
ever done this before
I certainly have when I was learning
this tool so good number of you here
have done this before so the goal of
this lecture is to make it so you don't
have to do this anymore unfortunately as
this comic illustrates gets interface is
a pretty terribly designed interface
it's a leaky abstraction and so for this
reason we believe that learning get
topped down starting with the interface
is maybe not the best way to go and it
can lead to some confusion it's possible
like this comic shows to memorize a
handful of commands and think of them as
magic incantations and why everything's
working all right it kind of works out
all right but then you have to follow
the approach of this comic whenever
things go wrong
so while git has an ugly interface its
underlying design and ideas are actually
pretty beautiful an ugly interface has
to be memorized but the beautiful ideas
underlying git can actually be
understood and once you understand gets
internals its data model which is
actually not that complicated then you
can learn the interface to get you
you'll have to memorize some things but
you can understand what exactly certain
commands do by understanding how they
manipulate the underlying data model and
so the way we're going to teach get
today is first talk about the data model
almost in abstract talk about how we
might model files and folders snapshots
of history and how they relate to each
other
then after that we'll walk you through
some get commands and then finally in
the resources and exercises will link
you to tutorials that'll teach you all
the specifics because there are lots of
different commands that you will need to
learn eventually any questions so far
about our teaching approach for today
cool great so let's get started there
are probably many ad hoc approaches you
could take to version control and I'm
guessing some of you may have done this
before like say you have some file or
folder we have a bunch of different
files corresponding system software
project and you want to track changes
you could just say every day make a copy
of that entire folder and give that
folder a timestamp when you want to do
things like collaborate with other
people you could take the entire folder
turned it into a zip archive and email
it to somebody and then whenever you and
your buddy are working on two different
features of a software project you can
work on them in parallel then one of you
emails the zip file to the other person
and then you manually copy and paste the
appropriate segments from their code
into your code so that eventually you
end up with one piece of code that has
both of your features in it this kind of
sort of works raise your hand if you've
done this before
I certainly have still a decent number
of you get let's us not do this sort of
thing
it is a well-thought-out model that kind
of facilitates these sorts of
interactions things that you might want
to do like tracking your own history on
your in project or collaboration or
things like that so git has a well
thought-out model that enables things
like branches and collaboration and
merging changes from other people all
sorts of neat stuff get models history
is a collection of files and folders
within some top-level directory so
you're probably familiar with this
abstraction just from files and folders
on your own computer and so here's one
example like you might have some
top-level directory I'll just call this
like root in parentheses and this
directory might have say a folder in it
called foo and this folder inside of it
might have a file called bar dot txt and
this might have some contents in it like
say this says hello world and then maybe
this top-level directory it has one
folder in it it caalso have another file
in it so say there's some other file
and this file also has some contents in
it all right
simple enough the terminology get uses
for these different things for files and
folders is this and the top-level thing
are called trees so this is a folder and
then these things what we normally call
files are called blogs all right ok so
now we have a model of files and folders
and this is a recursive data structure
trees can contain other trees and then
trees can contain both trees and files
obviously files can't contain trees all
right so now we have a model of files
and folders and the kind of top-level of
this thing the thing I've just labeled
root is the directory being tracked like
you might have some folder on your
computer corresponding to a software
project now how do you model history
once you have a model of files and
folders well you can imagine one way of
doing it which is you take a snapshot of
this entire thing and then history is
just a linear sequence of snapshots like
you might imagine that it's you can
almost think of it like you have copies
of the folder which are dated and
time-stamped well it doesn't use a
simple linear model like that it uses
something a little bit fancier you might
have heard this terminology before but
git uses a directed acyclic graph to
model history and this might sound like
a bunch of fancy math words but it's
actually not all that complicated
so in get each snapshot has some number
of parents and basically want to know
like what change preceded what other
change so suppose here I'm going to use
circles to refer to individual snapshots
this is the entire contents within this
tree so all the files and folders in my
project my entire project may be in some
state and then I edit some files and now
it's in some other state and then I add
some more files and that's in some other
state and every state points back to
which state preceded it this so far is a
linear history
but it lets us do something a little bit
fancier than this you can also from a
certain snapshot fork your history and
say I want to base changes off of this
version and create a new snapshot like
this so this way of modeling history
allows you to do things like okay I'm
working on my project this is my main
line of development I go up to here and
now I have two different tasks I want to
work on suppose on one hand I have some
fancy new feature I want to add to my
project and so I'm going to be working
on that for a couple days but separately
from that somebody's reported a bug to
me and I need to go chase down that bug
and fix it well instead of working on
all that stuff kind of concurrently at
the same time in the same line of
development
git has its way of branching the history
into two separate Forks and working on
different things in parallel temporarily
in a way that are unrelated to each
other so I could take this base snapshot
like my project is in some state where
it works and then from here I could
implement a new feature that creates a
new snapshot so this has the base
project plus a new feature so I'll do
like plus feature and then similarly
separately from this I could go back to
this original snapshot because I don't
want to do bug fixing while implementing
my new feature go here and then work on
my bug fix and create a different
snapshot so this has only the bug fix
but not the feature and then finally
once I've done these two separate things
in parallel eventually I want to
incorporate them all into my common
source code that has both the feature
and the bug fix so eventually I might
author a new snapshot by merging the
changes present in these two different
snapshots and so this one I'll have both
of these snapshots as parents and this
version here will have both the feature
and my bug fix so does it make sense why
get models history in a way that's a
little bit fancier than just a sequence
of snapshots of my files and folders why
I want to be able to support branching
to work on things in parallel and then
also merging to combine changes from
different parallel branches of
development question
yeah so that's an excellent point it
seems that when you merge things you
could create errors that weren't
anticipated you could imagine here that
this feature actually changes something
that makes this bug-fix redundant or you
could imagine this bug fix breaking this
feature or something like that oh that's
a really good point that's a something
known as merge conflicts and this is
something that git will try to do like
when you merge your parallel branches of
development it will try to automatically
combine the changes in a way such that
it retains all the important changes but
if it gets confused it will report a
merge conflict and then leave it up to
you the programmer to figure out how to
combine kind of concurrent changes to
the same files or things like that and
then get has some tools for facilitating
this any other questions great ok so now
we have a model files and folders and
then we have a model of history how
different snapshots of our code relate
to each other
one little detail here is that each of
these circles so they kind of correspond
to a snapshot like a tree with files and
folders but they also have a little bit
of metadata so like inside here we might
have like the author of this commit is
me and we might have other metadata like
some message associated with this commit
I might describe what kinds of changes
I've made that are present in this
snapshot but not the previous one
that is not really the chair class so
next we're going to talk about kind of
one level lower than this like how
exactly is this represented as a as a
data structure inside get and so I'm
actually going to write down pseudocode
because I think it's actually easiest to
understand this way so first we have
files so a log is just a bunch of bytes
so I'll say this is an array of bytes
okay then what is a tree remember that
this is just a folder of what are
folders they're mappings from the
filename or directoryname to the actual
contents and the contents are either
another tree like a subtree or the file
and then finally we have the last thing
there what I've been calling snapshots
so far and get terminology those are
called commits and so what does a commit
[Applause]
it's a bunch of stuff commits have
parents that describes what precede them
so in the case of most normal commits
they have one parent like what they came
from what merge commits can have
multiple parents so parents are an array
of commits and then I have some metadata
like the author and maybe a message
and then finally the actual contents the
snapshot which is a tree that's the
top-level tree corresponding to a
particular commitment so this is a
really clean simple model of history and
this is basically all there is to how
get models history any questions about
that all right so now we have that going
a little bit deeper let's talk about how
it actually stores and addresses this
actual data like at some point this
actually has to turn to data on disk
right so get defines an object kind of a
big standing term but an object is any
one of those three things so it's a blob
or a tree tree or a commit and then in
get all objects are content addressed
so what get maintains on disk and you
can actually we can look at this later
is a set of objects maintained as this
content address store so if you have any
one of these objects the way you put it
into this store is its key is the hash
of the object so like in pseudocode I
might say that to store a particular
object o what I do is I compute its ID
by taking the sha-1 hash of o and then I
put it into my objects map store it to
disk a quick show of hands who here
knows what a hash function is all right
so I'll quickly summarize basically a
hash function is you can think of it as
like this magical function that takes a
big piece of data and turns it into a
short string at a high level these are
used to or maybe that's like a
sufficient
clinician I won't go into too much more
detail here but you can ask me
afterwards if you're if you're curious
so basically they give you a way to name
a thing in a way that's kind of
deterministic based on the constants of
the thing it takes into thing as input
and gives you a short name for it and
then the opposite of stores load the way
we can load things from the store you
might have just guessed you can look
them up by their ID and this is just we
retrieve it from the object store by ID
and it gives us back the contents any
questions about this so far question
that's a good question what language is
it's all written in it's written in the
language I just made up so it's
pseudocode the get implementation itself
is a mix of C it's mostly C and then
some bash and Perl scripts I think any
other questions is this made-up language
clear enough or do I need to explain any
aspects of it great okay so blobs trees
and commits and get are unified in this
way they're all objects and also as you
might think given my description here
like it looks like commits contain a
whole bunch of other commits and contain
a snapshot and things like that in
practice it doesn't actually work that
way instead all these are pointers so a
commit will be able to reference a bunch
of parents by their IDs so this is
actually not an array of commits
themselves but IDs and similarly the
snapshot inside a commit is not the
actual tree object it's the ID of the
tree and so all these objects are kind
of stored on their own in this object
store and then all the references to
different objects are just by their ID
by their sha-1 hash does that make sense
you can almost in your head map it to
like these are objects in a programming
language like Java and then this is a
reference to a tree so it's like a
pointer and then that is your realm
maybe this naughty helps maybe it
doesn't
yeah yeah exactly so I'll just repeat
that for everybody to hear on the
microphone
this is gets on disk data store it's a
Content address store where objects are
addressed by their hash all right any
questions about that so far ok so now we
have a way of identifying we've unified
all the different types of objects into
one type of thing we call object and we
have a way of identifying objects by
their sha-1 hash what do these actual
sha-1 hashes look like well they're
hexadecimal strings that are 40
characters long
like sha-1 is a 160-bit hash and so one
of the actual IDs returned by that sha-1
function is going to be a really long
string and so given that we'll have ways
of identifying these different things
like this we'll have corresponding to it
an ID like for a 3-2 CEB or something
something so now we have a way of naming
everything in this commit graph but
these names are really inconvenient
because they're super long and they're
like text strings they're not meaningful
to humans in any way so it's solution to
this problem is one other thing so get
maintains a set of objects and then it
maintains a set of references what our
references here I'll erase this bit on
the left this parts pretty logical
that's the irony another time so
references all right here
so this is another piece of data that
get maintains internally references is a
map from string to string and you can
think of this as mapping human readable
names like I might have a name like fix
encoding bug fix - encoding - bug is a
human readable name and this would be
maps to like that long hexadecimal
string there and so with these
references and you can imagine how we
might have ways of creating new
references and updating references and
things like that
with this I can now refer to things in
my commit graph by name so I might have
the same be called like fix bug or I
might have a name for something over
here things like that and so yeah with
this skit can use human readable names
to refer to particular snapshots in the
history instead of these long
hexadecimal strings one other thing to
be aware of here is given gits design
for history this entire graph is
actually immutable you can add new stuff
to it but you can't actually manipulate
anything in here I won't go into the
details of exactly how or why but just
assume that that's the case however
references are immutable so as you're
updating the history like suppose you
keep working on this piece of software
you create a new commit so I'm
representing that by the circle this
points to the previous commit I can
actually have say my fixed bug reference
is pointing here I can update this
reference to now point over here however
I can't for example make this point over
here that's not even a meaningful thing
to say because this is just the hash of
this object to change this hash I'd need
to change the contents of the object
which doesn't really make sense
all right any questions about that so
far that's basically it forgets data
model and then we'll go into actually
interacting with get via the command
line and we'll see how git commands
correspond with manipulations of a graph
data structure so any questions about
modeling history as trees of trees and
blobs and then snapshots these things
called commits being chained together
and you have references that can point
to particular nodes in this graph cool
no questions so basically once we have
objects and references like that's
basically all there is to a git
repository those are the two pieces of
data that it stores and at a high level
all get command line commands are just
manipulations of either the references
data or the objects data okay so for the
rest of this lecture I'm going to go
through some git commands it's basically
going to be an interactive demo similar
to the vim lecture and then you can
refer to the notes for full information
on these commands look of course it's a
really powerful tool we can't cover
everything in what 20 minutes all right
so I'm going to go over to this folder
called playground and I'm going to make
a new directory called demo CD into demo
and this directory is going to represent
the top level of my project it's
currently empty because I just created
it if I want to turn this into a git
repository I use the git init command
get in it stands for git initialize and
we see that it says initialized empty
git repository in blah blah slash dot
git if I do LS I still see nothing but
if I do LS - a there's a hidden file in
this directory called dot git if I do LS
get there's a bunch of stuff in here
this is the directory on disk where it
gets stores all of its internal data
namely the objects and the references
and you actually see here objects and
refs as two directories in here and
all the repository data will be stored
underneath those two directories one
letter command to keep in mind as we're
going through these is something called
get help get help takes a sub command as
an argument it gives you some help on it
so if I do get help in it for example
it'll tell me about the git init command
so now there are some commands for
figuring out what's going on with a git
repository like git status at a high
level says what is going on right now
and we see here let's ignore the first
line for now the second line says no
commits yet that's because we just
initialized a fresh repository and so
there is no history yet I'm actually
going to does anybody still want this
are kind of clear this part of the board
I'm going to as we go along draw how the
underlying objects and references data
is changing when I type in certain git
commands so right now this picture or
lack of picture represents the current
state of our repository it's empty there
are no snapshots so let's fix that let's
add something to our history here we
have no files so let me just go ahead
and create a file hello.txt with the
content hello world normally you'd have
your source code with actually useful
stuff in it now what I want to do is I
want to take the current contents of
this directory and turn it into a new
snapshot to represent say the first
state my project was in you might
imagine an interface for doing this
where there is like a git snapshot
command or get something else command
which takes a snapshot of the entire
state of the current directory for a
number of reasons git doesn't have a
command that works exactly like that
because git wants to give you a little
bit of flexibility as to what changes to
include in the next snapshot you take
this is something that's kind of
confusing to beginners sometimes so I'll
try to explain it right now git has a
concept of something called a staging
area and at a high level it's where you
tell git what changes should be included
in the next snapshot you take if we do
get status here we'll see that git says
no commits yet like it said before and
it says untracked files hello Tex
so this is saying that get notices that
there's a new file in the current
directory but it is not going to be
included in the neck
snapshot gets kind of ignoring it for
now but if I do get ad hello text and if
I do get status again it says now
changes to be committed new file
hello.txt and so now if I do the get
snapshot command which is actually get
commit which creates a new one of those
circles I drone the board over there
this file will be included in that
snapshot I'm I take so let me go ahead
and run git commit what this does is it
pops up my text editor and it lets me
type in a message that will be
associated with this commit and it's
really good to write high-quality commit
messages because then later when you're
looking back at your products version
history you'll know why you made certain
changes I'm going to add this relatively
useless commit message but we have a
link in the lecture notes for a guide on
how to write high-quality commit
messages so now that I've done that get
prints out some output master ignore
that bit for now this thing is the hash
of the commit I just created so now I
have in my history a single node this
has in it a tree that has a single blob
a single file hello.txt with the
contents hello world and then this has
the sha-1 hash for 2fb
something something something it's
actually truncated in the get interface
as well this is just printing out my
commit message again and it says as a
reminder I just added hello dot text and
so now if I use the git log command so
the git log commit is really useful in
that it helps you visualize the history
the the commit graph if I do question
that's a great question so the question
is what exactly does this hash
correspond to so this is the hash of the
commit the commit contains inside of it
the hash of the tree along with whatever
other information so I can actually use
get cat file - P this number this is
kind of like a get internals command
that will print out the contents of this
commit so you can see this kind of maps
to
data structure I drew on the board over
there so this commit has inside of it
this tree and then I'm the author and
this is the commit message and so on and
I can continue digging down here so you
can take this hash of this tree and do
get cat file - P this hash here it says
that this tree has inside of it a single
entry hello text and that file has it's
a blob and it has this hash I can do get
cat file - P this thing and it will show
me the actual contents of that file so
these are like internal git commands to
explore objects in the object store
question that's a great question so the
question is why did I have to use get
add why can't you just commit all
changes and the answer is well there
kind of is a way to commit all changes
if you do get commit - a this commits
all the changes that were made to files
that are already being tracked by git so
anything that was included in the
previous snapshot but has been modified
since then it doesn't include new things
there's also variants of git add like if
you do get add colon slash this will add
everything in the top from the top level
down of your repository but at a higher
level the reason we have this separation
between git add and git commit and why
get come it doesn't just snapshot the
entire directory is that they're often
situations where you don't want to
include everything in the current
snapshot like here's a couple examples
one is that I might be packing on my
project and I go ahead and implement two
features maybe I don't want to have a
single snapshot that comes after this
one that's like I implemented feature a
and feature B maybe I want to create two
separate nodes in the history so that it
looks like first I implemented feature a
and then after that I implemented
feature B so I have one snapshot that
only includes a and then the next one
includes both a and B git add is a tool
and like the staging area in general is
a tool that will allow me to do that
sort of thing
another example is suppose I'm working
on a bug fix and I have printf
statements I've put all over my code and
then finally I find the bug and there's
a plus one somewhere where there
shouldn't be a plus one so go fix that
and then I want to take a new snapshot
right with my fix
but the snapshot probably should include
all of my print statements it just needs
to include the fix of removing that plus
one so one way I could solve that issue
is I can go in
annually remove all the print statements
but it has a much better way of doing
that there's actually a way to specify
that I only want to add the change of
removing that plus one then I can commit
that take the new snapshot and then I
can throw away all the other changes
there are commands for doing that and
some of them are linked in the lecture
notes so those are two ways in which you
can use the staging area to help you and
why there isn't just like a snapshot
everything command yeah so mm-hmm yeah
John John points out the yeah yet
another example is you might have log
files in your current directory that
your program runs when you run it and
you probably don't want to include those
when you take a snapshot there's
probably other things like if you
compile your project you end up with a
bunch of dotto and like elf files you
probably don't want those to be part of
your history so going back to what I was
showing you before I'm going to clear
the terminal screen and then show you
the git log command so get logged lets
you visualize the version history and
this is an incredibly helpful command by
default git log shows you a flattened
version of the version history so even
though the version history is a graph
this will linearize it and just show
things in order i personally find that
confusing so I almost never use git log
and instead get log takes some arguments
that actually show the history as a
graph so you can treat this as a magic
incantation for now and you can read the
documentation if you want to figure out
exactly what each of those flags does
but for now this doesn't look all that
different because we only have one node
in our graph so visualizing it as a
flattened thing versus a graph doesn't
look all that different let me go ahead
and create a new snapshot and then we
can run this command again and then see
exactly what it does so I will put
another line into hello dot text and so
if I cat hello dot text it has the thing
it had before plus this I can do get
commit and notice this doesn't do
anything it just says no stained state
no changes staged for commit why is that
it's because I didn't add this to the
staging area I didn't tell yet but like
this is something that should be
included in the next snap
so if I do get ad hallo text get status
it says okay this change is ready to be
committed this modification to this file
and now I can do git commit I'm gonna
put in a useless commit message and the
new changes have been made and so now my
history has another note in it and then
this note has some hash that's shown on
the screen and now if I rerun that
command from earlier the git log with
all these arguments it actually starts
looking more like a graph here notice
that this is like that graph turned this
way the more recent so it's shown
vertically not horizontally and the more
recent commits are shown at the top this
is showing one commit it shows as commit
hash shows a bunch of metadata including
the commit message and then this is the
part I want to talk about next so
remember we talked about objects like
the actual contents of your repository
and then we talked about references ways
of naming things in the repository with
human readable names so master is one
reference that's created by default when
you initialize it get repository and by
convention it generally refers to like
the main branch of development in your
code so master will represent like the
most up-to-date version of your project
so here you can think of master as a
pointer to this commit and as we add
more commits this pointer will be
mutated to point to later commits then
we also see here head this is a special
reference and get it's a reference like
master but it's special in some way and
head basically is used to refer to where
you are currently looking right now any
questions so far yeah question
that's an excellent question so the
question is work with github before and
you have to create an account to do that
how does github relate to get and the
answer to that question is github is a
repository host for get so you can
create an account on github and store a
git repository there and use that to
collaborate with other people but git as
a command-line tool is just independent
from github so you don't have to use
github to use git you don't have to use
github declare it with get either like
there are other providers of git
repositories like bitbucket or get lab
or things like that and so yeah github
is a host for github repositories any
other questions yeah so the question is
if you want this repository to end up on
github how do you do that yeah there's a
separate set of commands for doing that
there's a so that concept of having your
local copy of version history interact
with another copy so the other copy is
called a remote and then their set of
commands for interacting with git
remotes and sending data from your
remote or from your copy to get remotes
and getting data from git remotes into
your local copy and we'll cover that
later in this lecture or maybe in the
lecture notes Ron might make a
supplemental video to go along with this
lecture any other questions okay a
couple other basic commands to show you
so so far I've shown you a version
history and we've taken a file and
modified it but we haven't really made
use of the history in any way besides
reading the messages so one useful git
command is something called git checkout
and this is a kind of wacky command it
lets you do a bunch of different things
but one thing it lets you do is move
around in your version history so one
thing I can do is give get checkout the
commit hash of a previous commit and I
don't need to type the whole thing I can
give it a prefix and it's
to figure out what I'm talking about and
what this will do is it will change the
state of my working directory to how it
was at that commit so here if I do cat
hello text recall that I had only one
line in here before at the first commit
and later I added that second line now
if I do that get logged command and this
command is super helpful like it shows
you all the things if I do this command
notice that this output looks a little
bit different than before like my actual
history contents the commits themselves
in the way they relate to each other and
all that have not changed but the
references have so notice that head is
down here even the master is still up
here so at high level what this is
telling me is this is what I'm looking
at right now if I want to go back here I
could type git checkout and this commit
hash
does anybody know a different thing I
could type here instead of this long
hash in order to go back to this commit
yeah you can give it the name of this is
a branch colored in green here and it
refers to this commit so I can give it
the short name or the human readable
name instead and now if I do cat hello
text notice that it has that second line
[Music]
yeah yeah so to repeat that git checkout
actually changes the contents of your
working directory and so in that way it
can be a somewhat dangerous command if
you misuse it for example you can see if
I modify hello text and then try that
get checkout command from earlier
actually notice here that it says error
it says there's a file that's been
modified and the git checkout would
destroy your modification you probably
want to do something about that but
there are flags like for example get
checkout - eff does this forcibly and
now it's throwing away my changes so
yeah get checkout has the potential to
well it certainly does modify things in
your working directory and it can
actually destroy changes if you're not
careful question
exactly yeah this is exactly what I want
you to be thinking about how these like
the crazy get interface commands
correspond to mutations to this graph
and mutations to the reference or like
additions to the graph in mutations to
the references map so yeah exactly
get checkout moves the head pointer and
then also mutates the contents of your
working directory with the contents that
the head pointer now points to of course
my name for that commit any other
questions all right so one other basic
command I want to show you is the git
diff command so I'm going to modify this
file and put some changes in it the git
diff command can show you what's changed
since the last snapshot it's just
helpful for like knowing what's going on
with your project git diff can also take
extra arguments like you can do git diff
and say compute a diff not with respect
to the last snapshot the last commit but
with respect to this and say ok two
lines have been added since this point
to hello dot text
question so your the question is what
does this command do without this extra
argument here that's a good question so
what this does is it computes a DIF with
respect to head and looking at my get
log hat is pointing to here so it's
doing a get diff with respect to this
commit and you can actually specify that
explicitly you can do get diff had
hollow text okay yes uh-huh
so that's a good question it's like how
can hello dot text be different than
head because head refers to where you
currently are so to clarify head refers
to the last snapshot so like in my
picture here had and master are both
here and the current working directory
is kind of independent of this like
you're going to delete all the files in
here it doesn't change the history graph
or the references and so yeah you can
have differences between here and here
and at a high level this is how you work
on a project like you make some changes
here you get add them to stage them and
then you get commit and that creates a
new snapshot here good question
any other questions yep
so the question is does get actually
save all this stuff kind of in the
obvious way or is it doing something
fancier the answer is is it is doing
something a little bit fancier but you
can it has an interface that lets you
think of it like it stored that way in
practice get uses Delta compression it
also does some other stuff but yeah the
on disk representation is actually
reasonably efficient question yeah
that's a good question so the question
is here we were comparing the current
working directory with a particular
snapshot in the past can we compare two
snapshots with each other like at two
different points in the history and yeah
I get diff can take yet another argument
here so I can for example compare head
with it did in the wrong order I can
compare what change from here to head in
hello text and it shows me that I added
the second line in there any other
questions
yeah so the question is you're working
on a shared project in a Dropbox folder
and anyone a migrate to get does it make
sense to turn the Dropbox folder into a
git repo do not use get inside dropbox
dropbox will corrupt your gate repo
there are good solutions to doing that
one is just use github otherwise I talk
to me after class and there ways of
using Dropbox as I get remote safely any
other questions
next we're going to talk about branching
and merging which is another powerful
feature of get that you almost certainly
use both when working on your own
projects and when collaborating with
others for this series of demos we're
going to rather than work with a simple
text file actually write a simple
computer program because it'll better
illustrate the concepts of branching and
merging and as we go through this
demonstration we'll keep in mind how the
get interface commands connect to the
underlying data model connect to objects
and references and how these commands
modify those two data structures let me
do a get status to see the current state
of my repository here I've modified
hello text I actually don't really care
about this modification anymore this is
some random file if I do get check out
folio text this is another different use
of the check out command which basically
throws away the changes that I've made
in the working directory and sets the
contents of hello text back to the way
it was in the snapshot that head points
to if I like it get logged - - all -
graft - - decorate it'll show me that
here I added the initial attacks and it
added that single line here and so now
whole text doesn't have that third line
I'd added it just has the original -
next time we should write a very simple
program we'll call this program and a
mold pie and let me just go ahead and
write a program that it prints a little
bit of output when I run it let's see
[Applause]
so when I run this program it runs main
mean calls default and then let me go
right ahead go ahead and define default
and default is going it's just going to
print hello so this is a program that
greets its user and so if I run animal
dot pi I'll see that it just prints
hello so that'll be our starting point
if I do get status it shows me that
animal dot hi is an untracked file to
begin with i want this to be part of my
part of the snapshot so i'm going to get
add animal dot hi to add it to the
staging area and do then do a git commit
here I'm going to write yet another
useless commit message don't actually
write commit messages like this in real
projects but for now this is fine so now
I have this basic animal dot pi and if I
look at my get history now I have this
latest snapshot this is the commit hash
and this is where the master branch is
pointing now we're actually way to
demonstrate how to use git branches to
have parallel lines of development they
get branch command or the branch
sub-command is used to access
functionality related to branching just
running git branch by itself lists all
the branches that are present in the
local repository it can also take an
extra argument - V V to be extra verbose
and print some extra information if we
do get branch and then specify the name
for a new branch git will create a new
branch which is just a reference that
points the same place where we're
currently looking so now there's a new
reference called cat reference in this
case is the same as branch there's a new
branch called cat which points to
wherever head was pointing if I look at
the git log again I'll see that here had
points to master masters over here and
this is also where the cat branches so
now I have two branches two references
that resolve to the same commit get is
actually aware of not only which
snapshot in the history are currently
looking at so had points to this commit
but it's also aware of had kind of being
associated with a with a branch so here
head is associated with master and it's
the case that if I create a new snapshot
if I type git commit at this point the
next snapshot will be created and
I'll point to that new snapshot master
will be updated along with head if I do
get checkout cat what this does is it
switches to the branch cat it replaces
the contents of the working directory
without with whatever cats pointing to
which in this case is the same as the
contents before but now if I look at the
git log again now I have head point to
cat instead of master and then master
also points to the same place the same
underlying commit and now at this point
if I make changes to my current working
directory and make a new commit the cat
branch the cat pointer will be updated
to point than you commit where as master
will continue pointing wherever it
pointed before so let me go ahead and
modify animal PI to add some cat related
functionality so I'm going to say that
if sISTAR V one is cat then run the cat
function otherwise run the default
function and then let me go ahead and
import define the cat function so cats
don't say hello them you know so cat
prints meow straightforward enough so
now if I run animal dot PI and give it
the cat argument it says meow if I give
it some other argument it defaults back
to the hello all right so simple change
I made if I do a get status that says
that animal that PI has been modified
Farren get diff it'll show me what's
changed since the last commit
so here I've added this cat function
highlighted in green then also change
the main function a little bit now here
if I do get add animal dot I get commit
I mean actually you write a slightly
more useful commit message this time I'm
going to add cat functionality and now
if I look at the git log I see a little
more stuff I'm going to show you one
more argument to this get logged command
there's an argument - - one line one
line spelled correctly which shows a
more compact representation of the graph
so sould be a more useful thing to use
because we're super zoomed into the
screen and there isn't that much space
to show a long commit history so here we
see the sequence of commits is still
linear and we have master still pointing
wherever it pointed before where we just
had the basic underlying animal top high
functionality but now we have this cat
branch which adds the cat functionality
we could for example get checkout master
to go back to the master branch and then
here if we look at animal dot pie it
doesn't have the cat functionality
anymore if we look at the git log we'll
see that head is pointing to master so
so we can jump back and forth between
parallel lines of development so now
that we have the cat functionality
suppose that we want to work on adding
dog functionality in parallel and
suppose that in this case like the cat
functionality is under development or
maybe somebody else is working on it so
we just want to start from the base
master commit and build the dog
functionality starting from there so now
what do I want to do I want to create a
new branch dog for adding the dog
related functionality and I'll
eventually merge it in later so I can
use the git branch dog command followed
by the git checkout dog command to
create a new dog branch and then check
it out there's actually a short form for
this get checkout - b-dawg so this does
get branch dog get checkout dog and now
if I look at my graph I have cat where
it was before master where it was before
but now head instead of pointing to
master as it did before now head points
to this newly created dog reference
which is also at the same commit so at
this base commit and now I'll go ahead
and add my dog functionality so let me
go and define my dog function dogs don't
say hello they say woof and then I'll
add some similar functionality here to
decide whether to run default or dog so
if the first argument is dog then I want
to run the dog function otherwise whoops
otherwise I want to run the default
function so here's what I've changed
with respect to the base commit wherever
master is pointing so I've added the dog
function and I've changed mean a little
bit so a kind of parallel modification
to what I did in the cat branch let me
go ahead and get add animal Titus add up
to the staging area if I do get status
I'll see that this change will be
committed when I make the next commit
and then I do get commit add
functionality now when I look at the get
graph it actually looks kind of
interesting compared to the ones we've
looked at before this shows that these
three commits
are in common with the ones that come
after it but then the history is
actually forked after this point and I
have this one commit that adds cat
functionality in one line of development
and then I have this other commit that
adds dog functionality in this other
line of development and then using the
git checkout command I can switch back
and forth between dog and cat and master
so this is great I can do development in
parallel on different features but this
is only really useful if I can
eventually combine those things back
into my original line of development to
have both features in a single version
of my source code so the command that's
used to do that is get merge so like get
branch and get merge can kind of be
thought of as opposites let me check out
get check out master let me check out my
master branch so now you see head points
to master and then I want to merge the
cat functionality and the dog
functionality into master and to do that
I can use the git merge command and get
merge is actually pretty fancy and I can
actually merge cat and dog at the same
time but for this demonstration we're
going to only merge one thing at a time
so first I'll type git merge cat and
gets us some stuff here it says
fast-forward so what is going on here
well this is one interesting thing that
get can do when you're at a particular
commit and you merge some other branch
in where that other branch has the
current commit as a predecessor it's not
necessary to create any new snapshots or
do any other fancy stuff basically this
this master branch here this pointer to
this commit can just be moved to point
here instead to incorporate that cat
functionality and so if we look at the
git log again we see that master is
basically pointing to the same places
wherever cat was pointing all right so
now we're on the master branch and it
has the cat functionality great we're
halfway there if we look at animal dock
by it has the cat functionality but it's
missing the dog stuff so let's try get
merge dog next something a little bit
more interesting happens this time so
this time the branch can't be fast
forwarded like it was before it's not
that one thing which is strictly older
than the other thing there's been
parallel development that may be kind of
incompatible with the current set of
changes and
it does its best job at automatically
merging the changes from this other
branch
so it says Auto merging animal dot pie
but in this particular case there's what
was what's called a merge conflict so it
wasn't able to automatically resolve on
the call the conflicts between these two
parallel branches of development and
this is something you'll see in practice
when you're working on real software
projects and they're complicated
slightly incompatible changes happening
in parallel so at this point it's left
up to the developer to fix this issue
and get offers some functionality in
order to help resolve merge conflicts
there's a program called git merge tool
and in my particular setup this will
launch vim diff actually this is not
configured them diff I think will start
the right program let me set up my get
to launch the correct tool actually
let's skip that part and let's just
manually look at this event if so
there's a program called vim diff which
can be set up to be launched when you
type in get merge tool which is a tool
that you use when you try get merged in
there merge conflicts but in this
particular case we'll just manually
resolve them
so let me I did get merge - - abort so
it put me back in the state I was before
I tried that git merge so this is the
current state of my repository I'm back
to the case where master is at the same
place as cat and I'm about to merge in
dog so I do get merged dog and it says
conflict merge conflict in animal Pi so
let's just look at animal dot PI
directly so it looks like this top part
looks pretty reasonable it has both the
cat function and the dog function which
is exactly what I want but now I see
some weird stuff in main and this is
where I add slightly incompatible
changes so here it says that in one
thing like basically the branch you were
on you had this content and then the
branch you're trying to merge had this
content and then these things here the
angle brackets and the equals our
conflict markers so this is where you
were and this is the thing you're trying
to merge in and it's basically saying
that it was this on one case this in the
other case and it doesn't really know
how to resolve
these two and it's left up to the
programmer to fix this problem so in
this particular case we can go ahead and
delete the conflict markers and then
turns out that we can actually
concatenate this code together and does
the right thing maybe we want to make a
small change like this should be an if
this should be an else--if and this
should be an else that might make a
little bit more sense actually I think
it's necessary for correctness here so
the programmer needed to modify the code
a little bit in order to make it
sensible when it's merged together but
once the programmer has fixed the merge
conflicts fixed the stuff between the
conflict markers you can save this file
and we can do get merged - - continue to
tell git that we fix the issues it's
necessary to re add animal PI to tell
git that we've actually fixed these
issues and then we need to get merged -
- continue it pops up an editor and we
can give a commit message for this new
commit that we're about to create and
now if we look at the git history we
have the single commit that represents
our merge commit that we just made which
merges in the dog functionality and here
this has as parents both the dog commit
and the cat commit
so both these branches appear in our
history from this point backwards and
this current commit that we're on
incorporates the functionality from both
of these branches so if we run animal
duck fight with cat it does the cat
thing if we run it with dog it does the
dog thing and if we run it with anything
else it falls back to the default
implementation so this is a
demonstration of how you branch and get
to do development on different things in
parallel and then how you can use the
merge command and get to resolve those
different branches and combine them
together into a single snapshot that
includes all the functionality that was
developed in parallel with each other
and then one thing that can happen when
you're doing get branching and merging
is you run into merge conflicts and
these conflicts show up as conflict
markers and text files you can manually
resolve them and kit also has some tools
that can help with this though these
tools are kind of advanced and will only
refer to them in the lecture notes and
not actually demonstrate them for you
so that's get branching and merging
any questions no great so moving on to
the next topic of this lecture we will
talk about git remotes so this is
basically how you collaborate with other
people using git a git repository the
stuff contained in this dot git folder
represents kind of an entire copy of the
history it has the objects in the
references and contains all the previous
snapshots and the way you collaborate
with other people using git is that
other people can also have copies of the
entire git repository and then your get
copy your local instantiation of the
repository can be aware of the existence
of other clones of the same repository
and this is a concept known as remotes
so the git remote command will list all
the remotes that git is aware of for the
current repository and in our case with
this repository right here this command
get remote just doesn't print anything
because we haven't configured any
remotes it is only aware of the single
local copy of the repository that we're
working with here but in practice if
you're collaborating with other people
your git might be aware of the copy of
the code that is on github and then
there's a set of commands to send
changes from your local copy of the
repository to a remote that your get is
aware of so sending stuff from your
computer to github for example and
there's another set of commands for
fetching changes made in a local
repository to get changes from github
into your own local copy in this
demonstration here we actually won't go
and configure a github account and log
in and create a new repository on there
you can find other tutorials for doing
that we'll actually just use a separate
folder on the same computer and treat it
like a git remote so let me I'm in the
demo folder here let me go up one
directory I have a directory called
playground that has this demo folder and
I'll go ahead and create a new directory
in here and I'll call it remote and then
do get in it - - bear in here those are
the command that you'll probably never
need to use in regular usage but now
what I've done is made remote into a
folder that's appropriate to use as a
git remote
so now going back into my demo folder
here might mean repository I can do get
remote to list the remotes
there's nothing yet but I can use the
git remote add functionality to make my
local repository aware of the existence
of a remote so I can do git remote add
and then the format for this is that
remotes have names and then they have a
URL so in this case I'll use the name
origin does often use by convention as
the name of the remote if you're only
using one and then for the URL normally
this will be like a github URL or
something like that or bitbucket URL or
get live URL if you're using an online
repository hosting service but in this
case it's just a path to a folder on my
local machine there's a folder in the
parent directory called remote that will
act as the git remote for this
repository so now once I've done that
there's a set of commands for
interacting with this remote one command
that's useful is the git push command
this command can send the changes from
your computer to the remote and the
format for this command is that git push
takes in the name of a remote and then
it takes in a local branch name : a
remote branch name and what it does is
it creates a new branch or updates a
branch on the remote with the name
specified here and sets it to the
contents of the branch specified here so
a concrete use of this might look like
git push I've only one remote called
origin and then what should I push let
me look at my history graph I have a
bunch of things I could push let me get
pushed to origin the master branch from
my local machine :
master so I want to create a branch on
the remote machine with the name master
that is going to be the same as the
master branch on my local machine so let
me go ahead and run that command it
prints out some stuff and it says on the
remote I created a new branch remote
master points to the same branch as
master on my local machine and now if I
do a git log it shows me so in blue is
head where I currently am in green are
all the branches in my local git
repository and now we see one new color
here that we had
seen before so in red get shows
references that are present on the
remotes that my local copy is aware of
so on the remote origin there's also a
branch that happens to have the name
master that points to the same place as
my local branch master points and so now
if I make updates to my local copies
like suppose here I go in and change the
capitalization of these things and then
get had animal dot hi get commit here's
a short form for commit with a message
so it doesn't pop up the editor I'll
give it a late and commit message and
now if I look at the git graph now I see
that I've created this new snapshot here
that has this lower casing stuff in it
but origin master is still back here so
if somebody else looks at the remote
they will only see the changes up to
here and we can actually demonstrate
this functionality so let me go ahead
and open up a new tab here and go into
my playground directory the git clone
command is a command that somebody can
use to start from some copy of a
repository somewhere and make their own
local copy so this is often a command to
use when starting out with a git repo
like there might be something available
on github and you want to copy it all in
your machine in order to look at it or
start doing development and so the
format for git clone is that it takes in
a URL and then it takes in a name for a
folder for where to clone it so in our
case here we're just going to clone from
this remote directory we're pretending
that this remote folder is actually a
remote machine and then we're all clone
it into the folder called demo two so
cloning into demo 2 done and I'm going
to CD into that directory and then now
here I'm going to rename these tabs at
the bottom I will say this one's machine
one and this one's machine too so you
can think of these as two different
people on different machines with their
own copy of the repository and they're
both interacting with the single remote
so if I do my get log command that I've
been doing on machine one I see on
Machine 2 I see this portion of the
history so master on machine 2 is
pointing to the same places origin
master
and it says merge branch dog so if I
look at animal dot pie here
it doesn't have the changes that I made
on machine to even though there are
sorry on machine one where I have this
new commit that is only present on this
machine but not on the remote and not on
machine too so if I want to fix that if
I want to send these changes up to the
remote like think of it as sending it up
to github err up to the machine that's
holding or maintaining the source code I
can use the git push command again git
push origin master colon master and this
will work but this is kind of annoying
to type every time you want to do this
like this is a really common operation
so git has a way of making this a little
bit simpler it has a way of maintaining
relationships between branches on your
own local machine and branches on remote
machines it is a way of knowing what
branch on a remote machine a local
branch corresponds to so that you can
type in a shortened version of git push
and it'll know what all the arguments to
the expanded form would have been and
there a couple different syntaxes for
doing this one way is to use the git
branch - - set up stream to command and
what this does is for the branch that's
currently checked out which is master it
will set the upstream - and I'll type in
origin master and see now it says branch
master set up to track remote branch
master from origin now if I type in get
branch - VV remember this is tell me
about all the branches that I know about
in a very verbose way that's what the -
VV means I have three branches on my
local machine on machine one I have cat
dog and master and master on my local
machine corresponds to origin master so
now I can type in just get push without
all the extra arguments I could have
done this as git push origin master
colon master but it wasn't necessary
it'll know that I want to push to origin
master and it will make that change
so now these changes are present on the
remote we can go over to machine to
pretend we're the other guy interacting
with this repository and if I do might
get logged command I still don't see the
changes so what's going on here
well it's necessary in order to run a
separate command
or it's necessary to run a separate
command in order to have these changes
present here by default all the get
commands don't talk to the internet it
all works locally which means it works
very fast but then there are special
commands for saying that you want to
retrieve changes that have made
somewhere else and the command that's
used for doing that is a command called
git fetch get fetch takes thee as an
argument the name of the remote but if
there's only one it'll just use that so
you can type in git fetch and then it's
talked to this remote repository and it
says that there's some update on the
remote and we can visualize it by
running git log and now we see here
another situation that we hadn't seen
before we have master on our local
machine the master branch doesn't change
the git fetch command doesn't change any
of our local history our local
references like our branches but now
it's aware that origin master has been
updated to point to this new commit and
there's a separate command we can do get
merge in order to move master up to here
or there's another command called get
pull which is the same as doing git
fetch and then get merge so if we just
do get pull here for example it will say
it's fast forwarding is merging in
origin master into our master and now if
we look at the git history graph we've
currently checked out master master
points to the same place as the origin
master that we're aware of and all the
changes between Machine 2 and Machine 1
are in sync so those are the basic
commands for interacting with git
remotes so there's the git remote
command for listing remotes and adding
and removing them and things like that
and then there's the git push command
for sending changes from your local copy
of the repository to the remote and then
there's the git fetch command which is
for retrieving changes to a repository
that are present on a remote and getting
the changes on your local machine and
once you retrieve those changes you can
use git merge to update your local
branch to point to the same place where
the remote branch does or you can use
the git pull command which does
basically the same thing as get fetch
plus git merge and then of course
separate from all these commands
is the clone command that we talked
about a little while ago which is for
taking a copy of remote repository and
initializing the local repository from
that copy so that's a quick overview of
the different commands used to interact
with git remotes and now these are kind
of complicated and it takes a while to
master all the different variations of
this and understand how they're actually
used in practice but hopefully this acts
as a quick introduction and you can see
how the different commands relate to the
underlying data model all these commands
all they do is fetch new objects from
other places or send objects from the
local mission to other places and these
commands mutate references so relating
these relating the interface of git and
some of these kind of badly designed
commands to the underlying data model
can help it make a lot more sense the
final topic we're going to cover today
is it's a kind of overview of other
things that get can do that we're not
going to go into detail in teaching you
how to do but we just want to tell you
that these functionalities exist in case
you need to do these things yourself you
can look up the documentation and find
out exactly how to do it one thing is
the git config command like a lot of
tools we've looked at like the shell and
T MUX and things like that
git is highly configurable and it's
configured using a plain text file which
can be edited either through the
command-line interface so git config can
take in flags that will modify this text
file or you can edit the dot git config
file in the home folder with plain text
configuration and so for this lecture
I've actually cut out most of them I get
config and only left in my username and
email for what will go in to get commits
but there's a lot of stuff you can put
in here which will make it behave nicer
it behaved the way you want it to and
you can look online for different ways
people have configured their get configs
oftentimes people have documentation in
their kit configs
which can be found on github there's a
couple other random commands that could
be useful one is for when you want to
clone a repository with git clone that's
really gigantic get cloned by default
copies the entire version history for
the remote it's downloading the
repository from but there's an argument
you can pass it which is - - shallow
which will avoid doing that so if
there's some copy of some code on github
say that you want to get a copy copy of
on your local machine but that
repository is really gigantic and has a
billion commits he's get cloned - -
shallow this will be much faster but
then of course he won't have the version
history on your local machine you'll
just have the latest snapshot another
command that we find really useful when
doing development on real software
projects is an interactive version of
the git add command so to demonstrate
this I'm going to go ahead and make a
couple different changes to my animal PI
one change I'll make here I'll change
some text here and then I'll put a new
print statement here so let's pretend
that this first change was some real
change I wanted to make say it's a bug
fix and this other change here was a
printf that I added for debugging but I
don't actually want to commit in the
next snapshot if I do a get diff it'll
show me that yes I've made these two
changes and if I do get add animal dot
pi it will stage both of those changes
for a commit and that's not what I want
I could go manually remove this debug
print and then do this get animal dog
get add animal dot PI but there's an
easier way to do it
there's this get add - pika man which
lets me interactively stage pieces of
files for it commit and so there's some
interface for working with this so here
it's saying do I want to stage both of
these changes and no I don't but I'm
going to split it into two smaller
changes this one I do want to keep so I
say Y for yes and this one I don't want
to keep so I say n for no and then if I
do get diff - - cached this will show me
what changes are staged for commit so
now it shows only the actual change I
wanted to keep if I do get diff it'll
still show me the other change that is
not going to be part of the next the
next commit which is the change I didn't
want to keep and then with this I can do
get commit specify some commit message
now I only have this change left and
then I can do get check out animal to
apply to throw away this change so get
add - P for interactive staging is a
useful thing a couple other commands
that you can look up on your own are the
get blame command so this commands kind
of ominous but it can be used to figure
who edited what line of a file and you
can also find the corresponding commit
that was responsible for modifying that
particular line of that file and then
you can look up commit messages
associated with that and whatnot so this
is not that interesting to do in our
current toy repository but I'll go over
to the repository for the class website
and we can look at some particular file
here and let me go to some particular
line here and I can be looking at this
me like oh why was this particular line
added what does it mean and I can look
at the git blame for this so if I do get
blame config dot yml it'll print out all
the lines kind of in the right column
and then in the left side it'll show me
what commits that change was made in and
by whom and then looking at this like I
can go down to this collections line it
was made in this commit that's the last
commit that modified that line and now I
can use the git show command to get
information for that particular commit
oh and this is kind of useful redo
lectures is a collection that's probably
what was related to that collections
line and then beyond just showing the
commit and the commit message it also
shows me the actual changes introduced
in that particular commit and they can
go look through them and understand
what's going on another kind of cool
command is a command called git stash so
let's go back to our demo repository and
demonstrate that here so say if some
changes here and I temporarily want to
put them away if I do get stash it will
revert my working directory to the state
it was in at the last commit so if I do
cat hollow text that change is gone but
it's not just deleted its saved
somewhere and if I do get stash pop it
will undo the stash so now if I look at
hello text it has the changes I made so
yet another useful command another
really neat command is something called
git bisect and this has a complicated
interface that we're not going to
demonstrate in detail but basically this
is a tool that can be used to solve a
bunch of problems where you need to
manually search history for something
suppose you're in a scenario where
you've been working on a project for a
long time you have lots and lots of
snapshots you're a thousand commits in
and then you notice that some unit test
doesn't pass anymore but you know that
this was passing like
year ago and you're trying to figure out
at what point did it break like at what
point was this regression in your code
introduced so one thing you could do is
manually check out like go back one
commit and see if the unit test is still
failing go back one commit see if it's
still failing and eventually you'll find
the first commit where the test stopped
working and it'll probably tell you like
what broke but that's kind of annoying
to do manually get by sight automates
that process and it actually binary
searches your history so it does this in
the most efficient way possible and not
only that get bisect can take in a
scripts that it uses to try to figure
out whether a committed looking at is
good or bad so it can be a fully
automated process like you can give git
bisect a unit test and say find the
first commit where this unit test
stopped passing it's a really powerful
tool another random thing that's kind of
useful is something called a git ignore
file so by default if you have random
files in a directory like let me create
the dot d s underscore store file whoops
create the dot d s underscore store file
and then do git status so D s stores
like some nuisance file that Mac OS
creates I don't know exactly what goes
in here but basically once this file is
in this directory now whenever I do get
status it says oh there's this new file
that I've never heard of it before but
it apparently here like do you want to
add it and this sort of tough stuff gets
annoying and there's a lot of other
stuff beyond OS specific garbage that
might be in a directory like for example
if you're working with C code you might
compile it and produce dot o files or
executable files or things like that and
you probably don't want binaries to be
part of your commit history you only
want the source code and so git has a
way of you being able to tell the tool
that you don't care about a particular
set of files and to ignore them and
that's something called a git ignore
file so if I go and modify the file
called git ignore in the current
directory I can specify particular file
names or patterns of file names like say
I can specify star dot o so any file
ending in dot o along with da store and
now if I touch food oh and now do a get
status
I'll see that git says okay I've
hollowed out tax which I've modified
sure and
and I have get ignore so you should
track your get ignore file using it but
notice that it doesn't mention my dot d
s store file or my food out o file
that's present in the current directory
because that has been get ignored so
that's a quick overview of a little bit
of advanced get functionality just to
give you a flavor of what sorts of cool
things this tool can do and then finally
we have a couple other topics that are
covered in the lecture notes in more
detail I'll just quickly list them here
so you know what to look for one is that
there are many graphical clients forget
we don't personally use them we like the
git command line tool but some of them
are kind of ok and you might want to
check them out just to see if you prefer
using those another thing is shell
integration so you've noticed that in
this tutorial I've done get status a
whole bunch to see kind of what's going
on with my repository well that's kind
of annoying to do and a lot of people
have their shell prompts set up so that
just within this shell prompt itself
like on every line it will show me a
very succinct summary of what's going on
with my repository so it might show me a
summary of what branch I have currently
checked out along with maybe if I've
modified files or untracked files and so
we have a link in the lecture notes on
how to get some nice shell integration
for displaying kind of get related
information in your shell prompt similar
to that you can get integrations with
your text editor so for example I use
vim and I have a plug-in for vim that
does all sorts of interesting get
related stuff one thing I can do with
this plug-in is look at get blame
information remember we just looked at
this through the command line instead I
can look at it with this plug-in and it
lets me work with it a lot faster I can
look at get blame press enter when
hovering over a specific commit and it
shows me that particular commit in my
text editor it even hides all the other
files and shows me just the one file I
was looking at which is presumably what
I care about so we have links to that in
the lecture notes as well and there are
a couple of there interesting things you
could look at there if you're interested
finally this lecture by itself is
probably not enough to teach you
everything you need to know about git
it's a good start we think that the
right way of learning get was to learn
about
the underlying data model the whole
objects and references and how get
models history and then we gave you an
introduction to using the git commands
and if you want to become really
proficient at this tool in the resources
section in the lecture notes for today
we have a link to a book called pro git
so this is a free book it's nicely
written it's pretty short and I think
going through the first couple chapters
of that book should teach you basically
everything you need to know in order to
use get proficiently for real software
projects and for contributing
it's a project on github and things like
that and then finally just like all the
other lectures we have a number of
exercises you can go to go through if
you want some interesting and
challenging problems that you can figure
out how to do