Hi, in the future lesson, we're going to be
working on importing our code into our environment. Now, in this lesson
we're going to be using Git and GitHub to
pull the source code. I'll also share a couple
of tips and tricks, that'll make our lives
a little bit easier throughout this project. After this lesson, you'll be able to use GitHub to get the source code,and you'll be able to navigate and clone
the repository. Now if you're familiar with Git, you can skip
this video completely, since it's not central
to the course. However, if you're
unfamiliar with Git watch this video along with the Git
basics and their resources. So if you're ready,
let's get started. So the first thing we
want to do is we're going to clone the repository. Now, to get to the repository you can go
to github.com/ucdavis. If you go to just /udcavis, you can simply search for WebGoat in the finder
repository search field. It may not always be on the
top like it is right now, because I've recently
pushed code into it. When you come in here, there's a clone or
download button. You're more than welcome
to download the ZIP, and not even have to
use Git to do this. But if you do use Git and if you have the Git utilities
installed on your machine, you get to do a couple of tricks as we go through this project, to make the management of it
a little bit easier. So I'm going to simply
type in git clone and type in the project
file and let it download, now depending on how
fast your Internet is, this could take a couple minutes, it's a little bit on
the larger side for our project. Now that you've cloned
it over to your machine, you can simply navigate to it. I'm going to open up
this folder in my text editor, not an IDE necessarily, because I want to simulate
making changes to a file, we're not going to be doing
anything interesting. But I want to show you
some changes you want to keep, some changes maybe you
don't want to keep, and Git can make that
very easy for us. So I'm going to open this in my text editor and only just so we can make
some simple changes to it. So let's go down to the lessons, the introduction,
the source of it, the resources, and
under lesson plans. So there's this adoc that
we've played with a couple of times,and there's bunch
different texts in here. You could think of
it as source code, we could have just as easily
opened the owasp, webgoat, plugin page where we
opened this bit of code, and we do something that's
part of the lesson plan. So let's say instead
of getting the title, we wanted to return the titles. We run our code, we compile it, and it's what we expected
everything's working fine. So we kind of want
to create a snapshot or a checkpoint for ourselves. So that future changes we make, they may break this, we may lose track of
all the changes we made, we can always go back
to our checkpoints. So on the command prompt, if you do git status right now you'll notice that
a file has been modified, as this
WebGoatIntroduction.java file, we just modified it and we
can commit that change. We can commit it and you can either type in
git commit dash a, which will open up
your default text editor from your command prompt, or you could tack on a dash m and give
your message just directly on the command prompt and
since we're doing this as a checkpoint where not
pushing anything back to Git. It's perfectly fine to just add your message right on
the command prompt. So I'm going to say
changed webgoat.title to webgoat.titles,
compiled and worked. So we obviously didn't compile and we don't know if this works or if it
breaks or anything, but let's pretend we
did for a second. Maybe we'd go back and make some modifications to this file, and we delete some stuff, and we delete some other stuff, and we close the file and we
realize we made a mistake, and we want to get
those things back. Now obviously I can do Command Z or Control Z
to get my file back. But obviously since I close it I don't have any way of
getting that back. So this happens more
often than you think, where you close
a file after making changes that you may
not want to keep, and it makes working really hard. So going back to
our command prompt, I can simply do git reset hard. The second I click back
over to my text editor, you notice all the
text comes back. You also notice that this
webgoat.titles remained, even though I reset the state of my Git and that's simply because we had made
a commit to it. So I'm going to change it again, I'm going to commit it back, removed the s from
titles, to some commit. Now that stays. So essentially, anytime you make changes to
your repository to the code, and you test it and it's working and you're happy with it, you can simply do a git commit and add
some message on the line. You always will have
that checkpoint to come back to. Now, there's
some fancier things you could do using branches, and being able to bring
changes back from the past, and if you really
want to get into it, there's some really good
resources available. If you simply go to Google
and search, git intro. The very first link that comes up is getting started
with Git Basics, and it'll walk you through various use cases and scenarios where you
want to use Git. For our purpose, I think
that's insufficient to just simply make
checkpoints as you go along. If there's anything complicated
that you want to do, and use Git more
to your advantage, feel free to look at the
resources and get more into it. But for the purposes
of this course, simply doing a commit every time that you make
changes to your code, and you're happy with
the functionality of it and you notice you
didn't break anything, that's a good starting point. While we're going through
our modules I think it's also a good starting point to maybe commit at the end
of every module, once you've completed the module, so that worst-case scenario
you break your code, you can essentially restart
at that checkpoint. If you simply do git log, you'll notice all
of the checkpoints that you've pushed through, and you can at any point go
back to any of these commits. Now without any fancy tricks, you could simply type in git reset hard and copy
paste the commit number. Now you have to be
careful doing this, because if I copy pasted this commit number which
was on November 10th, I will lose all my
commits since then. My commit that happened
on November 12th, my commit that happened
on November 12th again, and December 12th commit
and so on and so on. So be very careful
when you're doing this and worse comes to worst. All of our modules don't necessarily build
on top of each other. So once you've
completed module one, you could actually go back
to our repository and get a fresh copy
of the repository, and download it to your computer
reset up your IDE. That's perfectly
acceptable, because nothing from Module 1 necessarily carries over to Module 2 as far as the project
is concerned. Obviously, the knowledge that
you gain does carry over. I hope they gave you
a basic intro into Git and how we're going
to be using it to make our life a
little bit easier. Feel free to research get on your own time
a little bit more. It is certainly a useful tool. If you're not familiar with Git, you may have used SVN
or Mercurial or TFS. Those are all Version
Control Management Systems and they all have pros and cons. I don't necessarily
have a preference, I'm using Git simply because WebGoat and Owasp decided to store their project on GitHub. That's where I forked
our UC Davis version of it, and that's where
we're working with.