相当于

svn export . otherpath

在现有回购协议中

git archive branchname | (cd otherpath; tar x)

相当于

svn export url otherpath

is

git archive --remote=url branchname | (cd otherpath; tar x)

在添加前缀（例如目录名）时将git导出到zip存档：

git archive master --prefix=directoryWithinZip/  --format=zip -o out.zip

这样做很简单，这是.bash_profile的一个函数，它直接在当前位置解压缩存档文件，首先配置您常用的[url:path]。注意：使用此功能可以避免克隆操作，它直接从远程存储库获取。

gitss() {
    URL=[url:path]

    TMPFILE="`/bin/tempfile`"
    if [ "$1" = "" ]; then
        echo -e "Use: gitss repo [tree/commit]\n"
        return
    fi
    if [ "$2" = "" ]; then
        TREEISH="HEAD"
    else
        TREEISH="$2"
    fi
    echo "Getting $1/$TREEISH..."
    git archive --format=zip --remote=$URL/$1 $TREEISH > $TMPFILE && unzip $TMPFILE && echo -e "\nDone\n"
    rm $TMPFILE
}

.gitconfig的别名，需要相同的配置（注意在.git项目中执行命令，它总是跳转到前面所说的基本目录，直到修复为止，我个人更喜欢这个函数

ss = !env GIT_TMPFILE="`/bin/tempfile`" sh -c 'git archive --format=zip --remote=[url:path]/$1 $2 \ > $GIT_TMPFILE && unzip $GIT_TMPFILE && rm $GIT_TMPFILE' -

我认为@Aredridel的帖子是最接近的，但还有更多的内容——所以我将在这里补充这一点；问题是，在svn中，如果你在repo的子文件夹中，并且你做到了：

/media/disk/repo_svn/subdir$ svn export . /media/disk2/repo_svn_B/subdir

然后svn将导出所有受修订控制的文件（它们也可能是新添加的；或已修改的状态）-如果您在该目录中有其他“垃圾”（我不在这里计算.svn子文件夹，而是像.o文件这样的可见文件），它将不会导出；将仅导出SVN repo注册的那些文件。对我来说，一件好事是，这个导出还包括尚未提交的具有本地更改的文件；另一个好处是导出文件的时间戳与原始文件的时间相同。或者，正如svn help export所说：

从指定的工作副本导出干净的目录树路径1，修订版本REV（如果给出），否则在工作时路径2….如果未指定REV，则所有本地将保留更改。不受版本控制的文件将不能复制。

要了解git不会保留时间戳，请比较以下命令的输出（在您选择的git repo的子文件夹中）：

/media/disk/git_svn/subdir$ ls -la .

…和：

/media/disk/git_svn/subdir$ git archive --format=tar --prefix=junk/ HEAD | (tar -t -v --full-time -f -)

…无论如何，我注意到gitarchive会导致归档文件的所有时间戳都相同！git帮助存档说：

git存档在给定树ID时的行为与给定提交ID或标记ID时的不同。在第一种情况下当前时间用作存档中每个文件的修改时间。在后一种情况下，记录的提交时间在引用的提交对象中。

…但显然这两种情况都设置了“每个文件的修改时间”；从而不保留那些文件的实际时间戳！

因此，为了保留时间戳，这里有一个bash脚本，它实际上是一个“单行”，尽管有些复杂-所以下面以多行形式发布：

/media/disk/git_svn/subdir$ git archive --format=tar master | (tar tf -) | (\
  DEST="/media/diskC/tmp/subdirB"; \
  CWD="$PWD"; \
  while read line; do \
    DN=$(dirname "$line"); BN=$(basename "$line"); \
    SRD="$CWD"; TGD="$DEST"; \
    if [ "$DN" != "." ]; then \
      SRD="$SRD/$DN" ; TGD="$TGD/$DN" ; \
      if [ ! -d "$TGD" ] ; then \
        CMD="mkdir \"$TGD\"; touch -r \"$SRD\" \"$TGD\""; \
        echo "$CMD"; \
        eval "$CMD"; \
      fi; \
    fi; \
    CMD="cp -a \"$SRD/$BN\" \"$TGD/\""; \
    echo "$CMD"; \
    eval "$CMD"; \
    done \
)

请注意，假设您正在导出“当前”目录（上面的/media/disk/git_svn/subdr）中的内容，并且导出到的目标位置有些不方便，但它位于DEST环境变量中。请注意，使用此脚本；在运行上述脚本之前，必须自己手动创建DEST目录。

运行脚本后，您应该能够比较：

ls -la /media/disk/git_svn/subdir
ls -la /media/diskC/tmp/subdirB   # DEST

…并希望看到相同的时间戳（对于那些受版本控制的文件）。

希望这对某人有所帮助，干杯

这似乎与SVN相比，Git的问题更小。Git只在存储库根目录中放置.Git文件夹，而SVN在每个子目录中放置.SVN文件夹。因此，“svn-export”避免了递归命令行魔法，而使用Git递归则是不必要的。

我的首选实际上是在Makefile（或其他构建系统）中有一个dist目标，它可以导出代码的可分发存档（.tar.bz2、.zip、.jar或其他合适的文件）。如果您碰巧使用GNU自动工具或Perl的MakeMaker系统，我认为这是自动存在的。如果没有，我强烈建议添加它。

ETA（2012-09-06）：哇，一票否决。我仍然认为，使用构建工具而不是源代码控制工具来构建发行版更好。我相信使用构建工具构建工件。在我目前的工作中，我们的主要产品是以蚂蚁为目标构建的。我们正处于切换源代码控制系统的过程中，这个蚂蚁目标的出现意味着迁移过程中少了一点麻烦。