basics

WestGrid Summer School

Marie-Hélène Burle
training@westgrid.ca
Understanding


3 components


Understanding


3 components


Understanding


What files are we talking about?


Understanding


Now, let’s consider the state of files


Understanding


When nothing is modified in the working tree…


Understanding


…we say that the working tree is “clean”


Understanding


Let’s create a new file


Understanding


It appears as modified


Understanding


To stage it, we run git add file1


Understanding


file1 is now ready to be committed


Understanding


When we commit, we take a “snapshot”, associated with a message


Understanding


Here is the command: git commit -m "<description of the commit>"


Understanding


Traditionally, the first commit looks like: git commit -m "Initial commit"


Understanding


We just took a snapshot of the project with file1 in that state


Understanding


Of course file1 is still in our working tree (the file didn’t go anywhere)


Understanding


But our working tree is clean: there are no uncommitted modifications


Understanding


What happens if we make an edit to file1 ?


Understanding


Or if we create a new file?


Understanding


The working tree is not clean anymore


Understanding


Git shows the new and modified files (with distinct labels)


Understanding


We can stage some or all of these changes


Understanding


For instance, let’s stage the edit of file1 : git add file1


Understanding


file1 moved from the modified to the staged state


Understanding


Let’s now make a new edit to file1


Understanding


As you can see, file1 now shows up in 2 states


Understanding


We don’t have to stage an entire file


Understanding


We can select hunks with git add -p file1


Understanding


The staging area is where the next commit gets organized


Understanding


We can pick and choose what to commit together


Understanding


This allows to archive snapshots with key sets of changes


Understanding


Instead of random mixed bags of changes


Understanding


A version of a file is only archived once it is committed…


Understanding


…as information in the staging area can be overwritten


Understanding


For instance, let’s make a new edit in file1


Understanding


and stage it with git add -p file1


Understanding


and stage it with git add -p file1


Understanding


Now let’s make a new edit in the same section


Understanding


and stage it with git add -p file1


Understanding


Our previous version of file1 (with edit3 ) is lost


Understanding


Once we commit (git commit -m "<message>" ) however…


Understanding


…that version enters the project history


Understanding


Not all files should be put under version control


Understanding


Source code and scripts should be version controlled


Understanding


but outputs shouldn’t as they can be reproduced easily


Understanding


Imagine that file2 is one such file


Understanding


We don’t want to have it clutter our working tree


Understanding


So we tell Git to ignore it by adding it to .gitignore


Understanding


This can be done in the terminal with echo file2 > .gitignore


Understanding


file2 was not deleted, but it has become invisible to Git


Understanding


In the meantime, we now have a new file: .gitignore


Understanding


You can treat it like any other file: stage it and commit it


Understanding


This archiving is nice, but how to return to old versions?


Understanding


We can’t do so now as we have uncommitted changes


Understanding


We need to commit or stash them first


Understanding


Stashing puts changes out of the way temporarily


Understanding


We stash with git stash push


Understanding


Our working tree is now clean


Understanding


So we can check out an old version of our repo


Understanding


Let’s return to our second commit


Understanding


First, we need to find its hash


Understanding


The hash of a commit is a unique string that identifies it


Understanding


You can list commits with hash, author, date, and message with git log


Understanding


Then you can checkout the commit: git checkout <hash 2nd commit>


Understanding


Now look very carefully at our working tree…


Understanding


B A M!


Understanding


Once we have checked out our second commit


Understanding


our working tree is back to that point in history


Understanding


If we want to go back to the latest version of our project


Understanding


all we have to do is to checkout our latest commit


Understanding


with git checkout <hash 3rd commit>


Understanding


Et voilà!


Understanding


Finally, to re-apply our stash, we run git stash pop