Git Basics | git clone
The git clone command
git clone is the command for making a copy of an existing Git repository. It is similar to svn checkout, but differs in that the working copy itself forms a complete Git repository, maintains its own change history, manages its own files, and provides an environment that is completely independent from the original repository.
For convenience, cloning automatically creates a remote connection named origin that points to the original repository. This makes it very easy to communicate with the central repository.
Usage
git clone <repo>
Clones the repository at <repo> to the local machine. The repository at <repo> may exist on the same local machine or on a remote machine accessed over HTTP or SSH.
git clone <repo> <directory>
Clones the repository at <repo> to a folder named <directory> on the local machine.
Notes
When a central repository already exists, git clone is the most common command for creating a developer’s working copy. Like git init, cloning is usually a one-time operation. After a developer creates a working copy, or local repository, all version control and collaboration happens through that local repository.
Repository-to-repository collaboration
It is important to understand that a Git “working copy” is very different from the working copy obtained by checking out code from an SVN repository. Unlike SVN, Git has no substantial difference between a working copy and a central repository. Both are complete Git repositories.
Because of this, Git collaboration and SVN collaboration are fundamentally different. In SVN, the relationship between the central repository and working copy plays an important role. In Git, the collaboration model is interaction between repositories. SVN checks a working copy into the central repository, while Git pushes or pulls commits from one repository to another.
Git Tutorial: Collaboration Between Repositories
Of course, you can assign special meaning to a Git repository you own. For example, by designating one Git repository as the “central” repository, you can follow a centralized workflow in Git as well. The important point is that this is not determined by the version control system or physical connection state; in Git, it is simply a convention.
Example
The following example shows how to create a working copy of a central repository stored on a server when the address is example.com and the SSH user name is john:
git clone ssh://john@example.com/path/to/my-project.git
cd my-project
# Start working on the project
The first line creates and initializes a new Git repository in the my-project folder on the local machine, then fetches the files from the central repository.
After this completes, move into the project directory and start editing, committing snapshots, communicating with other repositories, and so on.
Also, the cloned repository does not have the .git extension added. This means the local copy is not a bare repository.