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.