Чи є "експорт git" (наприклад, "SVN-експорт")?

Мені було цікаво, чи є хороше рішення "git export", яке створює копію дерева без .gitкаталогу сховищ. Існує щонайменше три методи, про які я знаю:

1. git cloneз подальшим видаленням .gitкаталогу репозиторію.
2. git checkout-index натякає на цю функціональність, але починається з "Просто прочитайте потрібне дерево в індекс ...", що я не зовсім впевнений, як це зробити.
3. git-exportє стороннім сценарієм, який по суті git cloneпереходить у тимчасове місце розташування, а потім - rsync --exclude='.git'у кінцеве місце призначення.

Жодне з цих рішень насправді не вважає задовільним. Найближчим svn exportваріантом може бути варіант 1, оскільки обидва вимагають, щоб цільовий каталог спочатку був порожнім. Але варіант 2 здається ще кращим, якщо припустити, що я можу зрозуміти, що означає прочитати дерево в індекс.

Напевно, найпростіший спосіб досягти цього git archive. Якщо вам справді потрібне просто розгорнуте дерево, ви можете зробити щось подібне.

git archive master | tar -x -C /somewhere/else

Більшу частину часу мені потрібно "експортувати" з git, я хочу в будь-якому випадку стислий архів, тому я роблю щось подібне.

git archive master | bzip2 >source-tree.tar.bz2

Архів ZIP:

git archive --format zip --output /full/path/to/zipfile.zip master 

git help archive Докладніше, це досить гнучко.

Майте на увазі, що хоча архів не буде містити каталог .git, він, однак, буде містити інші приховані файли, характерні для git, такі як .gitignore, .gitattributes тощо. Якщо ви не хочете, щоб вони були в архіві, переконайтеся, що ви використовуйте атрибут export-ignore у файлі .gitattributes і виконайте це, перш ніж зробити свій архів. Детальніше ...

Примітка: Якщо ви зацікавлені в експорті індексу, команда така

git checkout-index -a -f --prefix=/destination/path/

(Дивіться відповідь Грега для більш детальної інформації)

Я дізнався, що означає варіант 2. З сховища ви можете:

git checkout-index -a -f --prefix=/destination/path/

Нахил в кінці шляху є важливим, інакше це призведе до того, що файли знаходяться в / призначення з префіксом "шлях".

Оскільки в звичайній ситуації індекс містить вміст сховища, нічого особливого не потрібно робити, щоб "прочитати потрібне дерево в індекс". Це вже є.

-aПрапор потрібно , щоб перевірити всі файли в індексі (я не впевнений , що це значить пропустити цей прапор в цій ситуації, так як він не робить те , що я хочу). В -fпрапор сили перезапису існуючих файлів на виході, що ця команда зазвичай не роблять.

Схоже, це був такий тип "експорту git", який я шукав.

git archive також працює з віддаленим сховищем.

git archive --format=tar \
--remote=ssh://remote_server/remote_repository master | tar -xf -

Щоб експортувати певний шлях всередині репо, додайте стільки шляхів, скільки ви хочете, як останній аргумент git, наприклад:

git archive --format=tar \
--remote=ssh://remote_server/remote_repository master path1/ path2/ | tar -xv

Особлива відповідь у випадку, якщо сховище розміщене на GitHub.

Просто використовуйте svn export.

Наскільки я знаю, Github не дозволяє archive --remote. Хоча GitHub сумісний з svn і вони мають доступ до всіх git repos, svnтому ви можете просто використовувати так, svn exportяк зазвичай, з кількома коригуваннями вашої URL-адреси GitHub.

Наприклад, щоб експортувати ціле сховище, зверніть увагу, як trunkу URL-адресі замінюється master(або все, що встановлено для відділення HEAD проекту ):

svn export https://github.com/username/repo-name/trunk/

І ви можете експортувати один файл або навіть певний шлях або папку:

svn export https://github.com/username/repo-name/trunk/src/lib/folder

Приклад з бібліотекою jQuery JavaScript

HEADФілія або майстер філія буде доступний по trunk:

svn ls https://github.com/jquery/jquery/trunk

До неочевидній HEAD гілки буде доступний по /branches/:

svn ls https://github.com/jquery/jquery/branches/2.1-stable

Усі теги під /tags/одним і тим же способом:

