Як перетворити оголене сховище git у звичайне (на місці)?

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

Я припускаю, що міг би його клонувати:

git clone -l <path_to_bare_repo> <new_normal_repo>

Однак мій репозиторій розміром близько 20 Гб, і у мене немає місця для його копіювання. Чи є спосіб перетворити оголене сховище на місце, щоб у підсумку вийшла робоча копія?

Примітка : Я протестував це на дуже простому сховищі з 1 комітом. Двічі перевірити це, читати сторінки людини , і завжди буде радий , що ви створили резервну копію , перш ніж слідувати порадам ви знайшли на StackOverflow. (Ви робите резервну копію, так?)

Щоб перетворити --bareсховище на непростий:

1. Створіть .gitпапку на верхньому рівні вашого сховища.
2. Перемістіть речі управління сховищем ( HEAD branches config description hooks info objects refsтощо) у .gitщойно створені.
3. Запустіть, git config --local --bool core.bare falseщоб перетворити локальний репозиторій git у непростий.
4. (за коментарем Tamás Pap ) Після кроку # 3 ви побачите, що ви перебуваєте у гілці master(або залежно від того, яка ваша основна гілка), і всі ваші файли видаляються, а видалення відбувається поетапно. Це нормально. Просто оформліть замовлення вручну masterабо зробіть git reset --hard, і все готово.
5. (для вирішення проблеми, про яку повідомляє Royi ) Редагуйте .git/configдодавання файлу в рядок fetch = +refs/heads/*:refs/remotes/origin/*після url = <...>в [remote "origin"]розділі. Інакше git fetchне побачать origin/masterі інших гілок походження.

Ці кроки йдуть у протилежному напрямку від цього питання , "git-convert normal to gore repository" - зокрема, зверніть увагу на цю відповідь , в якій зазначено, що наведені вище кроки (у, я припускаю, будь-якому напрямку) відрізняються від виконання a git-clone. Не впевнений, що це стосується вас, однак, але ви згадали git cloneу питанні.

У мене був дещо інший сценарій:

• не репо ( перейти через tarball з github )
• необхідність відновлення повного репо з цього вмісту.

Рішення:

• клонувати оголене репо в цьому вмісті, в .gitпапці:
  git clone --bare https://github.com/user/project .git
• Позначте це як не оголене репо:
  git config --local --bool core.bare false
• скинути індекс (інакше він вважає, що все було видалено, оскільки .git оголене репо не включає файл ' index'.)
  git reset HEAD -- .
  Це відновлює файл .git/index.

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

cd /path/to/current/worktree

# That creates a .git directly at the right place
git clone --bare /url/of/repo .git

# restore the link between the local repo and its upstream remote repo
git config --local --bool core.bare false
git config --local remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git fetch origin
git branch -u origin/master master

# reset the index (not the working tree)
git reset HEAD -- .

Але я Рекон загальноприйняте рішення (з корисним git resetкроком додає по ADTC ) простіше.

Щоб спростити та поєднати інформацію у відповідях:

Є три відмінності, за якими голий репо відрізняється від звичайної папки .git:

• У файлі конфігурації core.bare встановлено значення true
• індексного файлу та робочого дерева не існує
• значення за замовчуванням для віддаленого "джерела" не створюється

Отже, ви можете просто перенести своє оголене репо в папку .git нової папки,

mkdir clone
mv bare.git clone/.git

Змінити core.bare:

cd clone
git config --local --bool core.bare false

Додайте refspec за замовчуванням, щоб зробити git fetchі git pushвибрати ті самі значення за замовчуванням:

git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'

І згенеруйте файл індексу та робоче дерево:

git checkout master

Я рекомендую, git checkoutа не git resetгенерувати файли, на випадок, якщо вони випадково введені не в тому місці.

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

git clone foo.git foo

Якщо у вас недостатньо місця на дисковому просторі, розширення робочого дерева шляхом перетворення в звичайне сховище буде проблемою, але ви можете переглядати вміст простого репо, не перетворюючи його. Використовуйте git cat-file -p <commit-sha>для будь-якого коміту, щоб побачити дерево, на яке воно посилається. Використовуйте git cat-file -p <blob-sha>для перегляду вмісту файлу, на який посилається краплина. Використовуйте git show <sha>:pathде sha - це або коміт, або дерево, щоб побачити вміст BLOB-файлу на шляху.

cd в голі репо і робити

1. Або:

git config core.bare false
git reset --hard

2. Або

git clone X.git X

(дасть вам регулярне репозиторій git, який називається X)

Якщо ви не проти працювати над різним робочим деревом, тоді

git worktree add ../repo2
cd ..
git status # now works fine

Зверніть увагу, це не клон.

Push-to-Deploy

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

Ось хороший приклад налаштування Push-to-Deploy

Для зручності посилання це приклад вмісту сценарію з наведеного вище посилання. Він буде розгортати лише натискання з гілки "master" у каталог із назвою "deploy", який знаходиться на тому ж рівні, що і батьківський каталог сховища:

#!/usr/bin/env ruby
# post-receive

# 1. Read STDIN (Format: "from_commit to_commit branch_name")
from, to, branch = ARGF.read.split " "

# 2. Only deploy if master branch was pushed
if (branch =~ /master$/) == nil
    puts "Received branch #{branch}, not deploying."
    exit
end

# 3. Copy files to deploy directory
deploy_to_dir = File.expand_path('../deploy')
`GIT_WORK_TREE="#{deploy_to_dir}" git checkout -f master`
puts "DEPLOY: master(#{to}) copied to '#{deploy_to_dir}'"