Hejka, pewnie już niejednokrotnie zadawano pytania dotyczące GIT'a szczególnie na temat jak tego używać, żeby nie narobić więcej szkód niż pożytku.
Mam jednak nadzieję, że mi podpowiecie (Ci doświadczeni).
Właśnie zacząłem używać ale mam kilka wątpliwości czy aby mój admin napewno wie co robi .
Dlaczego mam wątpliwości .... otóż ostanich kilka tygodni spędziłem na budowaniu kilku modułów z nadzieją, że zostaną dołączone do istniejącego systemu,
wszystko miałem praktycznie skończone i po jednym z commit'ów okazało się nagle, że wszystko co zrobiłem ... odeszło w niepamięć a zostało jedynie to, co zrobiłem około miesiąc temu. Zmartwiłem się bo żadnej kopii nie miałem, w końcu jak się używa SVN/GIT czy innego ...... musiałem wszystko od praktycznie zera klepać! Nie mam także pewności czy moja pamięć przechowała wszystkie linie kodu w poprzedniej postaci, może coś dodałem a może o czymś zapomniałem ...
Na razie działa ale czy wszystko ... to się okaże
Na pytanie dlaczego giną mi zawartości plików nie potrafił odpowiedzieć, ja z kolei z braku doświadczenia z GIT'em nie mogę mu udowodnić błędu.
Pliki dodane do trackowania, czyli rozumiem, że jeśli dokonuję jakichkolwiek zmian, system w przypadku "commit'a" a następnie "merge'a" powinien wszystkie zmiany uwzględnić tak i trzymać w takiej postaci w jakiej je zostawiłem czyli z ostatnimi modyfikacjami??
Poleciłem mu w piątek zrobić "commit" tylko wskazanych plików, jutro się dowiem co znowu mi wymazał
Czy może czegoś nie zrozumiałem i źle pojmuję istotę działania GIT'a ?
Mógłby mi ktoś ten temat lekko rozjaśnić albo może odesłać jeśli istnieje jakaś dokumentacja po "polskiemu" co bym w pełni zrozumiał o co w tym chodzi ?
Prościej chyba się nie da:
http://rogerdudler.github.io/git-guide/index.pl.html
Używasz jakiegoś programy do programowania, np. Netbeans ? Jeśli tak masz tam zapisaną historię swoich plików.
Admin do commitów, coś nowego.. Jeżeli terminal jest tak makabrycznie odstraszający swoją prostotą, to z drugiej strony dla klikaczy jest tak dużo narzędzi do gita, że aż mnie dziwi, że ktoś puszcza commity twojego kodu za ciebie. Git sam ci plików nie kasuje, więc zapewne albo ten cały admin (nie wiem dlaczego ale ciężko mi się go nazywa adminem ) albo wrzucił do stasha (schowka) te pliki, albo skasował je ręcznie (rm lub checkout). Więc sprawdź najpierw czy nie masz tych plików w stashu używając tej komendy w katalogu projektu:
Windows też ma przyjazną konsolę chyba właśnie z tortoisegit.
Ja jednak preferuję konsolę nad gui w tym wypadku.
https://git-scm.com/book/pl/v1
Z opisu wynika ze ty pracujesz bezposrednio na serwerze a nie na swoim lokalnym kompie?
Owszem ale oczywiście nie na "produkcyjnym", Dev-site a jedynie finalny kod idzie na "żywy"
A czemu nie pracujesz na wlasnym lokalnym kompie? Praca na serwerze, nawet na dev, to jakis zart.
Jak sobie wyobrazasz prace 5 osob wowczas? Wszyscy w tym samym czasie pracuja na tym samym kodzie? Pol biedy jak robia zupelnie rozne czesci, ale jak nagle przyjdzie pracowac nad tym samym plikiem to... hej, Franek, teraz ja robie zapis do pliku xyz.txt to ty sie wstrzymaj... kuzwa, Krzychu, nadpisales moje zmiany....
Inny przyklad "zajebistosci" tego rozwiazania masz w pierwszym poscie tego tematu.
Tylko, że każdy na tym serwerze może mieć postawioną swoją wirtualną maszynę, lub pracować w katalogach użytkownika i pewnie jeszcze kilka innych rozwiązań.
oczywiscie ze moze. Moze tez miec skrzynke zlota pod stolem.
Z tym problemu nie ma.
Dlaczego taka organizacja .... taki porządek zastałem i własnie jesteśmy na etapie ustalania dalszej poltyki a co za tym idzie zmian w strukturze i organizacji wszystkiego.
Tak jak jest w tej chwili .... jest poprostu beznadziejnie. Po pierwsze dlatego, że Dev-servery znajdują się gdzieś w jakim "Data-centre" i nawet najmniejsze zmiany i testowanie zjada mnóstwo czasu. Po drugie dostęp mimo dość szybkiego łącza, jest zdumiewająco powolny i trafia mnie jak mam np wciągnąć większą ilość plików ... ale mniejsza o to.
Jak pisałem wczesniej, pracujemy nad zmianami więc wkrótce może będę miał lokalny serwer a jedynie "produkcyjny" będzie na zewnątrz.
Mam nadzieję, że po wakacjach ruszymy z tym tematem (znaczy za jakieś 3 tygodnie jak wrócę).
@PHPRexio no i cool
@destroyerr mialem kiedys "przyjemnosc" pracy na dev serwerze i tak, kazdy mial swoj oddzielny dev-server. Chcialem pracowac na PHPStorm i niestety ale to byl koszmar. Predkosc synchronizacji/zapisu niestety uniemozliwiala jaka kolwiek sensowna prace. Po paru tygodniach juz mnie nie bylo w tamtej firmie (ps: nie, oni mnie nie zwolnili, sam odszedlem)
Heheh @destroyerr: ja tam nie zamierzam odchodzić, zamierzam zmienić co nieco, dostosować to jakiegoś normalnego standardu i pracować
Tymbardziej, że mogę i dodatkowo bo słuchają co do nich mówię
Przy okazji też dobrze płacą
@nospor nie tylko te rzeczy które wymieniłeś są problematyczne, problematyczne dodatkowe rzeczy to:
- brak dostępu do neta paraliżuje cały development;
- awaria serwera paraliżuje cały development;
- kogoś nieuwaga i restart czegoś paraliżuje cały development;
- niepotrzebne koszta;
I pewnie dochodzi jeszcze do tego jeden mankament: gdyby to było w miarę zrozumiałe dla wszystkich, jak się takie usługi stawia, to większość nie bawiła by się w zaciąganie zmian po ssh/sftp tylko postawiłaby sobie takie środowiska lokalnie. Ale tego nie robią z 2 możliwych powodów - nie wiedzą jak, lub nie mogą (np pracują na windowsie), więc w przypadku awarii i braku "gościa" co się tym zajmuje, cały development jest sparaliżowany. Ale w sumie daleko szukać nie muszę, podobna sytuacja jest w nowej firmie w której aktualnie pracuje, że sporo rzeczy jest testowane na serwerach, bo wszyscy pracują na makach a większość tego softu albo na makach nie działa, albo instalacja jest skrajnie trudna.
Cóż, moje rady:
- windows to niezbyt fajne środowisko do webdevelopmentu;
- z terminalem/konsolą trzeba się oswoić, bo nikt nie będzie tworzyć interfejsów do byle pierdoły. Większość tych rzeczy ma działać na serwerach, gdzie interfejs graficzny jest średnio wskazany (po co to komu tam..);
- zainteresować się dockerem - można sobie środowiska stawiać jednym poleceniem, ostatnio nawet na maku działa to dość podobnie do tego jak działało na linuxie (windows patrz punkt pierwszy);
W poprzedniej firmie całość (dev/staging/master) mieliśmy tak zaprojektowane że nie różniły się od siebie niczym, z wyjątkiem portów/hostów. Ktoś nowy przychodził to po poświęceniu kilku minut nad plikiem readme stawiał sobie całe środowisko w kilka minut i już mógł zacząć pracować. Pamiętam pierwszy raz jak przyszedłem do tej firmy to środowisko tłumaczyli mi 2 dni jak instalować, a i tak nie działało to identycznie jak w przypadku stagingu/mastera bo były różnice w działaniu PHP'a na windowsie i linuxie. W nowej firmie jak dostałem maka i zobaczyłem że do dockera trzeba instalować virtualboxa, to podzieliłem sobie dysk i zainstalowałem na drugiej części dysku ubuntu (na mbp). Dzisiaj developerka bez tego to jak powrót do średniowiecza (windows and associates). Całe szczęście wstrzeliłem się w okres gdzie na maka napisali od podstaw dockera, który działa bardzo podobnie jak ten na linuxie..
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)