svn ls https://github.com/jquery/jquery/tags/2.1.3

З посібника з Git :

Використання git-checkout-index для "експорту цілого дерева"

Здатність префікса в основному робить тривіальним використання git-checkout-index як функції "експортувати як дерево". Просто прочитайте потрібне дерево в індексі та зробіть:

$ git checkout-index --prefix=git-export-dir/ -a

Я написав просту обгортку навколо, git-checkout-indexяку ви можете використовувати так:

git export ~/the/destination/dir

Якщо каталог призначення вже існує, вам потрібно буде додати -fабо --force.

Установка проста; просто киньте скрипт десь у своєму PATHі переконайтесь, що він виконується.

Сховище github для git-export

Здається, це менше проблеми з Git, ніж SVN. Git містить лише папку .git у корінь сховища, тоді як SVN додає папку .svn у кожен підкаталог. Отже, "SVN-експорт" дозволяє уникнути рекурсивної магії командного рядка, тоді як при Git рекурсія не є необхідною.

Еквівалент

svn export . otherpath

всередині існуючого репо є

git archive branchname | (cd otherpath; tar x)

Еквівалент

svn export url otherpath

є

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

Якщо ви не виключаєте файли, .gitattributes export-ignoreспробуйтеgit checkout

mkdir /path/to/checkout/
git --git-dir=/path/to/repo/.git --work-tree=/path/to/checkout/ checkout -f -q

-f
Перевіряючи шляхи з індексу, не відмовляйтесь від занурених записів; натомість незаряджені записи ігноруються.

і

-q
Уникайте багатослівних

Крім того, ви можете отримати будь-яку гілку або тег або з певної редакції перегляду комісій, як у SVN, просто додавши SHA1 (SHA1 у Git - еквівалент номеру редакції у SVN)

mkdir /path/to/checkout/
git --git-dir=/path/to/repo/.git --work-tree=/path/to/checkout/ checkout 2ef2e1f2de5f3d4f5e87df7d8 -f -q -- ./

/path/to/checkout/Повинен бути порожнім, Git НЕ буде видаляти будь-який файл, але перезаписує файли з таким же ім'ям без будь - якого попередження

ОНОВЛЕННЯ: Щоб уникнути обезголовленої проблеми або залишити неушкодженим робочий сховище при використанні замовлення на експорт з тегами, гілками або SHA1, потрібно додати -- ./в кінці

Подвійний тире --повідомляє git, що все після тире - це контури або файли, а також у цьому випадку говорить про те, git checkoutщоб не змінюватиHEAD

Приклади:

Ця команда отримає лише каталог libs, а також readme.txtфайл із саме цього фіксатора

git --git-dir=/path/to/repo/.git --work-tree=/path/to/checkout/ checkout fef2e1f2de5f3d4f5e87df7d8 -f -q -- ./libs ./docs/readme.txt

Це створить (перезаписати) my_file_2_behind_HEAD.txtдва коміти за головоюHEAD^2

git --git-dir=/path/to/repo/.git --work-tree=/path/to/checkout/ checkout HEAD^2 -f -q -- ./my_file_2_behind_HEAD.txt

Щоб отримати експорт іншої галузі

git --git-dir=/path/to/repo/.git --work-tree=/path/to/checkout/ checkout myotherbranch -f -q -- ./

Зауважте, що ./це відносно кореня сховища

Я широко використовую git-підмодулі. Цей для мене працює:

rsync -a ./FROM/ ./TO --exclude='.*'

Я часто потрапляв на цю сторінку, шукаючи спосіб експортувати сховище git. У моїй відповіді на це питання розглядаються три властивості, які експортує svn за дизайном порівняно з git, оскільки svn дотримується підходу до централізованого сховища:

• Він мінімізує трафік до віддаленого місця сховища, не експортуючи всі версії
• Він не включає метаінформацію в каталог експорту

• Експорт певної гілки за допомогою svn здійснюється шляхом вказівки відповідного шляху

  git clone --depth 1 --branch master git://git.somewhere destination_path
  rm -rf destination_path/.git
  

При побудові певного випуску корисно клонувати стабільну гілку, наприклад, --branch stableабо --branch release/0.9.

