[Git]jak odwzorować Git workflow z localhostem?, osobny folder z plikami dla wersji produkcyjnej i osobny dla lokaln... Opcje

[koszykarze]

chcę do nauki zacząć używać jakiś Git workflow robiąc na localhoście.

W różnych workflows występują takie mniej więcej kroki:
- na githubie mam główne repozytorium remote origin/master
- lokalnie mam odwzorowany branch master
- z lokalnego branch master tworzę branch develop
- z develop tworzę branche feature
- skończone branche feature merguję w develop i taguję. usuwam branch feature
- develop merguję z lokalnym master
- lokalny master push do repozytorium origin/master na githubie

no dobrze,
a co znajduje się w folderze projektu na localhoście?
czy mam mieć dwa osobne foldery projektu, jeden niby lokalny na którym pracuję a drugi osobno produkcyjny niby remote?
czy mam w folderze na localhoście zrzucać PULL z origin/master?
a może mam mieć jeden folder projektu na localhoście który jednocześnie robi za lokalne repozytorium i remote


(wybaczcie za głupie sformułowania/spolszczenia)

[aniolekx]

jeden folder na ktorym pracujesz

[Pyton_000]

Taguje się Release a nie feature.

[nospor]

GIT jest samo wystarczalne samo w sobie. Jak nie chcesz miec gdzies na serwerze oddzielnej kopii to nie musisz miec zadnego remote. Nie mniej jednak dobrze miec, bo jakby nie patrzec to bedzie tez twoja kopia jakby ci dysk padl
Poza tym jesli pracowac bedziesz nie tylko sam ale jeszcze z kims, to dobrze by bylo miec GIT remote by kazdy z was mial do niego dostep.

czy mam w folderze na localhoście zrzucać PULL z origin/master?

No jesli pracujecie w kilka osob i kazdy moze robic zapis do origin to tak, wypadaloby robic PULL by miec zmiany innych ludzi u siebie. Bez tego raczej bedzie ciezko zrobic PUSH
Jesli pracujesz sam to nie ma potrzeby robic PULL bo przeciez tylko ty PUSHujesz.

U siebie na kompie masz miec jeden folder projektu. Jest to twoja kopia projektu GIT. Jesli masz podpiety jakis remote, to do niego PUSHujesz swoje zmiany oraz z niego robisz PULL jesli pracujecie w kilka osob.

[koszykarze]

@nospor
się nieprecyzyjnie wyraziłem.

Nie ma żadnego serwera osobnego. Fizycznie jest mój komputer i na nim wamp. Tylko chcąc używać Git workflow chciałbym to robić zgodnie ze sztuką, ale też by nie było zbyt upierdliwie. (No i jestem sam.)

(Releasy i tagi do niczego mi potrzebne, ale tak dla treningu mógłbym je porobić. )


Czyli tak,
- mam w wamp/www/ lokalne repozytorium z branchem master odzwierciedlającym origin/master na githubie
- z master branch off develop
- z develop branch off feature branch
- feature merge w develop
- release branch off develop, tag
- release merge z master
- master push do origin/master
- mając jeden folder z projektem, który jest i produkcyjny i dev za każdym razem gdy chcę zobaczyć witrynę w wersji produkcyjnej to robię checkout master (trochę głupio)

ale dwa foldery projektu obok siebie jeden udający, że jest na osobnym serwerze a drugi na którym pracuję też trochę głupio.

czyli origin/master na githubie z powyższego workflow służy mi jako ładny przegląd historii commitów, backup i planowanie kolejnych feature/issue

a w rzeczywistości gdybym moją stronę trzymał na serwerze firmy hostingowej to prawidłowym workflow byłoby wprowadzać zmiany lokalnie, pushować na origin/master i z niego dopiero jakoś na hosting. Tak?

Ten post edytował koszykarze 11.05.2016, 22:30:47

[Pyton_000]

Remote nie jest Ci do niczego potrzebne i nie odnosi się do Git Flow.

Nie wiem na czym się wzorujesz przy flow ale to jest chyba najbardziej popularna metoda: http://nvie.com/posts/a-successful-git-branching-model/

2 foldery są kompletnie zbędne, bo co... będziesz się cały czas gapił na master? Robisz feature, wrzucasz na dev, testujesz, fixujesz, robisz release, fixujesz drobne poprawki do tego co już masz (nic nowego) i wtedy robisz merge z master i tam dodajesz tag.sprawdzasz sobie czy wygląda OK i dalej działasz na develop/hotfix/feature.

A jeszcze ad. releas i tag. Sądząc po wypowiedzi to nawet flow Ci jest nie potrzebny
Musisz sobie uświadomić że git flow to nie jest jakieś tam sobie klepanie branchy, tagów. To cały rytuał. Robienie Releas to tak na prawdę ceremonia wydania kolejnej wersji oprogramowania a Tag to już taka wisienka na torcie.

[nospor]

Nie ma żadnego serwera osobnego.

mam w wamp/www/ lokalne repozytorium z branchem master odzwierciedlającym origin/master na githubie

Moze zle sie wyrazilem. Nie mialem na mysli specjalnego serwera. Poprostu zdalne repo. GITHUB jest wlasnie takim zdalnym repo.

czyli origin/master na githubie z powyższego workflow służy mi jako ładny przegląd historii commitów, backup i planowanie kolejnych feature/issue

Jak juz pisalem wczesniej: kazde repo GIT, czy to lokalne, czy zdalne, jest tak samo funkcjonalne. Logi/comity - to wszystko mozesz sprawdzac rownie dobrze w lokalnym repo.

[koszykarze]

Nie wiem na czym się wzorujesz przy flow ale to jest chyba najbardziej popularna metoda: http://nvie.com/posts/a-successful-git-branching-model/

dzięki, już czytałem, w zasadzie przeczytałem już cały internet na ten temat. Powtarzają się opinie, że ten workflow z nvie.com to bardziej do aplikacji niewebowych, gdzie tworzy się releasy z rzadka, że nie sprawdza się, gdy co chwilę wprowadza się zmiany w master.

Ciężko znaleźć w sieci opis workflow git dla aplikacji webowych.

[Pyton_000]

Pitu pitu... To zależy od podejścia. Fakt że wtedy będziesz miał miliard tagów ale czy to problem? Równie dobrze możesz tagować co xxx release

[koszykarze]

Piszę dla tych, którzy w przyszłości tu trafią szukając hasła "git workflow"

przeczytałem wszystko w internecie na temat git workflow, w większości świetnych opisów, obejrzałem dwa świetne video kursy, ale szczególnie polecam https://www.atlassian.com/git/tutorials/com...itflow-workflow jest tu wszystko o czym czytałem na innych stronach, ale wytłumaczone tak, że lepiej nie można. Super obrazki, scenariusze jak dla opóźnionych w rozwoju, po prostu idealnie. (Albo ciśnienie atmosferyczne zaczęło spadać po burzy. Nie wiem.)