Lecture 6: Version Control (git) (2020)

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

Channel: Missing Semester

Views: 515,045

Rating: 4.9671111 out of 5

Keywords: mit, lecture, tools, command-line, git, vcs, version-control, github

Id: 2sjqTHE0zok

Length: 84min 59sec (5099 seconds)

Published: Sat Feb 01 2020