Czy można kopiować (nie klonować) repozytorium git przy użyciu podstawowych poleceń Uniksa?

22

Jestem całkiem nowy, używając git i zastanawiałem się, czy to jest ok, aby skopiować repozytorium git z typowych poleceń systemu UNIX (jak cplub tar/ untag), a nie przez git clone.

Mam sytuację, w której mam środowisko produkcyjne (python virtual), w którym jakiś kod został wypisany w git. Zastanawiam się, czy to zły pomysł z punktu widzenia git, aby skopiować całe środowisko za pomocą tarczegoś lub czegoś. Takie podejście byłoby wygodne przy tworzeniu szybkiej kopii bazy kodu / środowiska.

Obawiam się, że być może klon git kojarzy jakiś unikatowy identyfikator z kopią roboczą, która może powodować konflikty, jeśli istnieją dwie kopie robocze, w których jedna została skopiowana z systemu plików od drugiej.

git tar

— Joe J
źródło

Wow, byłem w tej sytuacji, ponieważ miałem niektóre pliki pod kontrolą źródła, a niektóre nie, i miałem uprawnienia do plików, które musiałem zachować. Cieszę się, że zadałeś to pytanie.

— Joe C

21

Jest całkowicie w porządku.

git przechowuje całą swoją historię, zatwierdzenia itp. na miejscu - jest to podstawowa właściwość DCVS.

Technicznie rzecz biorąc, gitmoże działać dobrze z kopiowanymi repozytoriami biegającymi wszędzie, ponieważ sedno DCVS polega na tym, że nie musi wiedzieć, co się dzieje poza danym repozytorium , a tak naprawdę nie, chyba że to powiesz .

Ta sama zasada obowiązuje tutaj.

— nowy123456
źródło

1

Rozumiem, że sklonowane repozytorium będzie zawierało link z powrotem do rodzica. Użycie polecenia kopiowania systemu operacyjnego nie spowoduje utworzenia tego łącza.

— Tony

@ Tony Prawda, ale możesz usunąć ten link, używając git remote remove origin, co powstrzymuje Git przed użyciem repozytorium nadrzędnego jako nadrzędnego.

— new123456

2

Powinieneś być w stanie skopiować cały katalog roboczy do dowolnego miejsca w systemie i kontynuować jego normalne działanie podczas korzystania z Git, Hg lub SVN. Nie mogę komentować innych SCM.

— Darth Android
źródło

0

Jest to bardziej nietypowy przypadek użycia, ale ...

Widziałem, jak reponarzędzie tworzy dowiązania symboliczne w .gitkatalogu. W takim przypadku, gdy robisz kopię, powinieneś upewnić się, że dereferencje linków symbolicznych. Na przykład:

cp -r -L <source-repo-dir> <destination-repo-dir>

— Craig McQueen
źródło

0

Jest w porządku, ale jeśli masz zamiar udostępnić swoje repo komuś innemu, weź pod uwagę następujące kwestie :

W twoim configpliku mogą znajdować się piloty, których inna osoba może nie obchodzić.
Twój logsfolder będzie zawierał odniesienia, których możesz nie chcieć udostępniać. Git świetnie radzi sobie z robieniem nieprzyjemnych rzeczy na komputerze, dopóki nie poczujesz się komfortowo z końcowym rezultatem, a następnie przesuń go do pilota, aby (od czasu do czasu) udostępnić go. Niektóre z tej paskudnej historii mogą znajdować się w twoim dzienniku logowania, więc lepiej nie udostępniać jej IMHO.
Twój info/excludeplik może ignorować niektóre pliki, które tylko ty chcesz zignorować.
Możesz także mieć haczyki, gałęzie i wiele innych rzeczy, które są osobiste i wolisz nie udostępniać ...

— whoan
źródło