So for project two your first task and
probably the biggest hurdle is getting set up with GitHub and if you're new to
GitHub we encourage you to take our intro to Git and GitHub course.
It's really fun.
They did a, I love that class and I think Caroline and
Sarah did a really nice job.
>> I agree. >> It's been really helpful.
I learned a lot actually.
>> Me too. >> I know a lot of tricks About GitHub
and Git.
But yeah, you gotta get your Git and GitHub account set up.
And then, you're going to fork the repo, we have a starting point for
that resume.
And so, you're going to fork that.
And that creates a repo of your own.
And that's on your GitHub account online.
And once you have that repo online and
you can have account you can clone it to your computer or locally.
So now you have your local clone and can work on the code mostly.
And then push your changes back.
>> So Version Control, Durant, I'd like to ask you, why Version Control?
What's the point?
>> Yeah, so Version Control often if you want to be able
to go back to an old version of something you did before.
Maybe you're trying different branches.
You can try A and a B and you can work them individually, and
you can switch back and forth between them.
In the simplest case or even just a single revision history.
You can go back to a previous version.
Let's say you like something that you did before.
And you want to go back to that you decided the new way to test ways
when you are.
Go back and especially in the course they also talk about where if there's
a bug that was introduced, you want to go back and find it,
figure out where that was.
You can fix it and you can still keep the whole history of everything you have
and move forward from there.
>> Okay, so and how important is it for
you to learn version control in the professional world,
once you're working with other people because, it's good if you're.
There is an argument, and it's a fair argument, that if you're just working
on it by yourself, you can just copy old files into a folder and say okay, this
is my old version, and I'm just going to copy and paste into another folder.
Well I have another version that it will work on.
>> Right and that's a good point especially because when we're working
with other people, Version Control will also track who made what changes.
There's something funny called git blame where you can figure out who introduced
what into the stream of edits.
So it's really good when working with other people to
be able to track alternative versions of, whether it's code or even documents.
So you go back that's pretty much requirement working
in any kind of production environment with other people.
And even by yourself.
If you want to sort of have just
trail of breadcrumbs just to sort of go back and see what you did or what point.
It's basically rewind the clock to go back in time to find older versions of us.
There's the only other way to do would be to like name files, maybe version
one, version two so you to have them a very cluttered directory structure.
These tools make it really easy to first, create that trail so
that you only see the current files in that directory.
So it keeps everything neat and compact in your directory and
then also makes a way you can share with other people.
Like through GitHub.
>> Right, so that's interesting.
Let's talk more about only saving what you need.
In git, versus because if you think about Version Control you may be
thinking well let me just save the whole version, all the files, one at a time.
I'll archive this folder for yesterday and then I'll copy all the files and
then I will also then make my changes and copy all the files again.
So what's the difference between what GitHub does and
if you want to do everything manually?
>> Right so one thing, especially now that you're mentioning multiple files.
That's something else.
It's incredibly important.
Imagine you had two different versions, and
the files had to be consistent with each other.
So you can save all these files together in one batch or
all files together in another batch.
And you know that when you save if you save them to be consistent
you can switch back and forth between multiple files at the same time.
>> So one cool thing is git it doesn't necessary save all the file,
it saves the differences.
>> Yes, right.
>> Right, so if you think about it, it's actually genius.
It's very efficient.
So you don't care about redundant lines of code.
>> Mm-hm. >> If you
did not touch that line of code, Git doesn't care about it.
>> That's right, yeah.
>> So, only if you change certain lines of the code,
Git will keep track of those changes.
>> Yeah. >> because it will assume that if you
have a section of the code that you don't touch it will do anything.
It will just assume that it will just be there forever.
>> Yeah, it's super smart that way.
And also you can view the differences between each version.
So instead of looking these ginormous files you can see like
he just changed these lines versus those lines.
Really helpful for trying to track down.
>> Yeah, thanks for giving us the overview of why GitHub is important, and
gives you control.
>> This particular tutorial is very
helpful in just understanding the basics of Git.
Just the absolute high level of what base commands are and
what you need to do just to get started off.
The link is try.github.io it would have but
[INAUDIBLE] the first level of the first challenge.
And I spoke about this already now
you can see it on my screen you can see that there's, it's got
a terminal it's got a version of file system then you can use.
Just to see how changes have been made.
So when you start off the first thing you do is you want to create a git repo
on your system.
So that is done by a user
the git init command which is the initialization should be done.
Once you enter that on your terminal you will see that there will be a .git
folder that will be generated and
inside that you can see a whole bunch of sub branches.
You won't have to make any changes to these, these are just used for
the internal git workings so in work the git in future.
It will be it'll be using all of these to make changes whenever needed.
So once you created your Git repo the next step is to do git status so
git status can use periodically throughout your.
Working with Git just to see where your system lies and
what you're working with right now.
So many do git status.
You will see that it tells you that you're on the master branch.
And there's nothing to commit.
So again.
[INAUDIBLE] that I said previously.
The branch that will be on your system, the local branch is called master and.
Your remote branch will be called origins.
These are the default names.
So, if you go ahead and
add the octocat.txt file, as you can see in the works of the system.
If you add that into your Git folder and
you do a git status again it'll tell you that there's a new folder,
I mean there's a new file, and that it's an untracked file.
So when a file's untracked,
what it is basically telling you to do is it means you commit that file.
But before you do that it's always good practice to stage it.
Staging a file is essentially just
a medium where you're confirming that the file that you want to add
into your directory is the correct file and it has the right changes.
So to do that we do Git add and the name of the file and
that will give you a comment saying that the file is now on the staging area.
Again you do a Git status just to.
ensure that there are on the web so
it does us that the Git file that is added now needs to be commited.
So once the file has been staged by using Git add,
you'll get to commit so as you can see the work goes from git init.
Then you git add and then you git commit again.
So you commit this file and you see that it's been added.
So this is the basic steps that you need to follow to ensure that the file
that you're working with gets added on to the staging area and
then gets committed into your code.
And then, it's the same process that goes over and over again.
You will see that if you add more files.
If you want to stage all these files at the same time you can do
a Git star,
Git add.
Star is a wildcard that says that any files that have the .txt extension can
be added.
So I do that and that will ensure that all the files that you've added
into your Git folder are now in the staging area.
And then you can do the exact same thing.
You can commit them.
To ensure that they go through a staging area into your Git code.
And there you go.
So far we've seen git init, git status, git add and git commit.
After this, there's another command called git log.
A git log is, it's essentially if you want to see more information for
each commit, you can use git log.
You can see more information for each commit, we're going to use git log.
You can see where the files are added or where files are committed.
Uphold the basic method for that information.
So if I do Git log,
you will see that every commit has a particular code associated with it.
And it tells you who the author was, what date it was, and
what changes were made in each file.
So this is,
I was just giving you a quick through of this particular tutorial.
You can go ahead and use this.
It's not going to take you more than,
say twenty minutes to actually go through this entire tutorial.
It explains how to work with more people's hardware, basic Git Branch.
How to do a basic Git Merge.
>> Let's just talk about footer to GitHub.
because I've also noticed some people look confused between Git and GitHub.
>> Okay. All right.
>> Let's talk about that.
Let me clarify some questions.
That I've noticed.
>> Yeah yeah.
>> So what is the difference between Git and GitHub and do you need one or
the other or can you use one without the other,
yeah what's the typical workflow if you're versioning things?
>> Right, the relationship is that Git is
software that anyone can use anyone can download, it's open source and
you can host it from any particular website that you want.
GitHub is a particular company and their business model is to host, right and
to make some extra tools to make it easier for a using kit.
You can do everything on the command line but with GitHub, they just have
a really nice interface for posting your projects and for downloading.
Repositories, that sort of thing.
>> Right so to Durant's point, just want to drive this home.
GitHub is just an online server where you can just host your code,
share your code and collaborate.
Git is actually the system itself, the actual command line
system that you will learn in our Udacity course.
So that if there was this just a dry content relationship you how often
developers as they actually developed locally on their machine.
They use Git commands to commit, save your versions and
once they want to share their code, once their code is done,
they actually write a command called Git push.
They'll push this code to GitHub and from GitHub you can
then share your code and then GitHub will have supporting
functions to be able to help you collaborate with people.
Once you've shared it people can then download
your code onto to their own local machine and then they'll work on it.
And then, and if they say okay, I have this great function,
addition to your code, I'm going to upload it to my GitHub and
then I'm going to submit what we call pull requests.
Where we just merge and say okay I think this is a really good feature.
We should add it to the main code,
that's people work in a nutshell.
And on Git and GitHub.
>> And even your GitHub repository, I've heard people say that it's almost a,
could almost be a substitute for a resume or
a CV, like you'll just give someone- >> Good point, yeah.
>> Your GitHub Repository and say you these are all my projects.
Look on to all my projects.
>> Exactly. >> It's good, the projects speak for
themselves, they'll look at your code, they could ask you questions about them.
>> Yeah, they'll ask you questions and they'll also, if you collaborate online,
if you collaborate with open source projects or
other projects, they'll be able to see how you work with other people online or
how you collaborate with other developers.
And that's a very crucial skill that they'll be looking at so.
We highly encourage you to start your GitHub account, and start using Git and
start being comfortable with it, because it will only help you.
If you don't use Git, you can forget.
>> Yeah, yeah.
>> You forget what this command you.
I'm thinking, okay, I want to merge this branch but I have
this past commit for mergin how do you want to do it?
>> Yeah, I think it is a complicated system but Sarah and Caroline do a great
job of clarifying it and showing you some real world use cases for
it so I definitely also work your way through the Udacity course.
It might be a struggle because if it's new material it will be hard to get
through, but it should certainly help you out.
>> Awesome, well an application we just found, someone just
programmed an interactive practice tool, like a little tool to practice with Git.
Let's just look at, I don't know a Git commit.
>> Git commit, let's do it.
Okay so I click Git commit, and here's a little diagram, and
there's master and head.
And if I just Git commit.
And I Git commit again.
You can see the diagram updating and
master and head move along with the head.
>> Exactly. >> Yeah.
>> So it gives you a visual representation of actually what's going
on with your versions because think of every circle
as a version of the whole entire project.
>> Yeah. >> So every circle is a commit.
AKA, it's just the version that you see it in.
It's a snapshot of the past.
Basically.
And this is basically you can think about Git as a time machine, capsule.
You go to launch all these commands to manage this time machine.
So basically, if everyone watches Doctor Who,
it's kind of like your Tardis.
Everyone's Tardis here in the software development world.
GitHub is the ability to see everyone else's Tardis.
And get access to their version control,
their commits, and their code history.
Yeah so play around with this.
As you're learning the commands as you're going through the course.
Just come back to here, this web page, and
it will actually dynamically build this diagram for you.
>> Yeah. >> So cool Mark sent that
to the rest of us today.
Thanks Mark.