In today's world, software projects are usually developed by large teams
and this comes with an interesting set of problems.
Imagine we have 10 developers working on the same project.
Each person will add delete and modify code in random places.
Now imagine you're part of the same team.
If you turn on your computer ready to do some work,
how will you know what changed in the last 24 hours?
Now, in today's world, software projects are usually developed by large teams
and this comes with an interesting set of problems.
Imagine we have 10 developers working on the same project.
Each person will add delete and modify code in random places.
Now imagine you're a part of the same team.
Now you turn on your computer ready to do some work.
How will you know what changed in the last 24 hours?
Here are some examples of activities that might have happened during this time
while the software testing team reported a bug,
a developer changed code in six files to fix that bug.
Another developer added a new feature,
three new files were added and two were modified.
Someone else removed a feature that will not be
needed in the next version of this project,
two files were deleted and one file was modified.
That's quite a large number of changes in a short time.
And it's hard to keep track of everything.
Developers could inform each other and chat about what they did.
But that would quickly become messy,
overwhelming each person with information that they need to remember.
That's quite a large number of changes in a short
time and it's hard to keep track of everything.
Now, developers could inform each other and chat about what they did,
but that would quickly become messy,
overwhelming each person with information that they need to remember.
So when you begin work, you need a quick way to get updated on all of these changes.
You'll want to know things like what files were added, removed or modified,
what lines of code were changed,
who changed those lines
and why did they change them?
And these are just a few examples in a nutshell.
You need to know what the rest of the team did.
And when you make your own changes,
you need some way to inform the rest of the team about what you changed and why
with an efficient method to do this,
everyone can work on the same code and always know
what happened since the last time they logged in.
So we need a way to track all of these changes and keep things organized
and the solution is to use a distributed version control system like git.
Now at its core,
Git's job is to allow a large group of people to work on the same software project.
Let's take it step by step and discover how it works.
Now, first of all, in git, we have the concept of repositories.
These are the places where code is stored alongside information about each change.
Now, as a part of the team, we usually have two repositories,
a local repository and a remote repository.
The local repository is personal just for you and the remote repository
is in a shared central location used by the entire team.
For example,
as you code on your own computer, you work with your local repository.
And when you're happy with the results,
you can upload your latest changes to the remote repository.
If you've ever visited github, you already saw a lot of such remote repositories.
Every project you see there is basically a remote git
repository by uploading to this remote repository.
Each team member can update the project at a central location
and by downloading from the remote repository.
Each team member can see what the other people have been working on
this way. They all get updated with the latest changes.
You can think of the remote repository as the place where
everyone assembles all the bits and pieces they've been working on.
Every small change from local repositories is
gathered and integrated into this remote repository.
When you want to update the remote repository with the latest changes you made,
you push the latest code from local to remote
and when you want to get access to the latest changes your team members made,
you do a pull from the remote repository to your local one.
We'll see that the commands for these actions are quite intuitive.
And the best way to understand, get better is to just see it in action.
So
let's go through a few practical exercises.
OK. Now we're at our command-line and we're going to work with git.
Now git usually comes preinstalled on most modern versions of Linux.
However, if we do need to install it, we can type in
Getit,
config dash dash, global user dot name and then your name
and then we set the email address with a similar command,
but it's user dot email instead of user dot name.
Now, this is not login information,
it's just useful information for other team members.
So when we make changes to the software project and make commits,
they will see this username and email and they'll know who changed what
we use the dash dash global parameter to set this value system wide.
This will apply to all local git repositories that
we might create on this machine in the future.
If we omit the global parameter,
we can set the username and email address on a per repository basis.
For example, for one repository, we can use a certain email identity.
And for another one, we could use a totally different identity.
Now, let's imagine we intend to store our project's code into a directory.
We'll call this directory project
and let's go into that directory.
Now, we need to inform git that this is where our project will reside to
tell it to start tracking everything that will happen in this directory.
We use this command
get in there
and a net is short form for initialize,
we can see in the output that it created a hidden directory called dot
git.
Let's take a quick look at the contents in there.
We can see a few files and subdirectories.
Now git will store all the repository information here.
Everything from repository settings,
all the way to data that it will use to track our code changes.
Remember the username and email we picked earlier,
we set that globally.
But if we want to pick a different identity here non globally,
we just remove the global parameter.
That information is now stored inside this dot
git directory in a file called config,
which means that we have an easy and quick way to look at local repository settings.
We just have to display the contents of that file.
We just type in cat dot getit slash config
and we can see the name in the email that we just set.
Now let's pretend we begin our coding journey in our project directory.
Let's create two files, file one and file two,
we'll store a line of text in each file and
imagine that these are our first two lines of code
later on these lines of text will let us see
how git helps us track code changes to each file.
An important note to make here,
git does not continuously track every change to our project directory.
Instead, every time we make changes,
we have to inform Getit that something happened
now is a good time to learn how this process works.
And we'll find out in our next lesson
and I'll see you there.