Now we can get into some really clever stuff now.
We're going to take a look at implementing a remote repository.
As we said, we're going to be using our local file system,
so we're going to create a bare repository,
configure the local repository with the remote information,
push changes then back through to our server‑based repository,
and then prove that this is working for collaboration by
re‑cloning to another location on our client.
Now let's say we're going to look at some really cool stuff now because you're
going to be able to implement Git as you would in real life.
Now we're not going to need to set up another server,
as I said, we can go through and implement this just using our file protocol.
So to begin, we're going to create ourselves a brand new directory,
so I'm going to use mkdir ‑p, pointing through to my home directory,
creating a top‑level directory, let's say,
called Git, and then we can go through and set up our project directory.
So I'm just going to call it project1.git.
Notice the Git extension at the end of the directory name.
This is required.
I can move into that directory, so don't forget about Esc+.
to bring up our last argument.
And now, of course, we're in that directory.
We can go through and initialize our repository, so I
can go through and it goes git init.
But rather than leaving it just like that,
which will create the .git subdirectory,
if we use ‑‑bare, essentially, our .git subdirectory,
which is all of our repository information,
becomes the top‑level directory.
Hence, the .git extension that we use in our directory name.
If I run ls now,
we're really seeing what we would see from inside of a client‑side
Git repository, inside is the .git directory.
With that done, we've now created a remote repository.
Of course, it's empty,
but we're able then to synchronize our client through it to add the content.
So if I then go through to my previous directory,
cd ‑ will take me to my old directory so we can see then the
full path to the directory I've gone to.
I'm going to clear my screen just to move it to the top.
If I go ahead and run our git config ‑‑list,
we can see that we've got very simple information here.
We don't have any information about our remote origin.
So this is where we add in our repository information,
so we can go through and go git remote add and then our origin.
So origin is really representing our source, and we can go through and use Esc+.
just cycle through it to get back to your directory.
With that done, we can use git and remote ‑v.
We can see there that we've got our origin locations set up.
Now let's say this is often going to be an HTTPS or an SSH path,
but there's no reason it really can't be the file system,
and this could work quite well if we had NFS servers and we
had mounted the export to a local directory.
We can see there that we've got it both for fetch and push.
Really, the fetch is our pull, where we're pulling changes down,
push is where we've made changes locally,
which is how we work with Git.
We never work on the server‑based repository, push is pushing our changes back.
We now need to populate the repository, and we do this within our git push.
We need to the first time we run this because we don't have the information set,
so set‑upstream and have our origin.
That's the tag that we set for our remote information to be
linked then through to our master branch locally.
So we can see there that we've pushed information up,
and if I go through and clear my screen,
run my git config and ‑‑list,
we're able to see now that we've got the remote information and the
branch.master pointing through to our origin.
Now with that done, I can move back, let's say,
to my home directory, run a mkdir, and let's say play,
move into that play directory.
I just want to be somewhere else where we can then go
through and show how we can collaborate because I can now go
through and run my git clone again.
I could specify the file system path.
Again,
I can just cycle through my arguments to get back to my project1.git directory.
Here hit Enter.
Now when we take a look inside of here, we've got project1,
and I can go into project1.
And then when we take a look at this, we've got then myfile,
we've got the Python directory.
If I wanted to make a change, let's go through and just touch file1.
Again, when I go through and take a look where we've got then our git status,
we can see that we've got an untracked file,
so let's go through and do our git add.. We know
about this now our git commit ‑m, we'll just call it,
say, test.
As this is a newly‑cloned repository, it will have all of the information in it,
so I can just run a git push.
I don't need to specify where to push it to it's all
included in the git information.
So we've now updated the master with a new file.
If I return to my original project1 directory,
now, of course, then when I list the contents,
I don't have that new file that we've created.
But if I do a git pull, we can refresh,
so now I've got that new file added to my local system.
And as you can see, then,
we've been able to demonstrate how we can emulate a remote
master by using our file system and how we can have a couple
of clients working at the same time.
In our case, a couple of different directories,
so we can collaborate on our same project.
The last thing that we need to cover is just make sure we
fully understand about working with branches and creating our own branches for development.