Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
The "git clone" command can copy a repository, along with its full commit history, to another computer.
Using clones as peers
- With Git, every developer has their own repository on their machine, called their local repo.
- Repos belonging to other developers on the project are referred to as remote repos.
- Each repo is a full copy of the original repo, including all the version history.
- Developers can make commits to their own repo, independently of the others.
- Before beginning work on a new feature, you should use the network to pull commits other developers have made from a remote repo into your local repo, so that you have the latest version of the code.
- Then you can make your changes, and commit them to your local repo.
- Other developers will be able to pull the commits you've made over the network to their clones, so they can access them.
Pushing to a central repo
- Any Git repository is capable of pulling from any other repo. Sometimes collaborators pull from each other's repos directly.
- But it's more common to declare one repo the "central" repo.
- Developers clone this central repo to their local machines over the network.
- Then, each developer begins working on their own separate set of changes.
- A developer adds their changes to this central repo by pushing commits to it over the network. *Other developers receive these commits by pulling them down from the central repo, and they can push up their own changes in return.
- This is the system that GitHub, Bitbucket and other Git hosting services support.
Cloning repos
The easiest way to get a new repo based off another is to clone it, to make a copy of it. This copy will have all the same files in the working directory, plus a full copy of the project's history.
Normally you clone from one computer to another over the Internet or some other network. But we can also clone from one directory to another on the same computer, and everything will work the same. We're going to do that while we get used to the commands.
To clone the medals repo to a repo in another directory named myclone, change to its parent directory and run:
git clone medals myclone
- The first argument to
git cloneshould be the location of the repository you want to clone. Normally, this would be the URL of a repo out on the network somewhere. But for this demonstration, we just clone from themedalsrepo in our local directory. - The second argument is the name of the directory you want to clone into. We used the name
myclone. - If we run
ls, we'll see a newmyclonedirectory.- We can change into that with
cd myclone. - If we run
lshere in the working directory, we'll see copies of all our files. - Remember
ls -ashows all files, even ones that are hidden by placing a dot at the start of their names... If we run it here, we'll see another.gitdirectory that holds a copy of our repo history.
- We can change into that with
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
So far you've been working
in Git all by yourself.
0:04
But projects small enough to be maintained
by a single developer are pretty rare.
0:07
At some point, you're going to need a way
to share your code with other developers
0:12
and to merge all your work together
into a product you can ship.
0:16
Don't worry.
0:20
Sharing and merging file changes
are central features of Git.
0:21
With Git,
0:25
every developer has their own repository
on their machine, called their local repo.
0:26
Repos belonging to other developers on the
project are referred to as remote repos.
0:31
Each repo is a full copy of the original
repo, including all the version history.
0:36
Developers can make commits to their
own repo independently of the others.
0:42
Before beginning work on the new feature,
you should use the network to pull commits
0:46
other developers have made from
a remote repo into your local repo.
0:50
So that you have the latest version of
the code then you can make your changes,
0:54
and commit them to your local repo.
0:58
Other developers will be able to pull the
commits you've made over the network to
1:01
their clones, so they can access them.
1:04
Any git repository is capable
of pulling from any other repo.
1:07
Sometimes collaborators pull from
each other's repos directly,
1:11
as we've shown here.
1:14
But it's more common to declare
one repo the central repo.
1:15
Developers clone this central repo to
their local machines over the network,
1:19
then each developer begins working on
their own separate set of changes.
1:24
A developer adds their
changes to the central repo
1:28
by pushing commits to it over the network.
1:31
Other developers receive these commits by
pulling them down from the central repo,
1:34
and they can push up their
own changes in return.
1:39
This is the system that GitHub, Bitbucket,
and other Git hosting services support.
1:42
But how do you create all those
repositories in the first place?
1:47
The easiest way to get a new repo
based off another is to clone it,
1:50
to make a copy of it.
1:54
This copy will have all the same
files in the working directory,
1:56
plus a full copy of the project's history.
1:59
Normally you clone from one computer
to another over the Internet or
2:02
some other network.
2:05
But we can also clone from one directory
to another on the same computer and
2:06
everything will work the same.
2:11
We're going to do that while
we get used to the commands.
2:12
We need to be in the workspace directory,
which contains our medals repo.
2:15
If you just restarted your workspace,
you'll already be there.
2:19
But if we're currently in
the medals repo directory,
2:22
you'll need to change directories.
2:25
We can get there by changing to
the parent directory, that is,
2:27
the directory that contains this one.
2:30
Linux, Mac, and
Windows shells all use two dots,
2:33
two period characters to
represent the parent directory.
2:37
So now we're in the parent directory,
the directory named workspace.
2:41
Now, let's clone the medals repository.
2:45
We do this with the git clone command.
2:48
The first argument to git clone should
be the location of the repository you
2:51
want to clone.
2:55
Normally this would be the URL of
a repo out on the network somewhere
2:56
which we'll show you how to do later.
3:00
But for this demonstration,
3:02
we'll just clone from the medals
repo in our local directory.
3:04
The second argument is the name of
the director you want to clone into.
3:09
We'll name it my clone.
3:13
It will take a moment to clone
the repository with all its history and
3:16
check out a copy of all the files
into the new working directory.
3:19
It will show a message when its done and
return us to our shell prompt.
3:22
If we run ls,
we'll see a new myclone directory.
3:27
We can change into that with cd myclone.
3:31
The slash character following
the directory name in the cd
3:36
command is optional, by the way.
3:39
If we run ls here in
the working directory,
3:41
we'll see copies of all our files.
3:43
Remember ls -a shows all files,
even ones that are hidden,
3:45
by placing a dot at
the start of their names.
3:50
If we run it here,
3:53
we'll see another .git directory that
holds a copy of our repo history.
3:54
We can review that copy of the repo
history with the git log command.
3:59
It will show us the completely history
of changes from the original repo
4:04
up to the time it was cloned.
4:08
Of course whoever is working in the
original medals repo was probably going
4:10
to keep making changes to it.
4:14
And those changes won't show up in
our clone unless we find a way to
4:16
copy them over.
4:19
We'll learn how to do
that in the next video.
4:21
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up