Kiedy muszę wykonać „git pull”, przed lub po „git add, git commit”?

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ń?

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ń).

pull = pobierz + scal.

Musisz zatwierdzić to, co zrobiłeś przed połączeniem.

Więc ciągnij po zatwierdzeniu.

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.

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.