Is there a flag to pass to git
when doing a clone, say don't clone the .git
directory? If not, how about a flag to delete the .git
directory after the clone?

- 18,243
- 4
- 34
- 63

- 42,716
- 77
- 201
- 296
-
45This question is _not_ a dupe of [How to do a "git export" (like "svn export")](http://stackoverflow.com/questions/160608/how-to-do-a-git-export-like-svn-export). This question asks on how to _clone_ a (remote) repository _without_ the `.git` directory. The alleged dupe asks how to _export_ an existing repository where you already have the `.git` directory. – mknaf Oct 21 '13 at 20:18
-
3Agree. You cannot `git archive` remote repository as the "possible duplicate" solution says. – Vladislav Rastrusny Aug 05 '14 at 08:28
9 Answers
Use
git clone --depth=1 --branch=master git://someserver/somerepo dirformynewrepo
rm -rf ./dirformynewrepo/.git
- The depth option will make sure to copy the least bit of history possible to get that repo.
- The branch option is optional and if not specified would get the default branch.
- The second line will make your directory
dirformynewrepo
not a Git repository any more. - If you're doing recursive submodule clone, the depth and branch parameter don't apply to the submodules.

- 4,687
- 3
- 25
- 49

- 124,556
- 26
- 146
- 141
-
15For those interested, it's one of the [word designators](https://gnu.org/software/bash/manual/html_node/Word-Designators.html), part of the [history expansion](https://www.gnu.org/software/bash/manual/html_node/History-Interaction.html#History-Interaction) feature in Bash and zsh. – Rufflewind Mar 01 '15 at 09:21
-
Is there a way to get the depth=1 of all branches in the repo? not just master or specified branch – Gayan Pathirage Mar 07 '16 at 09:03
-
3you do that with the --no-single-branch option, since --depth implies --single-branch, you can un-imply it with --no-single-branch. (Taken from the git clone man page) – Robert Stoddard Jul 20 '16 at 22:00
-
Great answer, this is useful when cloning from e.g. gitlab and wanting to start afresh – StudioTime Sep 01 '17 at 18:29
-
17Using `!$`, while technically correct in this instance, does nothing to help people who don't recognise the syntax understand the answer to the actual question. It also relies on the second command directly following the first, and within the same shell. If anyone omits those implicit requirements, they may end up deleting something else entirely. Therefore I suggest your answer could be improved by explicitly specifying the name `dirformynewrepo` as an argument to the `rm` command as it will make the connection between both commands much clearer. – davidA Aug 22 '18 at 21:32
-
-
-
Is ./dirformynewrepo the name of the repo that's being pulled or a specific folder in it – Wayne Jun 16 '21 at 02:44
-
@Wayne `dirformynewrepo` is the local dir where you want to copy the repo to. The name of the live repo in this example is `somerepo` – Jules Colle Mar 08 '23 at 20:57
since you only want the files, you don't need to treat it as a git repo.
rsync -rlp --exclude '.git' user@host:path/to/git/repo/ .
and this only works with local path and remote ssh/rsync path, it may not work if the remote server only provides git:// or https:// access.

- 2,254
- 2
- 26
- 31
-
1
-
itub is right, this is just copying the work tree. git checkout used to do that properly, now it does not any longer. – Sylvain Aug 04 '16 at 17:06
-
1
Alternatively, if you have Node.js installed, you can use the following command:
npx degit GIT_REPO
npx
comes with Node, and it allows you to run binary node-based packages without installing them first (alternatively, you can first install degit
globally using npm i -g degit
).
Degit is a tool created by Rich Harris, the creator of Svelte and Rollup, which he uses to quickly create a new project by cloning a repository without keeping the git folder. But it can also be used to clone any repo once...

- 5,550
- 2
- 28
- 23
git clone --separate-git-dir=$(mktemp -u) --depth=1 <repo> <dir> && rm <dir>/.git
I like this solution more because I don't like rm -rf
ing things automatically. It just rm
s a .git file, which means it could never accidentally rm -rf
a wrong .git directory
It has a dependency on mktemp
command so it'll work *nix systems (from what I see this needs further work for the mktemp
to work on MacOS, so if anyone wants to comment a working solution I'll add it)
In zsh, I made that a function so I ensure a dir
value is defined:
alias np='node-project'
function node-project() {
dir=${1:-.}
git clone --separate-git-dir=$(mktemp -u) --depth=1 <my-node-repo> $dir && rm $dir/.git
}
Explanation
The --separate-git-dir
flag lets you specify a path for the .git directory. The resulting "project" will have a .git file (not a directory) whose content will be a single line:
gitdir: <the dir you specified in the flag>
Because we used a tmp dir with the mktemp
command, the actual .git
directory contents will end up in a tmp dir. We also use a --depth=1
so it takes less space on tmp dirs.

- 1,962
- 4
- 27
- 45
-
3Point of clarification - this still creates a `.git` equivalent folder, it's just stored in wherever `mktemp` chooses to put it instead of the `git clone` destination. When you `rm
/.git` as per this answer, you're effectively just removing a symlink to the tmp folder created elsewhere with the normal `.git` files. The files are being left until the OS processes automatically cleans up the temporary directory used by `--separate-git-dir`. So, to properly clean up, you may still want the `rm -rf`, just for the `git` folder stored in the temp folder instead of in the clone target. – mbafford May 23 '22 at 14:48
For those who doubt the --depth 1
solution because it still download the .git
directory and you need to manually remove it afterward, maybe you need to know how git clone actually works.
When you normally clone a repo, git download all your files (spanning across commits) into the .git
directory. When you clone with --depth 1
, git only downloads the latest version of the files into .git
. After that, git will checkout
or retrieve those files from .git
into the working directory (no more download).
And oftentimes, because the file objects inside .git
is compressed, you will save more bandwidth by downloading the files with git clone --depth 1
rather than downloading the uncompressed files. And for some people with slow internet, that is worth the price (the need to run rm -rf
).
I personally think the git archive
solution is better but since it's not supported by GitHub, --depth 1
is the way to go.

- 998
- 11
- 26
-
1If it's GitHub, why not just `curl -L https://github.com/${owner}/${repo}/tarball/master | tar xz` ? – Des Nerger Sep 11 '21 at 04:26
-
@DesNerger Because we can easily clone from private repo with ssh – M Imam Pratama Sep 11 '21 at 17:54
git clone --depth=1 --branch=master git://someserver/somerepo dirformynewrepo1
rd /s /q .\dirformynewrepo1\.git
this works for windows systems

- 19
- 3
If the repository is on GitHub, you can simply download a ZIP file of any tag:
curl -L https://github.com/<user>/<repo-name>/archive/refs/tags/v1.2.3.zip | tar xz
This will download and uncompress the repository. The contents will be in <repo-name>-1.2.3
, with no .git
folder.

- 894
- 1
- 8
- 19

- 20,262
- 30
- 97
- 159
-
1Very neat trick, but there are a lot of Git repositories that are not hosted on GitHub. – Carl Winbäck Apr 11 '23 at 07:04
-
1Good point. Well. They should simply move to github. I am joking. Well, I am sure it is possible to di similar thing also onnother hosts. – sensorario Apr 12 '23 at 08:14
git archive --remote
already implements this.

- 51,870
- 39
- 111
- 135
-
Any combination of `git archive --remote` I tried from posts online failed me with `Invalid command: 'git-upload-archive '
'` – Guido Tarsia Apr 22 '22 at 15:59 -
Try: `git archive --remote git@gitlab.com:gitlab-org/gitlab.git -o gitlab_15.9.3ee.tgz v15.9.3-ee` – mr.wolle Mar 13 '23 at 09:04
-
You can always do
git clone git://repo.org/fossproject.git && rm -rf fossproject/.git
-
54download everything and delete the dir later? for instance emacs has 95% of 1GB in the .git. so --depth=1 is the solution here clearly. – RParadox May 08 '13 at 11:37
-
2
-
2@AryehArmon of course you see it. Using --depth does not prevent the creation of .git, it just makes it a shallow copy, so much smaller size for .git. But if you do not want it there at all, you need to remove it afterwards. – zeycus Aug 08 '17 at 12:13