In this lesson, we'll talk about get branches
while checking, get status and making commits.
We can notice a line like this in the output on branch master.
So what are these branches?
Well, here's one example,
our project can have multiple versions.
So maybe we shipped out version 1.0 to our users.
And a part of the team is constantly fixing bugs
in version 1.0 So they'll work on the 1.0 branch.
But at the same time, we also intend to build new features into our software.
So another part of the team is working
on version 1.1 on an entirely different branch.
This way people can work on two versions,
two branches without interfering with each other.
And git will track each branch separately.
We can think of branches as different development roads.
They can go in similar but slightly different directions
and from time to time they can be reunited,
which is called merging in git terminology.
And we'll see how that works later on
the master branch is the default one that git works with.
We might use this to track our stable version of our software project.
And the one that's actually shipped out to the public,
it's up to us what we do with it.
Now, let's imagine that our master branch tracks the 1.0 version,
it contains file one and file two
and things are looking good.
But we want to prepare a new and improved version 1.1.
So we start improving our code
and we don't want to make changes directly to our master branch.
Instead, we wanna create a new branch.
We won't even call the branch 1.1. We'll call it 1.1 testing.
This tells our entire team that this 1.1 branch is not even final yet.
We're just modifying lines of code and we intend to
test the new software before releasing it to the public.
But seeing this in practice is easier to understand.
So let's dive right into how to use git branches at the command-line.
Now we're back at our terminal window
to add our new branch. We'll use this command.
Now, if you ever need to delete a branch, you can use this command
delete,
get branch, dash dash, delete and then the name of the branch
to see all available branches, we can type in
yet
branch
dash dash list
or simply
get branch.
Now we notice here that we're currently still inside the master branch.
The asterisk symbol shows us the one that is currently selected.
But remember we want to add new features and
track them in the 1.1 dash testing branch,
not the master one
to switch to the 1.1 dash testing branch. We'll run this command.
Great.
Now it's time to start work on the 1.1 version.
Let's open file two in an editor.
We'll press I to start inserting text
and we'll make the following modifications.
Now, we have changed our line two. This is the improved line of code in file two.
I will press escape
colon
WQ
to write and quit.
And now if we enter get status,
we'll see that. Git already noticed that file two was modified.
We're also offered a useful suggestion here. The git
commit
a command, meaning we could skip the whole git
a
file two command again and jump straight to the commit with a command like this
getit
commit, dash a dash M some message here.
But to build healthy habits for now and avoid any future mistakes as beginners.
Let's go through the usual routine.
We'll add file two to the staging area
and then we'll commit the change.
Awesome. We're in branch 1.1 dash testing.
So every developer in our team checking this out will see the latest changes here.
The master branch is basically unmodified,
still containing our clean well tested code that we had previously.
Now up to this point, we did a lot of things in this git repository.
Next week, we might not even remember all these changes. We made.
But when the multiple team members are involved,
it's even harder to know what people modified in the past.
That's why we have git
and one command we can use to get a glance at past activity is get log.
Now, we can truly see how awesome git is. This is full of details.
As a developer, we can quickly see what other team members did in this project.
Additionally, we can uncover even more details.
For example, maybe we want to see what files were actually changed.
So we can type in git
log dash dash raw.
Notice this output these lines tell us that the commit added two files,
file one and file two.
That's what the A stands for
D shows us files that are deleted in a commit and M signals modified files.
Also notice this weird text next to each commit.
This is called the commit hash
and it uniquely identifies each entry if we want to dig deeper
and see what lines of code were actually changed in this commit.
We can use the first few characters of this hash. For example, we can run git
show
and the first few characters of that. Hash.
Additionally, we can uncover even more details.
For example,
maybe we want to see what files were actually changed so we can run glog dash dash raw.
Notice this output, this line tells us that we added a file,
file three and that's what the A stands for.
D shows deleted files in a commit and M signals modified files.
Now also notice this weird text next to each commit.
This is called the commit hash. And it uniquely identifies each entry.
If we want to dig deeper and see what lines of code were actually changed.
In this commit, we can use the first few characters of this. Hash. For example,
I'll copy some of these first characters,
you will type in git show
and those characters.
Awesome.
Now, the red text preceded by the minus sign shows us old content that was removed
and green text preceded by a plus sign shows new content that was added.
So we can see the modification that we made in
this commit when we edited that text in the file.
If we list commits again,
we notice a few things.
One is that the master branch is one commit behind
since these are sorted from bottom to top,
the newest ones at the top and the oldest is at the bottom.
So when we improved our code,
we committed the change only in the 1.1 dash testing branch.
So this is expected the master branch should not contain that commit yet.
The second thing is a mysterious word that says head,
what does that tell us?
Well, it's easier to understand if we go through a few commands.
For example, right now, head points to the commit where we improved code in file two.
Now, if we take a look at file two.
We can see that we have the approved line of code in it.
But now let's switch back to the master branch
and we'll check the log again.
We'll spot a couple of differences here.
First. Now we only see three commits instead of four. As we saw previously,
the last commit here is when we remove the buggy feature,
the commit where we improved, our code is not present.
This makes sense because we didn't commit that change in
the master branch only in the 1.1 dash testing branch.
But now notice the head is pointing to this commit where we removed a buggy feature.
Previously, it pointed to the commit where we improved code.
So let's check out file two again.
Interesting. Now it shows us the old content of the file.
What's the explanation?
Well, head currently points to an older commit when we removed our buggy feature
in that commit file two had this original content that we see here.
So head points to a certain commit,
which is not necessarily the last one we did in our project.
And what head points to is the project state that we'll see in our working area
by pointing head to a different commit.
We can basically travel in time exploring the project state as it was in that commit.
So that's another great thing about git.
We can essentially explore various stages in
the life cycle of our software project.
So let's talk about merging branches.
Now,
remember how our latest changes in file two are not present in the master branch.
In
git terminology, we say that the master branches behind our 1.1 testing branch.
Now let's imagine we finished improving our code and we tested everything in
the 1.1 testing branch time to launch our new and improved software product.
But how do we do this?
We bring all the changes from the 1.1 testing branch
into our master branch and this is called merging branches.
We'll merge a secondary branch into our current branch.
We want to merge into master. So let's make sure that that's our current branch.
Perfect
to merge 1.1 dash testing into our current master branch, we run this command
and if we take a look at file two, again,
we can see that our master branch finally includes all the
latest code changes brought in from the 1.1 testing branch.
Now let's get to one of the most important features of git.
Let's talk about working with remote repositories.
Now, up until this point, we worked with our local repository only.
But as a part of a large team,
we'll want to periodically make our code changes available to everybody else.
The easiest way to do this is to upload our
progress from the local repository to a remote repository.
Now, if you've ever used github
or gitlab,
you already saw two examples of platforms that can host remote repositories.
But uploading our changes to a remote repository is only half the story.
Other team members are also working on this software project.
So we'll want to be able to see what changes they've made,
which brings us to the next git concepts.
When we upload our changes to a remote repository, this is called a push operation.
When we download changes, it's called a pole operation.
But what we're actually downloading and uploading are
all the commits that git knows about.
So we either pull in all the available commits from the remote
repository or we push all of our commits to the remote repo.
Either way this keeps the whole team synchronized with the latest code changes.
Let's see how we can push our changes to a remote repository.
Since github
is the most popular platform for remote git
repositories. Let's see the steps that we need to go through here.
After we log into our account, we'll head over to the repositories tab.
Next we press the new button to create a new repository.
We'll pick a name for it and I'm gonna call this KK Pro
and we'll leave the rest of the options with their default settings.
Now, the next important part is to get to our connection strings,
which we can see here.
We can see that the HTTPS protocol is selected by default.
When we intend to make changes to the remote repository, we must prove to github
that we're allowed to do that.
If we use the HTTPS protocol, we have certain login mechanisms.
For example, we can use a username and an access token,
but we'll click on the SSH button to log in in a different way.
It will be easier for our case since we can log in with SSH keys.
Now let's copy the connection string we see here
and back to our terminal.
Remember how git stores all information about our
local repository in the hidden dot git directory.
Well,
this is also the place where git
will store information about any remote repositories.
We might have
to check if any remote repositories are associated with this repository.
We type in git
remote
dash VV stands for
verbose which is detailed output.
Nothing will be output since no remote repos have been configured yet.
So let's add our first one
with the next command.
We will tell git what remote repository it
should use when uploading data from this local repository
or when downloading data to it.
So we're gonna type in git remote add origin and
then that connection string that I copied from the website
origin is an alias. It's a name that we pick for the remote repository
because it's easier to remember and type origin than an entire connection string.
So with the next commands will simply tell git to push or pull from origin
and it will know that origin points to that connection string,
we could pick any other name we'd like,
but it's usually standard practice to pick this name for the default remote repo.
Now,
we can check again if our local repository
is configured to use any remote repositories.
These two lines show us that an origin
is associated with this particular connection string.
It's configured to both fetch or download from the
remote repository but also push or upload to it.
Now let's configure the SSH keys that will allow us to log into this remote repo,
we can use this command to generate a public and private key pair
SSH dash key GM.
And we'll press enter at each prompt to pick the default settings.
We'll save the private key in its default location
and we'll use an empty passphrase.
So we don't have to pick any particular password to encrypt our private key.
OK.
And it was generated. Now, we'll need the public key,
which is specified here in ID underscore ed 25519 dot pub.
So let's display its contents
and we'll copy this entire text. Now, we'll go back to the github
website
and here we'll click on the settings tab
and we'll select SSH and GPG keys
and will click on new
SSH
key.
And here I'll put in a title
and we'll paste in the key
here.
We can see there's a difference between authentication key
and signing key and we want the authentication key.
We'll click add SSH key.
Now let's return to our terminal.
Now, our remote repository is empty.
Let's bring it up to date and upload all the commits that we did locally.
And we'll do that with the following command
and we'll type in. Yes, here.
So with this command,
we basically told git to push our local
commits to the remote repository named origin.
And we also specify what branch to upload. In this case, the one called master.
OK. Now at a glance, it seems that our changes have been uploaded. But let's check,
we'll go back to our repositories.
If we go back to the github.com website and navigate to our local remote repository,
we will see that we now have some content.
Now, let's go back to our terminal to pull in the latest commits to our master branch.
The command is also quite intuitive.
We'll say git pull origin master.
Finally, let's check out another thing.
Now, up to this point,
we've assumed that all of our team members
already have their local repository set up.
But what if a new member comes in?
They won't have a local repository with this project available.
They basically have to start from zero.
So how can they do that easily?
Well, with the clone command.
So let's imagine that our new team member wants to start working on our project
after we set up the SSH keys, upload their public key to the project and so on,
we can give them the connection string.
After we set up the SSH keys, upload their public key to the project and so on.
We can give them the connection string that you find here.
Now, let's put ourselves in their shoes.
We'll exit from our current directory and return to our home directory.
Let's imagine. They create a directory called work.
This is where they intend to store all the software projects they'll be working on
so they switch to this directory
finally, with one command, they can quickly get started.
The clone command will do everything that's required.
It'll create a local repository and this local
repo will be preconfigured with project specific settings.
For example,
the remote origin will be added automatically and all of
the project files and commits will be downloaded as well.
So the command that they need to enter is
get
clone
and that connection string.
And the result we can see a directory called KK project was created.
And if we take a look at it,
we see that it contains all of our project files plus the hidden dot git directory
which contains the history of commits and all the other data that's tracked by git.
And if we switch to this directory,
we can use the same commands as before such as get log.
So now our team member has the same repository on their
computer that all the other team members are working on.
The command is a nice quick way to start from zero.
Once the local repository has been created, though,
the rest of the workflow is the same as we saw in this demo.
This covers all the essential steps that we need to know when working with git.
Of course,
git is an incredibly complex tool that can do way more than what we just saw.
Remember that when needed, you can enter git followed by a space
and then press the tab key twice.
This quickly shows you all the subcommands that you can use
and you can get help for a subcommand by typing man,
followed by git and then the name of the subcommand you see in this list,
for example, man, get at
and we hope this is a fun lesson to go through.
If you're interested in learning more about git,
we have an entire course for it here on our website at code cloud.com
and you can check it out there.
Now let's continue with our next lesson.