Це скопіює весь вміст за вирахуванням файлів .dot. Я використовую це, щоб експортувати клоновані проекти git в git repo мого веб-додатка без речей .git.

cp -R ./path-to-git-repo / шлях / до / призначення /

Звичайний старий баш працює чудово :)

Так само просто, як клонувати, тоді видаліть .git папку:

git clone url_of_your_repo path_to_export && rm -rf path_to_export/.git

Для користувачів GitHub git archive --remoteметод не працюватиме безпосередньо, оскільки експортна URL-адреса є ефемерною . Ви повинні запитати GitHub для URL-адреси, а потім завантажити цю URL-адресу. curlробить це просто:

curl -L https://api.github.com/repos/VENDOR/PROJECT/tarball | tar xzf -

Це дасть вам експортований код у локальному каталозі. Приклад:

$ curl -L https://api.github.com/repos/jpic/bashworks/tarball | tar xzf -
$ ls jpic-bashworks-34f4441/
break  conf  docs  hack  LICENSE  mlog  module  mpd  mtests  os  README.rst  remote  todo  vcs  vps  wepcrack

Редагувати
Якщо ви хочете, щоб код розміщувався в певній, існуючій каталозі (а не у випадковій з github):

curl -L https://api.github.com/repos/VENDOR/PROJECT/tarball | \
tar xzC /path/you/want --strip 1

Так, це чиста та акуратна команда архівувати ваш код без будь-якого включення git до архіву, і це добре пройти навколо, не турбуючись про історію фіксації git.

git archive --format zip --output /full/path/to/zipfile.zip master 

Я просто хочу зазначити, що у випадку, що ви є

1. експорт підпапки сховища (саме так я використовував функцію експорту SVN)
2. в порядку, копіюючи все з цієї папки до пункту призначення
3. а оскільки у вас вже є копія всього сховища.

Тоді ви можете просто використовувати cp foo [destination]замість згаданого git-archive master foo | -x -C [destination].

Ви можете архівувати віддалений репо-файл на будь-якій комісії, як поштовий файл.

git archive --format=zip --output=archive.zip --remote=USERNAME@HOSTNAME:PROJECTNAME.git HASHOFGITCOMMIT

Баш-реалізація git-експорту.

Я сегментував процеси створення і видалення порожніх файлів. На їх власній функції з метою повторного використання їх у реалізації 'git-archive' (буде розміщено пізніше).

Я також додав файл .gitattributes до процесу, щоб видалити непотрібні файли з цільової папки експорту. Включено багатослівність у процес, зробивши функцію 'git-export' більш ефективною.

EMPTY_FILE = ". Порожній";

function create_empty () {
## Processing path (target-dir):
    TRG_PATH="${1}";
## Component(s):
    EXCLUDE_DIR=".git";
echo -en "\nAdding '${EMPTY_FILE}' files to empty folder(s): ...";
    find ${TRG_PATH} -not -path "*/${EXCLUDE_DIR}/*" -type d -empty -exec touch {}/${EMPTY_FILE} \;
#echo "done.";
## Purging SRC/TRG_DIRs variable(s):
    unset TRG_PATH EMPTY_FILE EXCLUDE_DIR;
    return 0;
  }

declare -a GIT_EXCLUDE;
function load_exclude () {
    SRC_PATH="${1}";
    ITEMS=0; while read LINE; do
#      echo -e "Line [${ITEMS}]: '${LINE%%\ *}'";
      GIT_EXCLUDE[((ITEMS++))]=${LINE%%\ *};
    done < ${SRC_PATH}/.gitattributes;
    GIT_EXCLUDE[${ITEMS}]="${EMPTY_FILE}";
## Purging variable(s):
    unset SRC_PATH ITEMS;
    return 0;
  }

function purge_empty () {
## Processing path (Source/Target-dir):
    SRC_PATH="${1}";
    TRG_PATH="${2}";
echo -e "\nPurging Git-Specific component(s): ... ";
    find ${SRC_PATH} -type f -name ${EMPTY_FILE} -exec /bin/rm '{}' \;
    for xRULE in ${GIT_EXCLUDE[@]}; do
echo -en "    '${TRG_PATH}/{${xRULE}}' files ... ";
      find ${TRG_PATH} -type f -name "${xRULE}" -exec /bin/rm -rf '{}' \;
echo "done.'";
    done;
echo -e "done.\n"
## Purging SRC/TRG_PATHs variable(s):
    unset SRC_PATH; unset TRG_PATH;
    return 0;
  }

