Pull to refresh

Comments 8

Не совсем понятна разница между копией репозитория и независимым репозиторием создаваемым командой git clone с дополнительным аргументом. Если лрмать мозг, можно подумать, что она создает еще один удаленный репозиторий в источнике.
Разница в том, что при использовании git worktree репозиторий по-прежнему остаётся один, отсюда следующие преимущества:
  • git clone создаст полную копию репозитория, то есть все-все объекты будут выгружены в папку .git, в то время как git worktree выгрузит именно рабочую копию и один-единственный крохотный файл .git с указателем на основной репозиторий. Для больших репозиториев это имеет значение (к примеру, репозиторий одной известной IDE занимает порядка 4 Гб, а рабочая копия ветки, соответствующей одной из версий — всего 800 Мб).
  • Двумя одинаковыми, но независимыми репозиториями сложнее управлять. Если Вы сделали изменение в одной копии, её надо синхронизировать со второй, чтобы изменения стали в ней видны (и наоборот). Это лишние действия :) Да, иметь две одинаковые рабочие копии (то есть одной и той же ветки) с помощью git worktree запрещено — как раз чтобы не допустить рассинхронизации изменений в этой ветке в рамках одного репозитория. Тем не менее, если в одной рабочей копии сделать какие-то изменения, они тут же становятся видимыми в основном репозитории и во всех остальных его рабочих копиях, потому что хранятся все объекты git только в основной папке репозитория (папка .git есть только там).
  • Если делать git clone с удалённого репозитория, нужен доступ к нему (а если репозиторий большой, то нужно ещё время и/или хороший канал). Разумеется, можно клонировать с локального репозитория, но тогда у свежесозданного репозитория в качестве remote-ссылки будет этот локальный репозиторий. То есть, снова нужны дополнительные действия по настройке его до такого же состояния. Рабочая же копия, получаемая с помощью git worktree — это только рабочая копия: репозиторий где был, там и остался, так что настраивать ничего не нужно.


Это не значит, что иметь два локальных репозитория с одного и того же remote — плохо. Но есть ряд случаев, когда путь с git worktree проще и удобнее.
Ах вот оно что… Спасибо за комментарий.
В дополнение к вышесказанному, git worktree трекает все папки, которые им созданы, поэтому их можно увидеть в git worktree list
> Однако в Git 2.6 нельзя было применить отрицание к файлу, находящемуся в уже игнорируемой папке.

Вот так работало…

/uploads/*
!uploads/.gitkeep
В Вашем примере первая строка игнорирует не саму папку uploads, а все файлы/папки в ней.
В 2.7 поддержали отмену игнорирования файла даже если какая-то из родительских папок игнорирована. То есть, исключить файл uploads/some_dir/file из приведённого ограничения Git 2.7 сможет, а 2.6 — нет.
Однако в Git 2.6 нельзя было применить отрицание к файлу, находящемуся в уже игнорируемой папке.

Да, как-то наткнулся на такую проблему, в итоге решил ее таким образом:
В родительской папке выставил так, папка folder_name всё равно игнорировалась:
*
!folder_name

Но внутри этой папки я создал новый файл .gitignore(folder_name/.gitignore) с таким содержимым и вроде, как сработало:
!*
Sign up to leave a comment.

Articles