Zacząłem uczyć się gita. Chcę go używać do moich projektów PHP+MySQL. Mam 2
pytania do praktyków:
1. Rozumiem że gałąź (branch) tworzymy gdy chcemy wypróbować jakąś zmianę w
kodzie, której nie jesteśmy pewni czy ją zaakceptujemy. Np. czy dodanie do
projektu jakieś funkcjonalności mam sens. Kiedy jeszcze tworzymy gałęzie?
2. Kiedy w praktyce wykonujemy operację merge? Kiedy mergujemy z gałęzią
master?
Byłbym wdzięczny za wytłumaczenie.

do góry

W dniu 12.09.2016 o 15:42, Jivanmukta pisze:
> Zacząłem uczyć się gita. Chcę go używać do moich projektów PHP+MySQL. Mam 2
> pytania do praktyków:
> 1. Rozumiem że gałąź (branch) tworzymy gdy chcemy wypróbować jakąś zmianę w
> kodzie, której nie jesteśmy pewni czy ją zaakceptujemy. Np. czy dodanie do
> projektu jakieś funkcjonalności mam sens. Kiedy jeszcze tworzymy gałęzie?
> 2. Kiedy w praktyce wykonujemy operację merge? Kiedy mergujemy z gałęzią
> master?
> Byłbym wdzięczny za wytłumaczenie.
>

U nas w firmie stosujemy się do zasad opisanych tutaj:
http://nvie.com/posts/a-successful-git-branching-mod
el/

--
Robert

do góry

On Monday, September 12, 2016 at 3:42:54 PM UTC+2, Jivanmukta wrote:
> Zacząłem uczyć się gita. Chcę go używać do moich projektów PHP+MySQL. Mam 2
> pytania do praktyków:
> 1. Rozumiem że gałąź (branch) tworzymy gdy chcemy wypróbować jakąś zmianę w
> kodzie, której nie jesteśmy pewni czy ją zaakceptujemy. Np. czy dodanie do
> projektu jakieś funkcjonalności mam sens. Kiedy jeszcze tworzymy gałęzie?
> 2. Kiedy w praktyce wykonujemy operację merge? Kiedy mergujemy z gałęzią
> master?
> Byłbym wdzięczny za wytłumaczenie.

U nas było tak:

- gałąź master na produkcję,
- gałąź dev na nową wersję produkcyjną,
- gałęzie na nowe funkcjonalności do dev,
- lokalnie to każdy sobie dodawał branche, jak mu pasowało.

Gałęzie na nowe funkcjonalności musiały być przed mergem rebasowane
do dev (żeby przed mergem przetestować lokalnie wszystkie zmiany
z deva).

Przed wydaniem wersji robiło się merga mastera z devem, tagowało
master i tyle.

W przypadku błędów na produkcji (zdarzają się, kurde), patche były
nanoszone bezpośrednio na mastera i wtedy master był mergowany
do deva, albo robiło się cherrypick poprawki.

Aha, mieliśmy jedną zasadę - branche na nowe funkcjonalności musiały
był pushowane na koniec dnia. Żeby w razie awarii, choroby, whatever,
ktoś inny mógł kontynuować prace na funkcjonalnością.

w.

do góry

Dzieki za odpowiedzi.
Mam pytanie: z czego uczyć się gita? Kupiłem książkę Gajdy - powierzchowna.

do góry

> Mam pytanie: z czego uczyć się gita?

https://progit.org/

Dodatkowo oczywiście obowiązuje dowcip:

- Czy Gita można używać off-line?
- Nie, bo potrzebny jest stack overflow, żeby wiedzieć, co robić.

--
Maciej Sobczak * http://www.inspirel.com

do góry

Maciej Sobczak wrote:
> https://progit.org/

Dzięki za odpowiedź.
Ściągnąłem sobie też trochę prezentacji.

do góry

Jak mogę pobawić się operacjami push/fetch/pull? Czy są gdzieś w sieci takie
repozytoria do testów czy mam założyć własne na githubie/bitbucketcie?

do góry

On Friday, October 28, 2016 at 4:53:29 PM UTC+2, j...@p...onet.pl wrote:
> Jak mogę pobawić się operacjami push/fetch/pull? Czy są gdzieś w sieci takie
repozytoria do testów czy mam założyć własne na githubie/bitbucketcie?

Raczej nie ma testowych. Jak chcesz poćwiczyć, to nawet na dysku lokalnie
możesz założyć repozytorium. Ale najlepiej chyba zacząć po prostu używać
w praktyce.

w.

do góry

Zrobiłem sobie testowe repozytorium prywatne na bitbucket'cie i trenuję. Właściwie
wszystko rozumiem poza pull requestami: kiedy i dlaczego docelowa gałąź miała by być
inna niż źródłowa? Byłbym wdzięczny za wytłumaczenie.

do góry

W dniu piątek, 2 grudnia 2016 15:34:58 UTC+1 użytkownik j...@p...onet.pl
napisał:
> Zrobiłem sobie testowe repozytorium prywatne na bitbucket'cie i trenuję. Właściwie
wszystko rozumiem poza pull requestami: kiedy i dlaczego docelowa gałąź miała by być
inna niż źródłowa? Byłbym wdzięczny za wytłumaczenie.

Pull requesty to mechanizm używany w pracy zespołowej. Możemy sobie
wyobrazić, że jest na przykład jedna osoba będąca opiekunem repozytorium,
która sama nie pisze kodu, ale która jest odpowiedzialna za scalanie
kodu pisanego przez inne osoby. (W takiej sytuacji np. przez długi czas
był Linus Torvalds, który otrzymywał pacze od różnych osób)

Załóżmy, że przez jakiś czas pracowałeś na swoim branchu nad jakąś
funkcjonalnością, i uznajesz ją za skończoną. Wówczas tworzysz pull
requesta (lepszą nazwą byłby chyba "merge request") będącego sugestią
scalenia Twoich zmian do głównej gałęzi rozwojowej (i ewentualnego
ich wydania w oficjalnej wersji). Opiekun repozytorium (i inne osoby
zaangażowane w projekt) mogą przejrzeć zmiany i skomentować je
przy pomocy narzędzi udostępnianych przez githuba albo bitbuckta.

Wówczas możesz uwzględnić ich komentarze i poprawić na swojej gałęzi
różne rzeczy, do których się przyczepili. Kiedy nie będą mieli już
żadnych uwag i zaaprobują Twoje zmiany, opiekun repozytorium będzie
mógł dokonać scalenia pull-requesta.

do góry