How to clone repository from git

How do I clone a Git repository into a specific folder?

The command git clone git@github.com:whatever creates a directory named whatever containing a Git repository:

19 Answers 19

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Option A:

Ergo, for right here use:

Option B:

Better yet:

Keep your working copy somewhere else, and create a symbolic link. Like this:

For your case this would be something like:

Which easily could be changed to test if you wanted it, i.e.:

If you just want it to work, use Option A, if someone else is going to look at what you have done, use Option C.

The example I think a lot of people asking this question are after is this. If you are in the directory you want the contents of the git repository dumped to, run:

The «.» at the end specifies the current folder as the checkout folder.

Go into the folder.. If the folder is empty, then:

Basic Git Repository Cloning

You clone a repository with

For example, if you want to clone the Stanford University Drupal Open Framework Git library called open_framework, you can do so like this:

Cloning a Repository Into a Specific Local Folder

If you want to clone the repository into a directory named something other than open_framework, you can specify that as the next command-line option:

That command does the same thing as the previous one, but the target directory is called mynewtheme.

Git has a number of different transfer protocols you can use. The previous example uses the git:// protocol, but you may also see http(s):// or user@server:/path.git, which uses the SSH transfer protocol.

Although it’ll still create a whatever folder on top of it, so to clone the content of the repository into current directory, use the following syntax:

Note that cloning into an existing directory is only allowed when the directory is empty.

You can use following git command to clone with custom directory name

Note: You don’t need to create your custom directory because it will create automatically

To clone to Present Working Directory:

To clone to Another Directory:

If you want to clone into the current folder, you should try this:

It contains the repo and the supporting files, while the project files that are in your /public directory are only the versions in the currently check-out commit (master branch by default).

Usage

Clone the repository located at the onto the local machine. The original repository can be located on the local filesystem or on a remote machine accessible via HTTP or SSH.

Clone the repository located at into the folder called on the local machine.

Clone the «specific branch»:

From some reason this syntax is not standing out:

git clone repo-url [folder]

Here folder is an optional path to the local folder (which will be a local repository).

Git clone will also pull code from remote repository into the local repository. In fact it is true:

Here’s how I would do it, but I have made an alias to do it for me.

There is probably a more elegant way of doing this, however I found this to be easiest for myself.

Here’s the alias I created to speed things along. I made it for zsh, but it should work just fine for bash or any other shell like fish, xyzsh, fizsh, and so on.

My personal preference, however, is to make a zsh plugin to keep track of all my aliases. You can create a personal plugin for oh-my-zsh by running these commands:

Afterwards, add these lines to your newly created blank alises.plugin file:

(From here, replace your name with mine.)

Then, in order to get the aliases to work, they (along with zsh) have to be sourced-in (or whatever it’s called). To do so, inside your custom plugin document add this:

I’m in the process of making a Git repository with all of my aliases. Please feel free to check them out here: Ev’s dot-files. Please feel free to fork and improve upon them to suit your needs.

Git on the command line

Git is an open-source distributed version control system. GitLab is built on top of Git.

You can do many Git operations directly in GitLab. However, the command line is required for advanced tasks, like fixing complex merge conflicts or rolling back commits.

If you’re new to Git and want to learn by working in your own project, learn how to make your first commit.

For a quick reference of Git commands, download a Git Cheat Sheet.

To help you visualize what you’re doing locally, you can install a Git GUI app.

Choose a terminal

Confirm Git is installed

You can determine if Git is already installed on your computer by opening a terminal and running this command:

If Git is installed, the output is:

If your computer doesn’t recognize git as a command, you must install Git.

Configure Git

To start using Git from your computer, you must enter your credentials to identify yourself as the author of your work. The username and email address should match the ones you use in GitLab.

In your shell, add your user name:

Add your email address:

To check the configuration, run:

You can read more on how Git manages configurations in the Git configuration documentation.

Choose a repository

Before you begin, choose the repository you want to work in. You can use any project you have permission to access on GitLab.com or any other GitLab instance.

You can fork any project you have access to.

Clone a repository

When you clone a repository, the files from the remote repository are downloaded to your computer, and a connection is created.

This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.

Clone with SSH

Run this command:

To view the files, go to the new directory:

Clone with HTTPS

Run the following command. Git automatically creates a folder with the repository name and downloads the files there.

To view the files, go to the new directory:

Convert a local directory into a repository

Run this command:

Add a remote

You add a “remote” to tell Git which remote repository in GitLab is tied to the specific local folder on your computer. The remote tells Git where to push or pull from.

On your computer, open the terminal in the directory you’ve initialized, paste the command you copied, and press enter :

View your remote repositories

To view your remote repositories, type:

Download the latest changes in the project

