Wypchnąć — co to jest, jak działa git push i kiedy używać

Czym jest push w Git

Git push to polecenie, które przekazuje commity z lokalnego repozytorium do zdalnego. W przeciwieństwie do commitu, który zapisuje zmiany tylko na lokalnym komputerze programisty, push publikuje te zmiany dla całego zespołu. Push to obowiązkowy krok przed utworzeniem Pull Request i wdrożeniem.

Architektura Git zakłada, że każdy programista pracuje we własnym lokalnym repozytorium. Commity są tworzone lokalnie i kumulują się, dopóki programista nie zdecyduje się je wypchnąć. Daje to swobodę: można robić wiele lokalnych commitów, eksperymentować i przepisywać historię bez wpływu na kolegów.

# Push do origin remote, gałąź main
git push origin main

# Push bieżącej gałęzi do remote z upstream
git push -u origin feature/new-dashboard

# Push wszystkich gałęzi z pasującymi nazwami
git push --all origin

# Force push z lease (bezpieczny force push)
git push --force-with-lease

Po pushu zdalne repozytorium aktualizuje refs (referencje do gałęzi) tak, aby wskazywały na nowe commity. Inni programiści mogą pobrać te zmiany za pomocą git pull lub git fetch. To właśnie ta wymiana commitów stanowi podstawę pracy zespołowej.

Jak działa git push

Polecenie git push porównuje lokalne i zdalne gałęzie i przekazuje tylko brakujące commity. Git nie wysyła wszystkich plików od nowa — przekazuje tylko deltę, co sprawia, że push jest szybki nawet w przypadku dużych repozytoriów. Protocol Git wykorzystuje smart transfer, który minimalizuje ilość przesyłanych danych.

Jeśli zdalna gałąź zawiera commity, których nie ma lokalnie, push zostanie odrzucony. To mechanizm ochronny zapobiegający utracie zmian. W takiej sytuacji programista powinien najpierw wykonać git pull, scalić zmiany, a dopiero potem ponownie wypchnąć. Alternatywą jest force push, który nadpisuje zdalną gałąź, ale należy go używać ostrożnie.

Zrozumienie zdalnych repozytoriów to klucz do prawidłowego pusha. Zwykle używa się origin — domyślnej nazwy zdalnego repozytorium. Polecenie git remote -v pokazuje listę zdalnych repozytoriów i ich adresy URL. Można dodać kilka remote (np. origin dla głównego repozytorium i upstream dla forka).

Kiedy pushować zmiany

Podstawowa zasada: pushować należy po każdym logicznie zakończonym etapie pracy. Jeśli programista ukończył zadanie lub jego część — czas wypchnąć. Jednak pushowanie niedokończonej pracy, która psuje build, nie jest zalecane. Niezepsuty build to minimalne wymaganie dla pusha do dowolnej gałęzi.

W programowaniu zespołowym przyjęty jest następujący rytm: rano — git pull, aby pobrać zmiany kolegów, w ciągu dnia — kilka commitów i jeden lub dwa pushe, wieczorem — finalny push wszystkich ukończonych zadań. Im częściej programista pushuje, tym mniejsze ryzyko konfliktów przy scalaniu gałęzi i tym bardziej przejrzysty jest postęp pracy.

• Po ukończeniu zadania — zcommitować i wypchnąć finalne rozwiązanie do gałęzi feature
• Przed wyjściem — wypchnąć niedokończoną pracę do gałęzi feature (nie do main!)
• Przed utworzeniem PR — upewnić się, że wszystkie commity są wypchnięte i dostępne do review
• Po rebase — wypchnąć z --force-with-lease do swojej gałęzi feature

Zasady bezpiecznego pusha

Bezpieczny push to zestaw zasad zapobiegających utracie danych i konfliktom w zespole. Pierwsza i najważniejsza zasada: nigdy nie pushować bezpośrednio do gałęzi main lub master, jeśli w projekcie nie skonfigurowano bezpośredniego wdrożenia. W nowoczesnych zespołach ochrona gałęzi main jest konfigurowana na poziomie GitHub branch protection.

Druga zasada: przed pushem zsynchronizować się ze zdalną gałęzią. Wykonać git pull --rebase, aby uniknąć merge commitu przy scalaniu. Upraszcza to historię i czyni ją liniową. Jeśli push został odrzucony — nie używać gołego force push, a najpierw sprawdzić, jakie commity pojawiły się na zdalnej gałęzi.

Trzecia zasada: skonfigurować pre-push hooki, które automatycznie uruchamiają testy i linter przed wysłaniem. Jeśli testy padają — push jest blokowany. Takie hooki konfiguruje się przez Husky lub Git hooks (plik pre-push w .git/hooks).

Czwarta zasada: nie pushować dużych plików binarnych. Git nie jest przeznaczony do przechowywania binarnych artefaktów — rozdymają one repozytorium i spowalniają operacje. Do dużych plików używa się Git LFS (Large File Storage). Jeśli plik binarny został już wypchnięty i trafił do historii, należy go usunąć przez git filter-branch.

Co zrobić, gdy push nie przeszedł

Najczęstszą przyczyną nieudanego pusha jest zdalna gałąź zawierająca commity, których nie ma lokalnie. Dzieje się tak, gdy inny programista wypchnął swoje zmiany do tej samej gałęzi. Rozwiązanie: wykonać git pull, rozwiązać ewentualne konflikty i powtórzyć push.

# Push odrzucony — najpierw fetch i rebase
git fetch origin
git rebase origin/main
# Rozwiąż konflikty, następnie:
git push --force-with-lease

# Lub po prostu scal zmiany zdalne
git pull origin main
git push

Drugą przyczyną jest brak praw zapisu do gałęzi. Jeśli gałąź main jest chroniona regułą branch protection, bezpośrednie pushe są zabronione. Rozwiązanie: pushować do gałęzi feature i tworzyć Pull Request. Ustawienia ochrony są zwykle administrowane przez GitHub settings lub GitLab protected branches.

Trzecią przyczyną są problemy z uwierzytelnianiem. Nieaktualne dane logowania, przejście na SSH lub zmiana personal access token. Rozwiązanie: sprawdzić remote URL (git remote -v) i zaktualizować dane logowania. Od 2021 roku GitHub anulował uwierzytelnianie hasłem dla HTTPS — używa się tokena osobistego lub klucza SSH.