function git-export () {
    TRG_DIR="${1}"; SRC_DIR="${2}";
    if [ -z "${SRC_DIR}" ]; then SRC_DIR="${PWD}"; fi
    load_exclude "${SRC_DIR}";
## Dynamically added '.empty' files to the Git-Structure:
    create_empty "${SRC_DIR}";
    GIT_COMMIT="Including '${EMPTY_FILE}' files into Git-Index container."; #echo -e "\n${GIT_COMMIT}";
    git add .; git commit --quiet --all --verbose --message "${GIT_COMMIT}";
    if [ "${?}" -eq 0 ]; then echo " done."; fi
    /bin/rm -rf ${TRG_DIR} && mkdir -p "${TRG_DIR}";
echo -en "\nChecking-Out Index component(s): ... ";
    git checkout-index --prefix=${TRG_DIR}/ -q -f -a
## Reset: --mixed = reset HEAD and index:
    if [ "${?}" -eq 0 ]; then
echo "done."; echo -en "Resetting HEAD and Index: ... ";
        git reset --soft HEAD^;
        if [ "${?}" -eq 0 ]; then
echo "done.";
## Purging Git-specific components and '.empty' files from Target-Dir:
            purge_empty "${SRC_DIR}" "${TRG_DIR}"
          else echo "failed.";
        fi
## Archiving exported-content:
echo -en "Archiving Checked-Out component(s): ... ";
        if [ -f "${TRG_DIR}.tgz" ]; then /bin/rm ${TRG_DIR}.tgz; fi
        cd ${TRG_DIR} && tar -czf ${TRG_DIR}.tgz ./; cd ${SRC_DIR}
echo "done.";
## Listing *.tgz file attributes:
## Warning: Un-TAR this file to a specific directory:
        ls -al ${TRG_DIR}.tgz
      else echo "failed.";
    fi
## Purgin all references to Un-Staged File(s):
   git reset HEAD;
## Purging SRC/TRG_DIRs variable(s):
    unset SRC_DIR; unset TRG_DIR;
    echo "";
    return 0;
  }

Вихід:

$ git-export /tmp/rel-1.0.0

Додавання файлів ".empty" до порожньої папки: ... виконано.

Компонент (и) індексу перевірки: ... виконано.

Скидання HEAD та Index: ... зроблено.

Очищення специфічних компонентів для Git: ...

'/tmp/rel-1.0.0/{.buildpath}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.project}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.gitignore}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.git}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.gitattributes}' файли ... зроблено. '

'/tmp/rel-1.0.0/{*.mno}' файли ... зроблено. '

'/tmp/rel-1.0.0/{*~}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.*~}' файли ... зроблено. '

'/tmp/rel-1.0.0/{*.swp}' файли ... зроблено. '

'/tmp/rel-1.0.0/{*.swo}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.DS_Store}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.settings}' файли ... зроблено. '

'/tmp/rel-1.0.0/{.empty}' файли ... зроблено. '

зроблено.

Архівація перевірених компонентів (-ів): ... виконано.

-rw-r - r-- 1 адмін-колесо 25445901 3 листопада 12:57 /tmp/rel-1.0.0.tgz

Зараз я включив функцію 'git archive' в єдиний процес, який використовує функцію 'create_empty' та інші функції.

function git-archive () {
    PREFIX="${1}"; ## sudo mkdir -p ${PREFIX}
    REPO_PATH="`echo "${2}"|awk -F: '{print $1}'`";
    RELEASE="`echo "${2}"|awk -F: '{print $2}'`";
    USER_PATH="${PWD}";
echo "$PREFIX $REPO_PATH $RELEASE $USER_PATH";
## Dynamically added '.empty' files to the Git-Structure:
    cd "${REPO_PATH}"; populate_empty .; echo -en "\n";
#    git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0
# e.g.: git-archive /var/www/htdocs /repos/domain.name/website:rel-1.0.0 --explode
    OUTPUT_FILE="${USER_PATH}/${RELEASE}.tar.gz";
    git archive --verbose --prefix=${PREFIX}/ -o ${OUTPUT_FILE} ${RELEASE}
    cd "${USER_PATH}";
    if [[ "${3}" =~ [--explode] ]]; then
      if [ -d "./${RELEASE}" ]; then /bin/rm -rf "./${RELEASE}"; fi
      mkdir -p ./${RELEASE}; tar -xzf "${OUTPUT_FILE}" -C ./${RELEASE}
    fi
## Purging SRC/TRG_DIRs variable(s):
    unset PREFIX REPO_PATH RELEASE USER_PATH OUTPUT_FILE;
    return 0;
  }

