Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #28716 > unrolled thread

pytanie z gita

Back to article view | Back to pl.comp.programming

Contents

  pytanie z gita Jivanmukta <jivanmukta@poczta.onet.pl> - 2016-09-12 15:42 +0200
    Re: pytanie z gita Robert Winkler <noone@nowhere.org> - 2016-09-12 15:51 +0200
    Re: pytanie z gita Wojciech Muła <wojtek.mula@gmail.com> - 2016-09-17 21:55 -0700
      Re: pytanie z gita jivanmukta@poczta.onet.pl - 2016-10-10 08:03 -0700
        Re: pytanie z gita Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-11 05:50 -0700
          Re: pytanie z gita Jivanmukta <jivanmukta@poczta.onet.pl> - 2016-10-12 15:32 +0200
    Re: pytanie z gita jivanmukta@poczta.onet.pl - 2016-10-28 07:53 -0700
      Re: pytanie z gita Wojciech Muła <wojtek.mula@gmail.com> - 2016-11-02 00:42 -0700
        Re: pytanie z gita jivanmukta@poczta.onet.pl - 2016-12-02 06:34 -0800
          Re: pytanie z gita godek.maciek@gmail.com - 2016-12-03 02:35 -0800
            Re: pytanie z gita Jivanmukta <jivanmukta@poczta.onet.pl> - 2016-12-09 19:32 +0100
              Re: pytanie z gita godek.maciek@gmail.com - 2016-12-09 10:45 -0800

#28716 — pytanie z gita

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.

[toc] | [next] | [standalone]

#28717

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-model/

--
Robert

[toc] | [prev] | [next] | [standalone]

#28766

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.

[toc] | [prev] | [next] | [standalone]

#29080

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

[toc] | [prev] | [next] | [standalone]

#29081

> 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

[toc] | [prev] | [next] | [standalone]

#29091

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

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

[toc] | [prev] | [next] | [standalone]

#29212

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?

[toc] | [prev] | [next] | [standalone]

#29242

On Friday, October 28, 2016 at 4:53:29 PM UTC+2, jivan...@poczta.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.

[toc] | [prev] | [next] | [standalone]

#29265

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.

[toc] | [prev] | [next] | [standalone]

#29268

W dniu piątek, 2 grudnia 2016 15:34:58 UTC+1 użytkownik jivan...@poczta.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.

[toc] | [prev] | [next] | [standalone]

#29269

Przeczytałem. Dzięki za odpowiedź.
Nie rozumiem dlaczego pull request jest adresowany do konkretnej osoby i 
dlaczego gałąź docelowa i źródłowa mogą być różne. Możesz mi to wytłumaczyć?

[toc] | [prev] | [next] | [standalone]

#29270

W dniu piątek, 9 grudnia 2016 19:32:50 UTC+1 użytkownik Jivanmukta napisał:
> Przeczytałem. Dzięki za odpowiedź.
> Nie rozumiem dlaczego pull request jest adresowany do konkretnej osoby i 
> dlaczego gałąź docelowa i źródłowa mogą być różne. Możesz mi to wytłumaczyć?

Z tego co wiem, na bitbuckecie PR nie jest adresowany do jednej konkretnej
osoby, tylko do całego zbioru osób (w szczególności może być pusty
albo jednoelementowy), które w tym kontekście nazywają się recenzentami,
co wynika stąd, że ich rolą (oprócz ewentualnego scalenia) jest zgłoszenie
swoich uwag odnośnie Twojego kodu.

To, jakie to będą osoby, zależy od struktury organizacyjnej w projekcie.
Jeżeli jakaś osoba w zespole zleciła Ci te zmiany, zapewne będziesz chcieć,
żeby to ona przejrzała te zmiany. Jeżeli inna osoba jest odpowiedzialna
za scalanie, również ona powinna zostać poinformowana o pull requeście.

Gałąź źródłowa i docelowa oczywiście powinny być różne, bo źródłowa
to jest zapewne jakiś Twój feature-branch, zawierający owoce
Twojej pracy, a docelowa to oficjalna gałąź, z której wydawane będą release'y.

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web