To work on an up-to-date copy of the project, you pull to get all the changes made by users since the last time you cloned or pulled the project. Replace with the name of your default branch to get the main branch code, or replace it with the branch name of the branch you are currently working in.

You can learn more on how Git manages remote repositories in the Git Remote documentation.

Branches

A new branch is often called feature branch to differentiate from the default branch.

Create a branch

To create a feature branch:

Switch to a branch

All work in Git is done in a branch. You can switch between branches to see the state of the files and work in that branch.

To switch to an existing branch:

For example, to change to the main branch:

View differences

To view the differences between your local unstaged changes and the latest version that you cloned or pulled:

View the files that have changes

When you add, change, or delete files or folders, Git knows about the changes. To check which files have been changed:

Add and commit local changes

To stage a file for commit:

Confirm that the files have been added to staging:

The files should be displayed in green text.

To commit the staged files:

Stage and commit all changes

As a shortcut, you can add all local changes to staging and commit them with one command:

Send changes to GitLab.com

To push all local changes to the remote repository:

For example, to push your local commits to the main branch of the origin remote:

Sometimes Git does not allow you to push to a repository. Instead, you must force an update.

Delete all changes in the branch

To discard all changes to tracked files:

This action removes changes to files, not the files themselves. Untracked (new) files do not change.

Unstage all changes that have been added to the staging area

To unstage (remove) all files that have not been committed:

Undo most recent commit

To undo the most recent commit:

This action leaves the changed files and folders unstaged in your local repository.

You can learn more about the different ways Git can undo changes in the Git Undoing Things documentation.

Merge a branch with default branch

When you are ready to add your changes to the default branch, you merge the feature branch into it:

In GitLab, you typically use a merge request to merge your changes, instead of using the command line.

To create a merge request from a fork to an upstream repository, see the forking workflow.

Advanced use of Git through the command line

For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.

Synchronize changes in a forked repository with the upstream

To create a copy of a repository in your namespace, you fork it. Changes made to your copy of the repository are not automatically synchronized with the original. To keep the project in sync with the original project, you need to pull from the original repository.

You can now use the upstream as a to pull new updates from the original repository, and use the origin to push local changes and create merge requests.

How to clone repository from git

Check your version of git by running

SYNOPSIS

DESCRIPTION

After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any (this is untrue when «—single-branch» is given; see below).

This default configuration is achieved by creating references to the remote branch heads under refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables.

OPTIONS

Operate quietly. Progress is not reported to the standard error stream.

Run verbosely. Does not affect the reporting of progress status to the standard error stream.

No checkout of HEAD is performed after the clone is complete.

When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end.

Specify the directory from which templates will be used; (See the «TEMPLATE DIRECTORY» section of git-init[1].)

Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out. The key is in the same format as expected by git-config[1] (e.g., core.eol=true ). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add additional fetch refspecs to the origin remote.

Create a shallow clone with a history after the specified time.

Create a shallow clone with a history, excluding commits reachable from a specified remote branch or tag. This option can be specified multiple times.

All submodules which are cloned will be shallow with a depth of 1.

Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree.

The number of submodules fetched at the same time. Defaults to the submodule.fetchJobs option.

The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.

The name of a new directory to clone into. The «humanish» part of the source repository is used if no directory is explicitly given ( repo for /path/to/repo.git and foo for host.xz:foo/.git ). Cloning into an existing directory is only allowed if the directory is empty.

GIT URLS

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.

The following syntaxes may be used with them:

git-clone(1) Manual Page

SYNOPSIS

DESCRIPTION

After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any (this is untrue when «—single-branch» is given; see below).

This default configuration is achieved by creating references to the remote branch heads under refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables.

OPTIONS

Operate quietly. Progress is not reported to the standard error stream.

Run verbosely. Does not affect the reporting of progress status to the standard error stream.

No checkout of HEAD is performed after the clone is complete.

Fail if the source repository is a shallow repository. The clone.rejectShallow configuration variable can be used to specify the default.

Employ a sparse-checkout, with only files in the toplevel directory initially being present. The git-sparse-checkout(1) command can be used to grow the working directory as needed.

When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end.

Specify the directory from which templates will be used; (See the «TEMPLATE DIRECTORY» section of git-init(1).)

Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out. The key is in the same format as expected by git-config(1) (e.g., core.eol=true ). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add additional fetch refspecs to the origin remote.

Create a shallow clone with a history after the specified time.

Create a shallow clone with a history, excluding commits reachable from a specified remote branch or tag. This option can be specified multiple times.

After the clone is created, initialize and clone submodules within based on the provided pathspec. If no pathspec is provided, all submodules are initialized and cloned. This option can be given multiple times for pathspecs consisting of multiple entries. The resulting clone has submodule.active set to the provided pathspec, or «.» (meaning all submodules) if no pathspec is provided.

All submodules which are cloned will be shallow with a depth of 1.

Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree.