Якщо ви хочете щось, що працює з підмодулями, це, можливо, варто спробувати.

Примітка:

• MASTER_DIR = Оформлено замовлення з підмодулями
• DEST_DIR = де закінчиться цей експорт
• Якщо у вас rsync, я думаю, ви могли б зробити те саме, що ще менше болить у кулі.

Припущення:

• Вам потрібно запустити це з батьківського каталогу MASTER_DIR (тобто з MASTER_DIR cd ..)
• Передбачається, що DEST_DIR створений. Це досить легко змінити, щоб включити створення DEST_DIR, якщо ви цього хотіли

cd MASTER_DIR && tar -zcvf ../DEST_DIR/export.tar.gz --exclude = '. git *'. && cd ../DEST_DIR/ && tar xvfz export.tar.gz && rm export.tar.gz

Моїм перевагою було б мати мету dist у вашому Makefile (або іншій системі збирання), яка експортує дистрибутивний архів вашого коду (.tar.bz2, .zip, .jar або будь-який інший варіант). Якщо ви випадково використовуєте автоінструменти GNU або системи Perl's MakeMaker, я думаю, що це існує для вас автоматично. Якщо ні, то я настійно рекомендую додати його.

ETA (2012-09-06): Нічого, суворі голоси. Я все ще вважаю, що краще будувати свої дистрибутиви за допомогою інструментів збирання, а не інструментом контролю вихідного коду. Я вірю у створення артефактів із інструментами для збирання. На моїй теперішній роботі наш основний продукт побудований з мурашиною ціллю. Ми перебуваємо в розпалі комутації систем управління вихідним кодом, і наявність цієї цільової мурашки означає одну мізерну міграцію.

Це скопіює файли в діапазоні комітів (від C до G) у файл tar. Примітка. Це призведе лише до зафіксованих файлів. Не весь сховище. Злегка модифікований звідси

Приклад історії фіксації

A -> B -> C -> D -> E -> F -> G -> H -> I

git diff-tree -r --no-commit-id --name-only --diff-filter=ACMRT C~..G | xargs tar -rf myTarFile.tar

Сторінка посібника з git-diff-дерева

-r -> повторюється в під деревах

--no-commit-id -> git diff-дерево видає рядок з ідентифікатором читання, коли це застосовано. Цей прапор придушив вихід ID ID.

- тільки для імені -> Показати лише імена змінених файлів.

--diff-filter = ACMRT -> Вибрати лише ці файли. Дивіться тут повний список файлів

C..G -> Файли в цьому діапазоні комітів

C ~ -> Включіть файли з фіксування комітету C. Не лише файли, починаючи з "Комітету".

| xargs tar -rf myTarFile -> виводить в tar

Наскільки я розумію питання, мова йде більше про завантаження лише певного стану з сервера, без історії та без даних інших гілок, а не про вилучення стану з локального сховища (як це роблять багато прихильників тут).

Це можна зробити так:

git clone -b someBranch --depth 1 --single-branch git://somewhere.com/repo.git \
&& rm -rf repo/.git/

• --single-branch доступний з Git 1.7.10 (квітень 2012).
• --depthяк повідомляється, був несправним, але стосовно експорту згадані питання не повинні мати значення.

Мені це було потрібно для сценарію розгортання, і я не міг використовувати жоден із вищезгаданих підходів. Натомість я придумав інше рішення:

