Here we will examine the git clone command
in depth. git clone is a Git command-line utility used to point to an existing repository and create a clone or copy of the target repository. On this page we will discuss extended configuration options and common git clone use cases. Some points we’ll cover here are:
Clone a
- local or remote repository Clone
- bare
- Using shallow options to partially clone repositories
- Git URL syntax and supported protocols
a
repository
In the repository configuration guide, we cover a basic git clone use case. This page will explore more complex cloning and configuration scenarios.
Purpose:
Repository-to-repository collaborative development copy
If a project has already been set up in a central repository, the git clone command is the most common way for users to get a development copy. Like git init, cloning is generally a one-time operation. Once a developer has obtained a working copy, all version control and collaboration operations are managed through their local repository.
Repository-to-repository collaboration
It’s important to understand that Git’s idea of a “working copy” is very different from the working copy you get when pulling code from an SVN repository. Unlike SVN, Git makes no distinction between the working copy and the central repository: they are all full Git repositories.
This makes collaborating with Git fundamentally different than with SVN. While SVN depends on the relationship between the central repository and the working copy, Git’s collaboration model is based on repository-to-repository interaction. Instead of checking a working copy into the central SVN repository, it sends or pulls commits from one repository to another.
Of course, there’s nothing stopping you from giving certain Git repositories special meaning. For example, by simply designating a Git repository as a “central” repository, it is possible to replicate a centralized workflow using Git. The point is that this is achieved through conventions rather than being wired into the VCS itself.
Using
git clone is primarily used to point to an existing repository and make a clone or copy of that repository to a new directory, in another location. The original repository can be located on the local file system or on supported protocols accessible by remote machines. The git clone command copies an existing Git repository. This is somewhat like the SVN checkout, except that the “working copy” is a complete Git repository: it has its own history, manages its own files, and is a completely isolated environment from the original repository.
For your convenience, cloning automatically creates a remote connection called a “source” that points to the original repository. This makes it very easy to interact with a central repository. This automatic connection is established by creating Git references to remote branch managers in refs/remotes/origin and initializing the configuration variables remote.origin.url and remote.origin.fetch.
An example demonstrating the use of git clone can be found in a repository configuration guide. The following example shows how to get a local copy of a central repository stored on a server accessible on example.com using the SSH username john: The
first command initializes a new Git repository in the my-project folder on your local machine and populates it with the contents of the central repository. You can then create a cd in your project and start editing files, committing snapshots, and interacting with other repositories. Note also that the .git extension is omitted from the cloned repository. This reflects the non-bare state of the local copy.
Clone to a specific folder Clone the repository located in the
folder
named ~! on the local machine.
Clone a specific tag
Clone the repository located in and only clone the reference for .
Shallow clone Clone the
repository located in and only clone
the commit history specified by the
depth=1 option. This example clones and includes only the most recent commit to the new cloned repository. Shallow cloning is most useful when working with repositories that have an extensive commit history. An extensive commit history can cause scaling issues, such as disk space usage limits and long wait times during cloning. A shallow clone can help alleviate these scaling issues.
git
clone -branch
configuration options
The -branch argument allows you to specify a specific branch to clone instead of the branch that the remote HEAD points to, typically the parent branch. Also, you can pass a label instead of a branch for the same effect.
This example above would clone only the new_feature branch of the remote Git repository. This is purely a convenience utility to save you time by downloading the HEAD reference from the repository and then having to additionally obtain the reference you need.
Git Clone –
mirror vs
. git clone -bare git clone -bare Similar to git
init
–
bare, when the -bare argument is passed to git clone, a copy of the remote repository will be made with a skipped working directory. This means that a repository will be set up with the history of the project that can be sent and checked out, but cannot be edited directly. In addition, no remote branches will be configured for the repository with the -bare repository. Like git init -bare, this is used to create a hosted repository that developers won’t edit directly.
git clone
-mirror Passing the –
mirror argument implicitly passes the -bare argument as well. This means that the behavior of -bare is inherited by -mirror. The result is a bare repository with no editable work files. In addition, -mirror will clone all extended references from the remote repository and maintain remote branch tracking settings. You can then run the git remote update on the mirror and it will overwrite all references from the source repository. Giving it exact ‘mirrored’ functionality.
For
a complete list of other git cloning options, visit the official Git documentation. In this document, we will address some other common options.
git clone -template Clone
the repository to <
repository location> and applies the template from to the newly created local branch. You can find a full refrence in Git templates on our git init page.
Git
URL Git
has its own URL syntax that is used to pass remote repository locations to Git commands. Because the git clone is most commonly used in remote repositories, we’ll examine the Git URL syntax here.
GIT URL
-SSH
Protocols Secure Shell (SSH) is a ubiquitous authenticated network protocol that is commonly configured by default on most servers. Because SSH is an authenticated protocol, you will need to establish credentials with the hosting server before connecting. ssh://[user@]host.xz[:p ort]/path/to/repo.git/
–
GIT
A git-only protocol. Git comes with a daemon that runs on the port (9418). The protocol is similar to SSH, however, IT HAS NO AUTHENTICATION. git://host.xz[:p ort]/path/to/repo.git/
–
HTTP Hypertext Transfer Protocol. The web protocol, most commonly used to transfer HTML data from web pages over the Internet. Git can be configured to communicate over HTTP http[s]://host.xz[:p ort]/path/to/repo.git/
Summary
In this paper we take an in-depth look at the git clone. The most important conclusions are: 1. The git clone is used to create a copy of a target repository
2. The target repository can be local or remote
3. Git supports some network protocols for connecting to remote repositories
4. There are many different configuration options available that change the contents of the clone
For a more in-depth reference on git cloning functionality, see the official Git documentation. We also cover practical examples of git cloning in our repository setup guide.