The number of submodules fetched at the same time. Defaults to the submodule.fetchJobs option.

The (possibly remote) repository to clone from. See the GIT URLS section below for more information on specifying repositories.

The name of a new directory to clone into. The «humanish» part of the source repository is used if no directory is explicitly given ( repo for /path/to/repo.git and foo for host.xz:foo/.git ). Cloning into an existing directory is only allowed if the directory is empty.

GIT URLS

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.

The following syntaxes may be used with them:

Setting up a repository

This tutorial provides an overview of how to set up a repository (repo) under Git version control. This resource will walk you through initializing a Git repository for a new or existing project. Included below are workflow examples of repositories both created locally and cloned from remote repositories. This guide assumes a basic familiarity with a command-line interface.

The high level points this guide will cover are:

By the end of this module, you should be able to create a Git repo, use common Git commands, commit a modified file, view your project’s history and configure a connection to a Git hosting service (Bitbucket).

What is a Git repository?

A Git repository is a virtual storage of your project. It allows you to save versions of your code, which you can access when needed.

Initializing a new repository: git init

Versioning an existing project with a new git repository

This example assumes you already have an existing project folder that you would like to create a repo within. You’ll first cd to the root project folder and then execute the git init command.

Pointing git init to an existing project directory will execute the same initialization setup as mentioned above, but scoped to that project directory.

Cloning an existing repository: git clone

git clone is used to create a copy or clone of remote repositories. You pass git clone a repository URL. Git supports a few different network protocols and corresponding URL formats. In this example, we’ll be using the Git SSH protocol. Git SSH URLs follow a template of: git@HOSTNAME:USERNAME/REPONAME.git

An example Git SSH URL would be: git@bitbucket.org:rhyolight/javascript-data-store.git where the template values match:

For more documentation on git clone usage and supported Git URL formats, visit the git clone Page.

Saving changes to the repository: git add and git commit

«test content for git tutorial»

After executing this example, your repo will now have CommitTest.txt added to the history and will track future updates to the file.

Repo-to-repo collaboration: git push

It’s important to understand that Git’s idea of a “working copy” is very different from the working copy you get by checking out source code from an SVN repository. Unlike SVN, Git makes no distinction between the working copies and the central repository—they’re all full-fledged Git repositories.

This makes collaborating with Git fundamentally different than with SVN. Whereas 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 SVN’s central repository, you push or pull commits from one repository to another.

Of course, there’s nothing stopping you from giving certain Git repos special meaning. For example, by simply designating one Git repo as the “central” repository, it’s possible to replicate a centralized workflow using Git. This is accomplished through conventions rather than being hardwired into the VCS itself.

Bare vs. cloned repositories

If you used git clone in the previous «Initializing a new Repository» section to set up your local repository, your repository is already configured for remote collaboration. git clone will automatically configure your repo with a remote pointed to the Git URL you cloned it from. This means that once you make changes to a file and commit them, you can git push those changes to the remote repository.

If you used git init to make a fresh repo, you’ll have no remote repo to push changes to. A common pattern when initializing a new repo is to go to a hosted Git service like Bitbucket and create a repo there. The service will provide a Git URL that you can then add to your local Git repository and git push to the hosted repo. Once you have created a remote repo with your service of choice you will need to update your local repo with a mapping. We discuss this process in the Configuration & Set Up guide below.

Configuration & set up: git config

In addition to configuring a remote repo URL, you may also need to set global Git configuration options such as username, or email. The git config command lets you configure your Git installation (or an individual repository) from the command line. This command can define everything from user info, to preferences, to the behavior of a repository. Several common configuration options are listed below.

Git stores configuration options in three separate files, which lets you scope options to individual repositories (local), user (Global), or the entire system (system):

Define the author name to be used for all commits by the current user.

Define the author email to be used for all commits by the current user.

Create a shortcut for a Git command. This is a powerful utility to create custom shortcuts for commonly used git commands. A simplistic example would be:

Open the global configuration file in a text editor for manual editing. An in-depth guide on how to configure a text editor for git to use can be found on the Git config page.

Discussion

Git stores configuration options in three separate files, which lets you scope options to individual repositories, users, or the entire system:

When options in these files conflict, local settings override user settings, which override system-wide. If you open any of these files, you’ll see something like the following:

Example

The first thing you’ll want to do after installing Git is tell it your name/email and customize some of the default settings. A typical initial configuration might look something like the following:

Tell Git who you are git config

Select your favorite text editor

Add some SVN-like aliases

This will produce the

/.gitconfig file from the previous section. Take a more in-depth look at git config on the git config page.

Summary

Here we demonstarted how to create a git repository using two methods: git init and git clone. This guide can be applied to manage software source code or other content that needs to be versioned. Git add, git commit, git push, and git remote were also introduced and utilized at a high level.