Przypadek użycia :
Mam MyApp, która zostanie wdrożona na ClientX. Piszę skrypt powłoki, aby pobrać tę gałąź z mojego repozytorium bitbucket
mój skrypt powłoki (działa dobrze)
git clone -b $BRANCH_NAME https://$USER_NAME@bitbucket.org/MyApp/ecodrone.git
Pytanie :
Teraz z aktualizacjami, czy lepiej mieć
Odpowiedzi:
Jeśli masz trwałe miejsce do przechowywania, ponowne klonowanie byłoby bardzo nieefektywne (szczególnie klonowanie całej historii, ponieważ nie używasz --depth=).
W międzyczasie pull / fetch otrzyma tylko te obiekty, które faktycznie się zmieniły. Posługiwać się:
git fetch && git reset --hard "origin/$BRANCH_NAME" aby zawsze pobrać najnowsze zatwierdzenie,
lub git pull --ff-onlyjeśli wolisz, aby mocno się nie udawało, gdyby ktoś próbował przepisać historię.
Nie używaj zwykłego, git pullponieważ może to spowodować duży bałagan w tym drugim przypadku.
Krótka odpowiedź:
Aby zaktualizować, lepiej jest git pull lub git fetch, rebase i scal, jeśli pracujesz z innymi osobami z tej samej gałęzi (i / lub plików), ponieważ git pull próbuje scalić tylko wtedy, gdy nie ma konfliktów scalania.
Lepszym rozwiązaniem byłoby również utworzenie nowej gałęzi na podstawie sklonowanej gałęzi, aby łatwiej rozwiązywać konflikty scalania lokalnie na komputerze. Jest to ogólnie nazywane gałęzią funkcji w przepływie pracy. W ten sposób po zakończeniu i zatwierdzeniu pracy możesz uruchomić git pull na gałęzi master (z powodu braku nazwy nazywam gałąź, którą sklonowałeś master), co powinno się zdarzyć bez żadnych problemów, a następnie możesz dokonać zmiany bazy funkcji master i scal (użyj flagi --no-ff, jeśli chcesz zachować dziennik gałęzi funkcji / historię zatwierdzeń, w innym przypadku zostanie zmiażdżony w jedno zatwierdzenie), aby opanować. Następnie pchnij swoją pracę (gałąź główna) w górę.
powinien iść coś takiego:
git checkout -b feature
...work, stage changes & commit...
git checkout master
git pull upstream/master #or git pull origin master based on git remote urls
git checkout feature
git rebase -i upstream/master
git checkout master
git merge --no-ff master feature
git push upstream #or git push origin
Również nie rozumiem, dlaczego chcesz go klonować ponownie, klonowanie powinno być jednorazową sprawą dla repozytoriów git