GIT - Jak nadpisać zmiany w wersji prod z wersji dev ?

pytanie zadane 25 listopada 2020 w Systemy operacyjne, programy przez Piotr Zakrzewski Obywatel (1,260 p.)

Witam

Chciałbym poprzez GIT'a aktualizować produkcyjna wersje mojej aplikacji.

Załóżmy że mam dwa foldery appprod i appdev, appdev zaktualizowałem o poprawki i wgrałem na GitHuba, kiedy używam komendy clone wywala mi błąd że dany folder już istnieje, kiedy użyłem fetch coś ściągnął ale nic się nie wydarzyło ani w plikach nic kompletnie się nie zmieniło a po wykonaniu log nie widze commita który wprowadziłem w wersji

komentarz 25 listopada 2020 przez tkz Nałogowiec (42,000 p.)

Różne branche?

komentarz 25 listopada 2020 przez Piotr Zakrzewski Obywatel (1,260 p.)

A jak to sprawdzić ? Troche zielony jestem i nie mam pojęcia ale wydaje mi się że chyba tak, jak wpisuje git log to w dev mam '(HEAD -> main, origin/main' a w prod 'HEAD -> main'

komentarz 25 listopada 2020 przez tkz Nałogowiec (42,000 p.)

git branch
Ale trudno mi cokolwiek powiedzieć bez czegoś namacalnego.
git fetch pobiera dane, ale ich nie łączy. git pull pobiera i je łączy. Uogólniając.

komentarz 25 listopada 2020 przez Piotr Zakrzewski Obywatel (1,260 p.)

w obu przypadkach wynik git branch to * main.

λ git clone https://github.com/blablabla9/test.git appprod
fatal: destination path 'appprod' already exists and is not an empty directory.

komentarz 25 listopada 2020 przez tangarr Mędrzec (154,860 p.)

Jeżeli repozytorium jest publiczne to daj link.
Jeżeli nie to opisz jak wygląda to repozytorium (wystarczy układ katalogów).

komentarz 25 listopada 2020 przez Piotr Zakrzewski Obywatel (1,260 p.)

Są to 3 foldery z Symfony w wersji 5,

src z cala zawartoscią i tutaj głownie zaszly zmiany,

templates z cala zawartoscia zero zmian,

public tylko z folderem assets rowniez bez zmian.

1	komentarz 25 listopada 2020 przez tkz Nałogowiec (42,000 p.) @Piotr Zakrzewski, Kopiujesz w to samo miejsce, gdzie istnieje już to repo. Spróbuj w inne, ale to nie rozwiązanie... Spróbuj również git pull origin main

komentarz 25 listopada 2020 przez Piotr Zakrzewski Obywatel (1,260 p.)

SUPER ! Dzieki zadziałało ! :)

Updating 77344d8..33d5e84
Fast-forward
src/Controller/TechnologiesController.php | 18 ++++++----------
src/Service/ImagesUploadService.php | 36 +++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 12 deletions(-)

komentarz 25 listopada 2020 przez tkz Nałogowiec (42,000 p.)

Przeczytaj jak działa git fetch...

2 odpowiedzi

odpowiedź 25 listopada 2020 przez tangarr Mędrzec (154,860 p.)
wybrane 25 listopada 2020 przez Piotr Zakrzewski

Najlepsza

Problem jest taki, że nie potrafisz korzystać z gita.

Musisz się nauczyć używać branchy.

# tworzenie nowego brancha z aktualnie wybranego
git branch nazwa_nowego_brancha
# przejście z jednego brancha na drugi
git checkout nazwa_nowego_brancha

Dzięki branchom możesz spokojnie modyfikować kod aktualnego brancha niezależnie od innych (np. od brancha produkcyjnego).

Jeżeli masz nowy poprawiony kod i chcesz go dodać do swojego repozytorium to wykonaj następujące instrukcje

# wybierz jakiś pusty katalog w systemie nazwijmy go ROBOCZY
cd ROBOCZY
# sklonuj swoje repozytorium
git clone REPOZYTORIUM_GITHUB
cd REPOZYTORIUM

# tworzymy nowy branch
git branch NAZWA_BRANCHA
git checkout NAZWA_BRANCHA

# skopiuj nowe pliki do repozytorium
cp -r NOWE_REPOZYTORIUM/* .

# sprawdź które pliki się zmieniły
git status

# dodaj zmodyfikowane pliki do commita
git add PLIK_LUB_KATALOG

# skommituj zmiany
git commit

#wypchnij branch na serwer
git push
# za pierwszym razem będziesz musiał wykonać komendę
# git push -u origin NAZWA_BRANCHA

Później na drugiej maszynie

cd REPOZYTORIUM
git fetch # ta komenda nie zmienia plików
git checkout NOWY_BRANCH
git pull

komentarz 25 listopada 2020 przez Piotr Zakrzewski Obywatel (1,260 p.)

Tak przyznaje - nie potrafię korzystać z gita dopiero go odkrywam od tygodnia przy tym projekcie. Czyli rozumiem że prawidłowo należy rozbijać gałąź na ta 'dev' a potem ja scalać z prod ?

komentarz 25 listopada 2020 przez tangarr Mędrzec (154,860 p.)

Scalasz dopiero gdy się upewnisz, że wszystko działa prawidłowo

git checkout BRANCH_PRODUKCJA
git merge BRANCH_DEVEL

Czasami może się zdarzyć konflikt, który będziesz musiał rozwiązać ręcznie.

W każdym bądź razie, commituj często, dzięki temu w razie problemu będziesz mógł się cofnąć do innego commita i znaleźć działający kod.

Poczytaj sobie dokumentację https://git-scm.com/book/pl/v2/Pierwsze-kroki-Wprowadzenie-do-kontroli-wersji

Na razie nie musisz wszystkiego zapamiętywać, ważne, żebyś się orientował jakie są możliwości. Jeżeli będziesz potrzebował jakiejś funkcjonalności to zawsze możesz wrócić do dokumentacji.

Git rządzi!