Jaka jest właściwa droga?
git add foo.js
git commit foo.js -m "commit"
git pull
git push
Lub
git pull
git add foo.js
git commit foo.js -m "commit"
git push
Lub
git add foo.js
git pull
git commit foo.js -m "commit"
git push
UPD:
Zapomniałem wspomnieć, że w tym przypadku używam git adddo przygotowania śledzonego i zmodyfikowanego pliku. Nie dołączać zupełnie nowego pliku do repozytorium. Czy to zmienia kolejność poleceń?
Odpowiedzi:
Myślę, że najlepszym sposobem na to jest:
Zachowaj swoje lokalne zmiany:
git stash
Zaktualizuj gałąź do najnowszego kodu
git pull
Scal lokalne zmiany w najnowszym kodzie:
git stash apply
Dodaj, zatwierdź i prześlij swoje zmiany
git add
git commit
git push
Z mojego doświadczenia wynika, że jest to droga do najmniejszego oporu w Git (zresztą w wierszu poleceń).
git stash?
pull = pobierz + scal.
Musisz zatwierdzić to, co zrobiłeś przed połączeniem.
Więc ciągnij po zatwierdzeniu.
rebasezamiast tego merge. Możesz to zrobić za pomocą jednego git commit && git rebaselub drugiego git pull --rebase.
git pullumieszczenie moich zmian w fazie, ponieważ uważam to za najbardziej naturalne. Chociaż zdaję sobie sprawę, że działa wiele różnych przepływów pracy (skrytka też jest fajna), więc prawdopodobnie jest to kwestia gustu.
Sugerowałbym jak najczęstsze pobieranie ze zdalnej gałęzi, aby zminimalizować duże fuzje i możliwe konflikty.
Powiedziawszy to, wybrałbym pierwszą opcję:
git add foo.js
git commit foo.js -m "commit"
git pull
git push
Zatwierdź zmiany przed ściągnięciem, aby twoje zatwierdzenia zostały połączone ze zdalnymi zmianami podczas ściągania. Może to prowadzić do konfliktów, z którymi możesz zacząć sobie radzić, wiedząc, że Twój kod jest już zatwierdzony, gdyby coś poszło nie tak i musisz przerwać scalanie z dowolnego powodu.
Jestem pewien, że ktoś się ze mną nie zgodzi, nie sądzę, że jest jakiś właściwy sposób na wykonanie tego scalania, tylko to, co działa najlepiej dla ludzi.
git adddokładnie służy mój przykład.
Myślę, że git pull --rebasejest to najczystszy sposób na ustawienie najnowszych lokalnych zatwierdzeń na zdalnych zatwierdzeniach, których w pewnym momencie nie masz.
W ten sposób nie musisz ciągnąć za każdym razem, gdy chcesz zacząć wprowadzać zmiany.
Chcesz, aby zmiana została uwzględniona na szczycie bieżącego stanu zdalnej gałęzi. Więc prawdopodobnie chcesz wyciągnąć rękę, zanim się zobowiążesz. Następnie ponownie wprowadź zmiany.
„Brudne” pliki lokalne nie stanowią problemu, o ile nie występują konflikty ze zdalną gałęzią. Jeśli jednak wystąpią konflikty, scalanie zakończy się niepowodzeniem, więc nie ma żadnego ryzyka ani niebezpieczeństwa związanego z ściąganiem danych przed wprowadzeniem lokalnych zmian.