In this first part of the git demo, we will
call it the basics of git. So for example, how to
introduce yourself to git, how to create a repository, how to
commit changes and get changes from the repository, and so on.
So after you installed git you should have the git tool
available on the command line, so you can run the command
git and, if you just execute git you will get the
usage information for git, with the most commonly used git commands.
And to find information on any command, you can simply
type git help and the name of the command. For
example, let's try to write git help init. And that
brings up the git manual page for git init, which describes
the command, the synopsis, and so on. Now, let's get
started with using git by introducing ourselves to git, which is
the first thing we need to do. To do that
we use the git config command, in particular we are going to
write to the git config minus, minus global
user dot name. Which means we are telling it
our user name. We'll specify our user name which
in this case is George P. Burdell. You could
also provide your email address in the same
way. So you still use the git config --global
command. But in this case you will write user.email
as the property. And then you'll specify a suitable
email address. In this case, the email address of George P.
Burdell. We will now look at some commonly used commands that to
create and maintain a local repository. Let's first create a
new project and call it my project. So, to do that we
are simply going to create a directory and then we're going
to move into that directory. Now, if we try to call the
git status command at this point to see what's the state of
my project, of course git doesn't know anything about this project, right?
So, you will get an error. It will tell you that, basically,
we're not in a git repository. So how do we create a git
repository? How do we make this? A Git repository, but we do it
by calling git init and the output will tell you that the
repository was initialized. If we check the status again, you will see
that now Git recognizes the repository and will tell you that there is
nothing to commit because, of course,
the repository is completely empty. So let's
just create a new, empty file. Which we're going to call REAME. So
now if you run git status, as you can see, git will
tell you there is a file that's called README, but it's untracked.
Now what that means is that the file not staged, if you
remember our lesson. So what we need to do, we first need
to tell git that, you know, this needs to be considered. And
the way we do that, is by calling the git at command
and then we specify README as the argument for the command. If
we call again, Git status. Now, as you can see, Git knows
that there is a new file called README, because the file
is staged. So Git is aware of the fact that this
file has to be committed. So, to commit a file,
we simply execute git commit, which will open a text editor, which
can be different, depending on what is your environment, and here
we need to add a comment to be added to the commit.
So here we simply write in Added README file, then we
can close and save And this will add the file to the
Git repository. The local Git repository of course. At this
point, if we ran Git status again to see where we are.
You can see that Git tells you that there is nothing
to commit. Because of course the only file that we have, is
committed to the repository. Now, let's make some changes to our
README file. I'm just going to add some text here. Once more, we
can run git status, and at this point, git knows about
this file. So, it will know that README file has been modified.
Remember that before, it was telling you that it was a new
file, now it knows that there was a different version in the
repository. So something we can do, at this point, for example, is
to check the differences. Between this file and the committed one by
executing get diff readme and if you look at the output of
the get diff command here, you can see that this line, readme
file content was added and you'll see that it was added because
there's a plus sign before that line. In case of deletion of lines,
you'll see a minusm sign there. So at this point, if we
want to commit our file, remember that we'll always have to tell git
that we want to stage the file before committing it. Otherwise, it
will be ignored by the commit operation. So to tell git, that the
file has to be staged, we will, can use the usual git
add command. But if you remember the lesson, we can also use a
shortcut. So you, we don't really have to do this in two steps.
We can simply say, git commit -a, and this will tell git to
commit all of the files that git knows about, which in this
case is only the written file of course. Something else that we can
do, is that we can also provide the right away message for
the commit, without having to open an editor. So, to do that we
can specify the -n option. And at this point a we can
just put a in double quotes our content we press enter and as
you can see it will notify us that one file was changed
and in particular it will also tell you that there was an a
insertion again if we run git status you will see that
there is nothing else to commit. So now let's imagine that
you want to see the version history for your repository. You
can do that by running the git log command. So if
you run that, it will show you all the different commits
For your repository. And each commit has got a commit ID, as
you can see here and the one down here is
the first commit, where as the one above is the second commit.
And as you can see, we'll also show you the comments associated
with each commit. And in case you wanted to see the changes introduced
by a commit. You can use that git show command, and you
can provide the commit ID for the commit that you're interested in.
And you don't really need to provide the whole ID, you can
provide the first four or more characters. So that's what we're going to
do here. So we're going to specify the second commit, and when we
execute the command it will show use the changes introduced by that commit.
To fetch a repository from a remote server, you can
use the git clone command. So you will write git clone
and then specify the URL. For the remote repository. Here
we are using the SSH protocal and there are different protocals
that can be used, so the remote repository can be
made available in different ways. As you can see, when you
clone the project, the project is cloned into the local directory.
If you wanted to import the project under a different name.
You could just specify the name that you want for the
Local Directory. For example, in this case, myproject2. And,
so here you'll get the project in my local work space
with the name that I specified. So, let's go inside one
of these two projects that have the same content because they're
coming from the repository. If you want to see the details
of the server you can use the remote command and specify
the flag -v. And here we'll show you what is the remote
repository now let's go ahead to make some changes to the project
for example let's add a file. So I'm just going to create this
empty file which I am going to call new file I'm going to
add it to my index so that it gets committed. Later on and
then I'm going to run git commit to actually commit it to the
local repository. And I'm going to specify the comment for the commit right
away here from the command line. So when we do that the
file gets added to my local repository. And if we want to double
check that, we can run git log. And if you look at
the last commit at the top, you can see that it's telling
me that the new file was added to the repository, showing the
comment that I added. But this is just for the local repository,
so I need to use the git push command to push it
to the remote repository. And at this point, when I run that,
my local changes will be committed. To the remote repository. So now
let's go to the other copy of the project that we created.
The one under directory myproject2. If you remember this project was
linked up to the same remote project. But of course, if we run
get log here, we don't see this latest change that we made, because
we didn't synchronize this local copy with the remote copy. And so we
just have these files, the README and ,Five that worked there before.
So what we need to do is that we need to pull the
changes from the remote repository using git pull, and when we do that,
that will actually pull these changes and therefore, create the new files that
we created in the other directory. And if we run git log now,
you can see that now we have the new entry. The comment at
the top, that says this new file was added and of course, this
is just an example, so we had two copies of the project on the
same machine and for the same user, so the normal users scenario for
this, it will be that, each user will have their local copy, but this
should have given you the idea of how, git allows you to work
on some local file. Commit them and push them to a remote repository and
other users to get your changes, do further changes push
them as well and then, you know, they will allow you
to get their changes, and so on and so forth. So
really allows this collaboration between different users and keeping track
of all the changes made by the different users. So now
let's look at some more advanced concept, which are the concept
of branching, and merging. So what branching means is basically is
to make a copy, to create a branch of the current
project so that we can work on that copy indpendently from the
other copy, from the other branch. And then we can decide whether
we want to keep, both branches, or we want to merge them at
some point. And you can of course have multiple branches, not just two.
And the reason why this is particularly useful is because in many
cases if you think, about the way we develop software in general,
we work with artifacts. We might have the need to create kind
of a separate copy of your work space. To do some experiments for example.
So you want to change something in
the code, you're not really sure it's going to
work and you don't want to touch
your main copy. So that's the perfect application
for branching. If you want to do
something like that...you want to experiment or do
some modifications that you're not sure about,
you will branch your code, you will do
the changes...and then if you're happy with
the changes, you will merge that branch
with the original one, or worse if you're not happy with the changes you will
just throw away that branch. So this is just one possible use of branch but
it's one of the main uses of that. So in all let's see how that
can be done with git. So first of all if you
want to see which branches are currently present in your project, you can
simply execute git branch, and in this case, you can see
that there's only one branch, which is called master, and the star
there indicates that this is our current branch. So how do
we create a new branch? So we simply run the command
git branch and specify a name for the new branch, for example we'll
call it newBranch, to make it very explicit. At this point,
if we run git branch of course, we will have
a new branch plus master will still be our current branch. So
if you want to switch to the new branch, we will use
the git checkout command and specify the name of the branch that
we want to become our current branch. So when we run that,
git will tell us that we switched to the new branch. And
if we run git branch you will see that now the star
is next to newBranch because that's our current branch. There is a
shortcut for these two commands. If you run the command git
checkout specify the -b flag and then the name of
the new branch it will do both things at the same
time. It will create the new branch called testing in this
case, and then it will switch to new branch and then
it will tell you after executing the command. So now if
we look at the git branch output, you can see that
there is three branches and we are currently on the testing branch.
So now let's create a new file and just call it test
file, put some content in there, save it, we edit and commit it.
And as you can see, now in this current branch, we have our
testFile. So now let's switch to a different branch. So let's go back
to the master branch using the usual git checkout command. So now if
we do an ls, if we check the content of the current directory,
we can see that the testFile is not there, because of course, it's
not in this branch. so now let's assume that we are happy with
the testFile that we created, with the modification that we made on the
branch. And so we want to merge that branch with our master branch.
To do that we can call the git merge command and
we'll specify the branch that we want to merge with the current
one. So we will specify testing in this case. That will merge
the testing branch with the current branch, which is the master. Which
means that now the testfile is in my current working directory,
is in my current, Current branch. And if I run the branch,
you'll see that the testing branch is obviously still there, so let's
assume that we want to delete the testing branch at this point
because we don't need it anymore. We could simply execute
the branch -d which stands for -delete, specify
the name of the branch and this will eliminate that
branch as confirmed by running the command git branch or the
testing branch no longer shows up. So, something that might
happen when you merge a branch is, is that you
might have conflicts For example, in case you change the,
the same file into different branches. So, let's see an example
of that. So, we're going to check which branches we have,
so we have two branches, in this case, master and newBranch
Our current branch is master. Let's open this file called new
file and, add some content there. So now let's commit
this changes to the get to the local repository. Now
let's switch to the other branch and if you remember we
do this by running git checkout and the name of the
branch. And at this point we do the same operation here.
So we take this file and we change it here to. In this
case we have content that reflects the fact that we are. In the
new branch just for convenience. At this point, we also can move the
file here. The comment here is, of course, that this is the new
file in the new branch. So, at this point, what we have here
is that we have this file called newfile that has been modified
independently both in the master branch and in the new branch. So we
have a conflict. Right? So, now, let's switch back to the master branch.
So now, let's say we want to merge the two branches. So
since we are in master, we want to say that when I
merge the new branch into the current one. And when we run
that, we get an auto merging conflict. So at this point what
we can do, is that we can manually fix the conflict by
opening the new file. So the file that was showing the conflict.
So here you can see the kind of of information that you get
in the conflicted file. So it's telling you basically that there is
in the head which is the, the master this conflict. Which is new
file in master. Which is the content that we added of course. And
then you know, under, you know, the separator you can see the content
that was added in the new branch. Which is the contents in new
file, in new branch. So basically, what this is showing you is the
parts of the file that are conflicting. In this case, we only have
one line, is basically the whole file into two versions and you can
decide which version you want to keep or how you want to merge in
general, the two pieces. So here, let's assume that we
want to keep the content from the master. So what we're
going to do is we're going to elimate the annotations
and we're going to eliminate the additional content. We save this
file. So at this point what we need to do
is simply to commit the modified file (the merge file) and we
do that in the normal way. We call git add, specifying
the file, so git add newfile. Then we run git commit
newfile, and we specify in the comment for clarity that this is the merged file,
so that we performed a merge. And at this point we are done with our merge.