#!/bin/sh
[ $# -eq 2 ] || echo "USAGE $0 REPOSITORY DESTINATION" && exit 1
REPOSITORY=$1
DESTINATION=$2
TMPNAME="/tmp/$(basename $REPOSITORY).$$"
git clone $REPOSITORY $TMPNAME
rm -rf $TMPNAME/.git
mkdir -p $DESTINATION
cp -r $TMPNAME/* $DESTINATION
rm -rf $TMPNAME

Це простий спосіб, це функція для .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, така ж конфігурація потрібна (TAKE CARE виконання команди всередині .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' -

На сьогодні найпростіший спосіб, який я бачив (і працює на Windows) git bundle:

git bundle create /some/bundle/path.bundle --all

Дивіться цю відповідь для отримання більш детальної інформації: Як я можу скопіювати своє сховище git зі своєї машини Windows на машину Linux через USB-накопичувач?

У мене є ще одне рішення, яке добре працює, якщо у вас є локальна копія сховища на машині, куди ви хочете створити експорт. У цьому випадку перейдіть до цього каталогу сховища та введіть цю команду:

GIT_WORK_TREE=outputdirectory git checkout -f

Це особливо корисно, якщо ви керуєте веб-сайтом із сховищем git і хочете отримати чисту версію в /var/www/. У цьому випадку додайте цю команду до .git/hooks/post-receiveсценарію ( hooks/post-receiveу голому сховищі, що більше підходить у цій ситуації)

Я думаю , що повідомлення @Aredridel було найближчим, але є ще трохи до цього - тому я додам це тут; справа в тому svn, якщо ви перебуваєте в підпапці репо, і ви робите:

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

тоді svnви експортуєте всі файли, які перебувають під контролем редагування (вони могли бути також свіжододаними; або зміненим статусом) - і якщо у вас в цьому каталозі є інші "мотлохи" (і я не рахую .svnтут папки, але видимі речі, такі як .oфайли) , він не буде експортований; експортуються лише ті файли, зареєстровані репортажем SVN. Для мене одне приємне - це те, що цей експорт включає також файли з локальними змінами, які ще не були здійснені; і ще одна приємна річ - те, що часові позначки експортованих файлів такі ж, як і оригінали. Або, як svn help exportзазначається:

2. Експортує чисте дерево каталогів з робочої копії, визначеної PATH1, при перегляді REV, якщо воно дано, інакше при РОБОТІ, в PATH2. ... Якщо REV не вказаний, всі локальні зміни будуть збережені. Файли, які не перебувають під контролем версій, не будуть скопійовані.

Щоб зрозуміти, що gitчасові позначки не збережуть, порівняйте вихід цих команд (у підпапці gitрепо за вашим вибором):

/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 -)

... і я, в будь-якому випадку, помічаю, що git archiveвсі часові позначки архівованого файлу однакові! git help archiveкаже:

git-архів поводиться інакше, коли йому присвоєно ідентифікатор дерева порівняно з тим, коли йому надано ідентифікатор фіксації чи ідентифікатор тегу. У першому випадку поточний час використовується як час модифікації кожного файлу в архіві. В останньому випадку замість цього використовується час фіксації, записаний у згаданому об'єкті фіксації.

... але, мабуть, обидва випадки встановлюють "час модифікації кожного файлу"; тим самим не зберігаючи фактичні часові позначки цих файлів!

Отже, щоб також зберегти часові позначки, ось 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/subdir) - і призначення, в яке ви експортуєте, дещо незручно розміщене, але воно знаходиться в DESTзмінній середовищі. Зауважте, що з цим сценарієм; ви повинні створитиDESTперед створенням вищевказаного сценарію каталог вручну самостійно.

Після запуску сценарію ви зможете порівняти:

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

... і, сподіваємось, побачити ті самі часові позначки (для тих файлів, які були під контролем версій).

Сподіваюся, це допоможе комусь,
ура!

експорт git до zip-архіву, додаючи префікс (наприклад, ім'я каталогу):

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

Якщо вам також потрібні підмодулі, це повинно зробити трюк: https://github.com/meitar/git-archive-all.sh/wiki

У моєму файлі .bashrc у мене є така утиліта: вона створює архів поточної гілки у сховищі git.

function garchive()
{
  if [[ "x$1" == "x-h" || "x$1" == "x" ]]; then
    cat <<EOF
Usage: garchive <archive-name>
create zip archive of the current branch into <archive-name>
EOF
  else
    local oname=$1
    set -x
    local bname=$(git branch | grep -F "*" | sed -e 's#^*##')
    git archive --format zip --output ${oname} ${bname}
    set +x
  fi
}