In the last movie we gained an understanding of the three-tree architecture that Git uses.
Now I want us to go further with that and look at the workflow that one
typically uses when working with those three trees.
This is the exact process that we're going to do in the next chapter as we begin
to work with Git commands.
But I think it's helpful for us to have an illustrative overview first.
So let's look at the process.
First, we are going to work with just having a new file.
Now remember Git doesn't just work with single files, it works with sets of
files that it puts together into a changed set.
But for now, we're just going to be working with a single file to make the illustration simple.
So we've got our three trees, we've got our working directory, the staging
index, and the repository.
We are going to add a file to the working directory, this is exactly what we did
when we made our first commit, we added a file to our working directory, we are
going to call this set of changes A just to have a simple reference for it.
When we called the git add command, what it does is it pushes that set of
changes that we've specified up to the staging index.
So now the file.txt exists in staging index as well.
You may notice that I'm using git add with the exact file name, when we did our
first commit we did git add and had a dot after it.
A dot just says gather all the changes that have been made to this entire
directory and push all of them up to the staging index.
So if I'd changed five files, it would have moved all files up to the staging
index at the same time. Here I am just adding a single file.
Now once we've got everything in our staging index exactly like we like it,
we're ready to bundle it all up and send it as a commit to the repository, we
used the git commit command.
So git commit will take that set of changes and push them up to the repository
so that now that file exists in the repository.
It's there permanently, it's tracked, and it has a commit message about the
change that we made.
That's exactly what we did when we made our first commit.
Now let's take a look at what happens when we make an edit to the file.
So we've got our same state as before, we now have that change in the repository
and our three trees all look identical.
The repository, staging, and working index have the exact same files in them.
But now we are going to make a change to the file that's in the working directory.
So now when we save that we have version 2 of that file, all right, it's a
changed version of the file, and we are going to call the difference between
them, that changed set, we are going to call B.
So when we are done making our changes, then we want to stage the changes, and
we do that with git add, that then pushes change B up to the staging index so
that now version 2 of the file exists there as well.
And then when we finally have everything altogether, we can commit that set of
changes that are represented by B to the repository, using git commit.
So that will push it up to the repository, and now version 2 of the file exists
in all three of those places. We can do this process one more time.
We have change C with version 3 of the file.
We'll push that change up to the staging index, and then we'll commit it, and it
will go to the repository.
So this is the typical Git workflow that we are going to follow.
And as we saw before if we used git log, it would show us the sequence of those
changes that would show us changes A, B, and C that have been made over time.
Now of course, Git doesn't simply refer to these commits as being A, B, and C, it
has a more complex way of dealing with it.
We are going to take a look at that in the next movie.