And now what we're going to take a look at is that we're going to move out
again to our Ubuntu system and create a Git repository.
Git is for sharing code and collaboratively working on code.
We can then add code to the repository from the Alma system
and view the code from our openSUSE system.
And here we are again, starting on our Ubuntu 20.04 system.
Now we want to be working as our user1, the account
that we created with the password.
So I can use su ‑user1 and add in the password to gain
access on the Ubuntu console as that user.
We want to go through and create ourselves a directory for our project.
So we use the mkdir command, and I'm quite simply going to call it project.
This is going to be our central Git repository.
I'm going to move into that project1 directory.
And from here, I already have the git command installed.
It is installed as standard with this Virtual Box machine, so I can
use git init ‑‑bare to create an empty repository.
It will have the .git hidden directory, but that's
all. It's going to have no files.
So we see, then we've initialized an empty Git repository.
This is going to be my central Git server, but we can add code from our
remote client systems. But before we move out to our client systems, we
might as well check that the previous exercises work.
So cd takes me back to my home directory where I can see, then the file1
that we copied up with scp, and the docs directory that we use rsync. And
looking inside of the docs directory, obviously I've got all of the files
that we had synchronized up.
So this is all good and showing that our previous exercises have worked. We
can now return back to our Alma Linux system where we're then going to
clone our repository. Now Git wasn't installed on this automatically, but I
have already installed, then the package git‑core, and from that gives me
the git command where I can use git clone and user1 at the IP address of
your Ubuntu system.
So in my case, and remember in the Vagrant file, I configure this to be
192.168.33.13. We can specify the full path to go through.
So after the colon, we've got /home/user1. And remember, it
was that project1 directory was our project.
We, of course, need to authenticate with the password that we've been
using, so we can add in our password, and it does tell us that we've
cloned, then an empty repository. But that's okay.
We can add in content to this. By moving to the project
directory, when I look at the ls command, it shows as being
empty, but it still has metadata. Ls ‑a shows me all files,
including hidden files and directories.
Hidden files begin with dot. Well, you see we've got a hidden directory,
.git, that holds all of the metadata regarding this project.
We're going to create a new text file.
It's going to be a script, but reality is that Git can manage
any text files, really, including scripts.
Often, when we're looking at scripting, the first line will be
something called a shebang, so, our comment,
exclamation mark, and then the path to the interpreter. So we'll create
a Bash script that merely echoes out hello. We can go through and save
our changes, so escape, and colon, and x.
Now we want the execute permission on this script so it can be
executed, so we can go through and use our chmod, change mode,
setting the mode or permissions of the file, a, all, +x, the
execute permission for the file, my.sh.
Now that we're ready,
we can start saying these files are going to be managed by the
project, so git add, and dot all files. With that done, we need to
make a little bit of a configuration.
We need to be able to commit these changes. But to commit them, we have to say
who made the changes, so we need a name and an email address.
I'm just going to paste in the commands.
We can get them from the slides, but git config, and setting them
globally, so for all projects, our email and name. You can obviously put
a real email address and a real name if you want, but these will work
for us. We can keep it anonymous. And then we can go through and use git
commit. ‑m is the message.
The message becomes useful, so we can see why these changes were
made. So we'll say, look, this is our first commit of our
script, hit the big Enter key on this.
Now let's just set metadata.
We still haven't pushed up these changes.
We need to make sure that these changes now are reflected in our repository, and
we can use, then git and push, and then origin being our local data and being
pushed up to the master branch of our repository.
Again, I've got to authenticate.
We don't need to say where the repository is because that's already stored
within that hidden data inside of the .git directory.
So once we authenticate, we can see then that the data then goes back
up. That's now stored centrally in my Git repository, and other users
then who've got access rights to this such as on my openSUSE system can
collaborate within the project.
We need to make sure on openSUSE, we haven't used this yet, that we do
have git‑core installed, so sudo zypper install git‑core.
We can allow this to come down and just accept the prompt, but that's
going to give me now my Git client, and that's going to allow me to clone
the repository, so git clone. And then user1 at the IP address of our
beautiful Ubuntu host, so 192.168.33.13:, the path through to the
repository, so /home/user1/project1.
Accept the public key from the SSH server, add in our
password, and we'll now pull our code down.
Now that would've created the project1 directory, so we can see the
contents of the directory. And obviously, I use ls ‑l. We'll see the
metadata, including the permissions, and we can see there that the
execute permission is still maintained.
So everything is looking good.
That also means, though that I can go ./project1, and the name of the script.
I can execute the script, and we can see our
wonderful hello message coming back.
So everything now has worked. And we're, in fact, at the end
of this module, but we do need to summarize a little of what we've seen, so we don't forget.