Ostatnio poznaje system kontroli wersji git, i cały czas tworzę i bawię się nim i uczę dokonując zmian na lokalnym dysku, robiąc kopie na zdalne repozytorium i odwrotnie, ale cały czas zmian i edycji plików, które git śledzi dokonuję lokalnie na komputerze. Czy w taki sposób też fachowo się podchodzi gdy koduje kilka osób, tzn. edycji plików serwisu internetowego dokonuję się na jakimś lokalnym apachu ( np. wersja testowa ) , jeśli już wszystko jest okey to klonuje się do repozytorium te wszystkie zmiany i stamtąd dalej kopiuje i zmienia pliki na innym serwerze i podmienia pliki projektu? Zawsze pracowałem raczej zdalnie na serwerze i chciałbym się dowiedzieć jak to się fachowo odbywa działając z repozytorium git`a - to luźne pytanie, dlatego też umieściłem tutaj do hydeparku

Jest całe forum poświęcone zarządzaniu projektami (Tak GIT też się w to wpisuje).

Przeszukaj sobie kilka stron pod kątem GITa i poczytaj. Jest tam wiele wartościowych tematów (odpowiedzi na Twoje pytania również)

mniej więcej.

z tym, że często pracuje się na tzw. gałęziach/branchach w Git i potem się je scala. Czasem są jakieś konflikty, jeśli dwie czy więcej osób ruszało ten sam plik. Trzeba wtedy wybierać które nanoszone zmiany mają się znaleźć w wersji końcowej.

Można też na bieżąco pracując na jakiejś gałęzi scalać/bazować się na gałąź główną (np. master czy develop), są komendy do tego, git merge, czy git rebase. Wtedy robisz coś swojego, a jednocześnie masz również te wszystkie zmiany, nad którymi ktoś pracuje (bez tego jak pracujesz na swojej gałęzi to możesz być do tyłu trochę).

poza tym pracuje się też często na tzw. pull requestach (robisz coś, pushujesz do zdalnego repozytorium, a potem prosisz, żeby zmerdżowali, przy okazji możesz mieć robiony code review i np. komentarze do twojego kodu).

poza tym może być system testujący i żeby cokolwiek dodać, muszą wszystkie testy(jednostkowe czy inne) przejść pozytywnie (co jest w miarę oczywiste, bo ciężko dodawać coś, co psuje całą aplikację).

itp. itd.

achaaa czyli aktualizuje sie tylko te pliki ktore zostaly zmienione i aktualizuje sie czesc a nie calosc, logiczne, dziekuje;-) a jak się rozwiazuje system produkcyjny, testowy, finalny itd - to sa trzy repozytoria na przykład, z czego jeden to produkcyjny, drugi np. developerski i jeden z nich jest oficjalny a na drugim sobie pracuje i testuje i jesli przeszedł testy to aktualizuje się oficjalny projekt i użytkownicy wtedy widzą zmiany? ;-) czy jakaś inna droga jest?
Kurcze, ciekawa sprawa, że ja wcześniej się tym poważniej nie zająłem, ile problemów by mi to zaoszczędziło ;-P

Tzn. to Git akurat z automatu robi, sam wykrywa które pliki zostały zmienione i nanosi zmiany (chyba, że są konflikty)


Myślę, że to o co tutaj pytasz, to już nie jest kwestia samej pracy z Gitem, co ogólnie przyjętego workflow (który może się różnić zależy gdzie trafisz), od tego czy jest to agile czy waterfall, od używanych rozwiązań serwerowych itp. itd. Myślę, że to już ci powiedzą dokładnie w konkretnej firmie, w której będziesz pracować.

Jeśli chodzi o to, że tylko zmiany zapisuje sam git to tak - wiedziałem, taka jest jego rola Hmm, właśnie czytam odnośnie git flow i jest fajny pomysł różnych gałęzi typu produkcyjny i developerski i na docelowym katalogu gdzie np. aplikacje używają już użytkownicy i trzeba nanieść poprawki/zmiany to merdżuje się tylko poszczególne gałęzie itd.. No nic, czytam dalej i dziękuję za wskazówki i odpowiedzi ;-)

Swoją drogą ale zgadłeś, że zamierzam zmienić pracę ;-) Tylko chciałbym nabrać wprawy z gitem, bo jak widzę rozwiąże wiele problemów z klientami ( przecież to robiliśmy tak, a potem działa tak? No działa tak, bo jak mówiłem zmieniając tamto musieliśmy zmienić i to - a tak mam wszystko na białym i nie muszę specjalnie przeglądać archiwum emaili że wtedy i wtedy podjął decyzje że zmieniamy to i tamto)

Ten system też proponuję zmienić na coś bardziej czytelnego niż maile, ja osobiście uzywam do swoich nie wielkich projektów gdzie pracuje maks 3-5 osób razem z klientem używam asana
To w połączeniu z gitem pozwala zaoszczędzić dużo czasu