Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Witam.
Chciałbym w końcu założyć repozytoria do swoich projektów. Zdecydowałem się na GIT'a, ale z tego co widzę to wszystkie systemy kontroli wersji to strasznie duże kobyły z dziesiątkami opcji... nie umiem się w tym ogarnąć.
Stad pytanie do osób używających GIT'a, lub jakiegoś innego SCM'a jak ogarnąć poniższe sytuacje:
Sytuacja 1:
Zaczynam tworzyć jakieś oprogramowanie, założyłem sobie repozytorium. Co dalej? Zakładam że trzeba założyć sobie dwa branch'e - jedną stabilną jedną deweloperską, dobrze myślę że do stabilnej kod ląduje dopiero po zrealizowaniu jakiejś funkcjonalności, a do dev'a ląduje wszystko inne, czy to poprawne zachowanie? Czy podobnie należy się zachować w przypadku kodu gotowej aplikacji - czytaj jeden branch dla wersji 1.0 drugi dla 2.0 itd. czy jakoś inaczej.
Sytuacja 2:
Kilku deweloperów pracuje nad aplikacją "A". Każdy z nich tworzy niezależne od siebie funkcjonalności - pytanie jak się mają branche do takiej sytuacji? Na kilku stronach wyczytałem że dobrą praktyką jest tworzenie osobnych branch'y dla każdej funkcjonalności... czy to prawda.
Sorry że tak chaotycznie - ale lepiej wyrazić tego nie umiem, w sumie to chyba po prostu pytam jakie są dobre praktyki dbania o kod w systemie kontroli wersji.
Z góry dzięki za info.
Pozdro.
Offline
S-1
Nie ma ogolnej zasady "co jest złe " a co "dobre". Bardziej istotne jest co jest "wygodne" , no i wygodnie jest trzymac jedna gałązkę na której kod jest utrzymywany w wersji stabilnej, zawsze masz wersje oprogramownaia która działa, wygodnie jest miec gałązke developmentu, do której dorzucasz zmianny. Ale dwie to stanowczo za mało :-), tyle jestes w stanie osiagnać z dwoma folderami i je kopiować XD. Ale idąc dalej tym tropem jezeli masz dwie wersjie oprogramowania 1.x i 2.x no to potrzebujesz minimum 4 gałazek. itp itd.
S-2
Wygodnie jest dorzucac nowe "ficzery" tak zeby kazdy maił swoją gałązkę. Jeżeli ficzer jest duży, no to dzielisz go na mniejsze taski to zrealizowania noi dla kazdego tasku mozesz utworzyc gałązkę.
master ( stable ) ----------o--------------------------------------------------------------------------------------------------------------------- \ DEV o---------o-----------Tutaj pracuja inni ludzie, tez sie wypinaja tworza cos i potem merge------------------------------o----------- \ / Ficzer_1 o-----------------o---------o-------------------o-------o-------------------o----------o------------------o ficzer skonczony, merge do gałazki developerskiej \ / \ / \ / \ / o---Task_1----o o----Task_2---o o----Task_3-----o o---Task_4-----o
Ostatnio edytowany przez gindek (2013-01-27 11:26:23)
Offline
Nie myśl w kategoriach schematów „poprawne” i „niepoprawne”.
System kontroli wersji — każdy — to narzędzie. Możesz go używać w sposób efektywny lub nie; może ono znacznie ułatwiać Twoją pracę, tylko trochę a nawet ją spowalniać.
To Ty wiesz, w jakiej sytuacji się znajdujesz, jaki sposób pracy najlepiej odpowiada Twoim preferencjom i jakie problemy chcesz rozwiązać przy pomocy systemu kontroli wersji. Innymi słowy: to Ty musisz sobie stworzyć taką strukturę, która najbardziej Tobie odpowiada. Zacznij od czegokolwiek — po dwóch tygodniach będziesz wiedział, gdzie znajdują się słabe punkty obecnego systemu (które czynności sprawiają Tobie problemy, są nieintuicyjne itp.).
Oglądanie się za innymi nigdzie Cię nie doprowadzi. Chyba że naprawdę wierzysz, że sposób rozwoju ogromnych programów (jak Linux czy LibreOffice) będzie odpowiedni również dla Twoich prywatnych, rozwijanych przez jedną osobę, aplikacji.
Offline
Rozumiem, a odwracając pytanie - czego zdecydowanie NIE robić? Zapewne tutaj można coś wskazać :) ?
Offline
nie uzywac tylko jednej gałazki i na nia wszystko commit && push. Bo to ma nikły sens.
Offline
OK, dzięki za info.
Trochę poczytałem, potestowałem i chyba zaczynam łapać jednakże dwa pytania mi się nasuwają:
Czy dobrze myślę że w praktyce działanie na projekcie powinno wyglądać tak:
1. Klonujemy repo:
git clone jakieśRepoProjektu
2. Osoba która pobrała repo ma za zadanie dodać "ficzer1" więc daje:
git branch ficzer1 (czy coś podobnego) && git checkout ficzer1
3. Osoba robi co ma zrobić, koduje, testuje itd
I w tym momencie pytanie - czy taka osoba po zakończeniu pracy powinna to wcheckować do mastera (czy tam innej wybranej gałęzi), na zasadzie:
1. Przełączyć się na master:
git checkout master
2. Zmergować zmiany mastera z branchem "ficzer1":
git merge master ficzer1
3. Wypchnąć zmiany do zewnętrznego repo:
git push origin master
Czy też powinna jakoś stworzyć patcha komendą:
git format-patch master --stdout > ficzer1.patch
i przesłać komuś innemu odpowiedzialnemu za checkowanie kodu? Jak to u Was wygląda?
Offline
Jak bys mial jakies problemy to sie nie zniechecaj , tool jest swietny, trzeba sie tylko nauczyc myslec na innym poziomie abstrakcji :-).
2. git checkout -b nazwa_nowej_galazki
w ten sposob utworzysz nowa galazke oraz automatycznie zostaniesz na nia przełączony
piszezs cos, stwierdzasz ze jest dobre, :-) wiec musisz zrobic na tym commit, jezeli plik nie był indeksowany przez gita, musisz najpierw go dodać.
3a. stworzyles nowy plik, nie jest jeszcze indeksowany przez gita.
git add sciarzka_nazwa_nowego_pliku
bedziesz musial pozniej wykonac commita
3b. plik istniał juz wcześniej, ty go tylko edytowałes, zmiany które wprowadziłeś musisz "skommitować"
mówisz w ten sposób gitowi "ten kod ktory napisałem jest dobry, zapisz zmiany względem poprzedniej wersji"
git commit -m "jakas tam wiadomosc" -- nazwa_pliku_edytowanego
magiczne -- oznacza "skonczylem podawac opcje do polecenia, dalej beda scierzki lub/i nazwy plikow"
3c. jest graficzny tool do wykonywania commitow :-), przydaje sie bo ładnie mozna message wpisac no i bardzo ładnie mozna wybrac które konkretnie zmiany z pliku chcesz "zapisać w gicie". Gigantycznym plusem jest ze mozesz wybrac ktore zmiany chcesz zapisac, np. rozwiazujes jakiegos buga, dopisałeś 150 z logami XD, znalazleś problem, dopisałeś "fiksa" na 3 linijki i tylko te 3 linijki chcesz miec w kodzie finalnym. W zwiazku z tym odpalasz citool, zaznaczasz zeby tylko te 3 linijki weszły jako zmiana w historii pliku.
git citool
prawde mowiac ja nigdy nie robie commitow "z palca" zawsze w citool :-). Ze wzgledu na bardzo naturalny sposob pisania długich komentarzy do commita.
Teraz kiedy zmiany są zapisane na gałązce w postaci commita, mozesz wykonac reszte czynnosci czyli przełączyć się na mastera, zrobić merge , potem push.
Przy malych projektach chyba wystarczy trzymać zdalnie tylko główne gałązki. Ja w pracy na zdalnym repo trzymam wszystko co robie.
Czyli kiedy klepne "ficzera" to oczywiście robie merge & push na "masterze". Ale robie tez push mojej gałązki
git push origin nazwa_gałazki
Jeszcze takie przydatne poleenia
git branch -pokaze lokalne galazki
git branch -r -pokaze zdalne galazki, te ktore sa na serwerze, ktorym push zrobil ktos inny
git remote -pokaze aliasy dla serwerow
git remote -v -pokaze alias oraz adres serwera do ktorego jest ten alias przypisany
git posiada bogatego helpa :-).
git --help git komenda --help git branch --help
Na koniec, ja miałem problem i komendy były dla mnie mało intuicyjne, np.
- przełączasz sie pomiedzy branchami przy uzyciu :
git checkout a nie git branch
- tworzysz nowa galazke przy uzyciu
git checkout -b ale jak chcesz zobaczyc galazki git branch ale przy usuwaniu lokalnej gałazki git branch -d nazwa_galazki git branch -D nazwa_galazki --- usuwanie z force no i moj faworyt na koniec, przy usuwaniu zdalnej gałązki dajesz .... uwaga jebniesz xd git push origin :nazwa_galazki tak tak usuwanie i dodawanie na serwerze gałązek rozni sie tylko znaczkiem "dwuciapka"/"dwukropka"/"colon" czyli :
tak jak na to teraz patrze to troche pojebane to.
Ostatnio edytowany przez gindek (2013-01-31 00:14:23)
Offline
@gindek:
Wielkie dzięki za porządny opis :)
Już trochę potestowałem i klika repów założyłem. Akurat w moim wypadku Git ma być używany do projektów .Netowych więc korzystam z tego co rozszerzenia dla Windosa dostarczają, ale chyba wszystko jest ok. Jeszcze raz dzięki :)
Jak bym czegoś nie wiedział to wiem do kogo się zgłosić :P
Pozdro.
Offline
np.
Offline
Przy git commit mozna tez pominac -m, a w celu podania wiadomosci otworzy nam sie $EDITOR.
A selektywne dodawanie bez graficznego interfejsu zapewni git add -p oraz git commit -p.
Jak juz jestesmy przy commit message'ach, warto poczytac (niekoniecznie od razu uzywac): http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Podstawy: http://git-scm.com/book http://hoth.entp.com/output/git_for_designers.html
Troche inaczej: http://think-like-a-git.net/epic.html
Ostatnio edytowany przez Carnophage (2013-01-31 14:34:04)
Offline
Strony: 1