Codzienna praca z gitem.

0

Dotychczas programowalem sam, zmieniam prace i beda nas 4 osoby w zespole.

Czy dobrze opisuje metodyke pracy z gitem (glupio byloby sie na czyms takim osmieszyc :P)

Jeśli mam do zrobienia cos wiecej niz zmiana 2 linijek w jednym pliku:

  • zakladam nowe brancha
  • checkhoutuje sie do niego

koduje, koduje

-commituje wszystkie zmiany
-checkhoutuje sie do mastera

  • merguje sie z branchem //moze tu gdzies pull, czy nie ma sensu i tak jesli problem to push nie przejdzie ?

i robie pusha (jesli nie ma konfliktow to ok)
usuwam brancha (jesli juz nie bedzie potrzebny)

jesli sa, wlaczam synchronizacje i modyfikuje swoje pliki, commituje je i pushuje wszystko

Czy to wyglada ok ? Czy wystarczy w typowej pracy ?

Dotychczas pracowalem z Intellijem, teraz bede mial Eclipsa.
Jakie dodatki trzeba do niego zainstalowac, aby pracowac z projektem java, git, wcket, tomcat itp.

0

Sam niedawno zaczalem przygode z Gitem wiec moze wypowiedza sie tutaj bardziej doswiadczeni :)

U mnie w kazdym razie wyglada to podobnie :) Tj. merge brancha do mastera po zakonczonej pracy nad danym taskiem.

0

Dotychczas pracowalem z Intellijem, teraz bede mial Eclipsa.

Odradzam. Eclipse ma wtyczke egit która raz działa raz nie. W szczególności merge w zasadzie nie działa. Ergo jeśli będziesz korzystał z eclipse to niestety razem z jakimś TortoiseGitem.

2
  1. git fetch
  2. zakładam brancha przez git checkout origin/master -b <nazwa_brancha>
  3. wprowadzam zmiany, git commit (wielokrotnie)
  4. gdy skończę, git push origin <nazwa_brancha> (tworzy zdalnego brancha w repozytorium) i zakładam pull-request na GitHubie
  5. czekam na recenzje i testy
  6. jeśli wymagane są poprawki, dalej komituję do brancha i robię kolejne pushe
  7. jeśli kod przejdzie wszystkie testy naciskam duży zielony guzik na GitHubie i mój kod ląduje w gałęzi master; ten duży zielony guzik to jest najfajniejsza rzecz w całym procesie; niestety przyjemność z jego naciśnięcia jest tak duża, że ostatnio szef coraz częściej wciska go samodzielnie...

Jeżeli proces trwa długo, to czasami konieczne jest zrobienie merge odwrotnego - tj. dociągnięcie wszystkich zmian z mastera do mojej gałęzi zanim naciśnie się zielony guzik.

0

Ja GITa używam praktycznie do wszystkiego, nawet dla stronek WWW i innych głupotek:

( Najlepiej korzystać z GIT console )

Tutaj macie tutorial:
http://www.chartingcontrol.net/WebChartDemo/ChartTypes.aspx

1
  1. Master jest "święty i nietykalny" to kod, który jest jeszcze rozwijany lecz nie jest na produkcji.
  2. Tworzysz branch dla zmiany/zmian/większego zadania
  3. Tworzysz ten branch na głównym repo
  4. Wszyscy zainteresowani pushują tam kod.
  5. Kod przechodzi testy - serwer CI prawdę ci powie
  6. Robisz merge do mastera.
  7. Jeżeli kod z mastera nadaje się na kolejną wersję to robisz taga

Przydatne opcje

  1. Branche lokalne do ogarniania wielu zadań
  2. Stash czyli takie magiczne "skrzyneczki" na zmiany
  3. Ustawienie remote repo dla branchy na komputery innych programistów w celu skrócenia linii dostarczenia poprawek
  4. Serwer CI na buildy z twojego lokalnego repo.

Eclipse ssie jeśli chodzi o obsługę gita. Używaj Idei, a jak nie możesz to opanuj gita z linii poleceń i gitgui

0

@Shalom wspomniałeś o TortoiseGit. Czy dla kogoś kto nie korzystał z Git'a, a wyłącznie z svn'a za pomoca TortoiseSvn'a - przydatne będzie takie narzędzie ? Czy odpuścić całkowicie i z linii poleceń się nauczyć ?

3

W graficznym narzędziu jednak łatwiej podejrzeć pliki, które chce się zacommitować, i ich zawartość. Historię zmian w plikach też wygodniej oglądać w GUI, a nie w konsoli.

0

@axelbest podpisuje się pod ty co napisał somekind. Mnie się jednak łatwiej klika w okienkach, szczególnie jak bawisz się w przeglądanie historii commitów czy diffowanie plików.

0

Tylko terminal! Parę razy jak w GUI coś spieprzyłem to potem nie miałem pojęcia jak to odkręcić. W TUI jakoś mi się to nie zdarza.

1 użytkowników online, w tym zalogowanych: 0, gości: 1