Skopiuj repozytorium Git na Linuxie, nie myląc klucza ani folderu

Komenda git clone tworzy lokalną kopię roboczą i zwykle dodaje zdalne repozytorium pod nazwą origin. Pułapka pojawia się przed pierwszym poleceniem: URL SSH wykorzystuje Twój klucz, URL HTTPS często wymaga tokena, a folder docelowy nie powinien już zawierać użytecznych plików. Poświęć dwie minuty, aby sprawdzić te trzy punkty przed uruchomieniem skryptu pobranego w Internecie.

Tux trzyma repozytorium Git oraz klucz SSH przed dwoma ścieżkami klonowania Linux — Przed sklonowaniem repozytorium sprawdź URL, używany klucz i folder docelowy.

Wybierz HTTPS lub SSH przed klonowaniem

Użyj HTTPS, aby pobrać publiczny projekt lub gdy nie chcesz konfigurować klucza na tej maszynie. Aby następnie przesyłać zmiany do GitHub, GitLab lub swojej platformy, hasło do konta zazwyczaj już nie wystarcza: usługa wymaga tokenu dostępu osobistego.

Użyj SSH, jeśli Twój klucz publiczny jest już powiązany z Twoim kontem na platformie. Ta metoda unika ponownego wpisywania tokena, ale może się nie powieść, jeśli zostanie zaproponowany zły klucz lub jeśli agent SSH go nie załadował. Zacznij od sprawdzenia używanej tożsamości:

ssh -T [email protected]
ssh-add -l

Dopasuj pierwszy host do swojej platformy. Odpowiedź uwierzytelniająca bez zdalnego powłoki jest normalna u wielu dostawców Git. Jeśli zarządzasz wieloma kluczami, sprawdź swój plik ~/.ssh/config za pomocą ssh -G [email protected], zanim oskarżysz Git. Nasz przewodnik dotyczący konfiguracji SSH dla wielu serwerów wyjaśnia, jak ustalić klucz i konto według aliasu.

Utwórz kopię w pustym i rozpoznawalnym folderze

Znajdź się w katalogu przeznaczonym na swoje projekty. Bez drugiego argumentu Git tworzy folder na podstawie nazwy repozytorium. Używając wyraźnej nazwy, unikniesz pomylenia kopii testowej z tą, która zawiera Twoje zmiany.

mkdir -p ~/projekty
cd ~/projekty
pwd
ls -la

git clone https://github.com/octocat/Hello-World.git hello-test
cd hello-test

Nie uruchamiaj klonowania w folderze, którego zawartości nie znasz. Git zwykle odrzuca niepusty katalog, ale lepiej jest najpierw sprawdzić pwd oraz ls -la przed wydaniem polecenia. Na kopię przeznaczoną tylko do przeglądania kodu, HTTPS pozostaje najprostszym wyborem.

Za pomocą SSH, ta sama operacja wygląda następująco:

git clone [email protected]:moje-konto/moj-projekt.git moj-projekt
cd moj-projekt

Zamień host, konto i repozytorium na wartości podane przez Twoją platformę. Nigdy nie kopiuj URL otrzymanego w podejrzanym komunikacie. Najpierw otwórz oficjalną stronę projektu i porównaj właściciela, nazwę repozytorium oraz URL klonowania.

Sprawdź zdalne repozytorium i pliki przed wykonaniem czegokolwiek

Po klonowaniu sprawdź źródło, aktywną gałąź oraz stan katalogu. Te polecenia nie zmieniają projektu:

git remote -v
git branch --show-current
git status
git log -1 --oneline
find . -maxdepth 2 -type f -name 'README*' -o -name 'INSTALL*'

git remote -v wyświetla URL-e używane do pobierania i wysyłania zmian. Sprawdź je przed pierwszym git push, zwłaszcza jeśli projekt zawiera konfigurację wdrażania. Następnie przeczytaj README, pliki INSTALL, zależności oraz skrypty startowe. Repozytorium Git może zawierać ważny, stary lub wyraźnie ryzykowny skrypt, nie nabieraj się na zaufanie tylko dlatego, że klonowanie się powiodło.

Aby później pobrać aktualizację, pozostań w sklonowanym folderze i rozpocznij od sprawdzenia swojej pracy:

git status
git fetch origin
git log --oneline HEAD..origin/$(git branch --show-current)
git pull --ff-only

git pull --ff-only odrzuca automatyczne scalanie, jeśli Twoje lokalne zatwierdzenia i zdalne repozytorium są różne. To lepsze niż aktualizacja, która łączy zmiany, gdy jeszcze nie przyjrzałeś się gałęzi ani zdalnemu repozytorium.

Oficjalna dokumentacja git clone szczegółowo opisuje opcje takie jak --depth, --branch i --recurse-submodules. Zachowaj je na zidentyfikowaną potrzebę. Przy pierwszym klonowaniu, zweryfikowany URL, czysty katalog i przeczytanie README już ograniczają większość błędów.