[kiler129]

Mireczki z #programowanie używajace #github, mam do was pytanie.
Mamy sobie repozytorium z projektem, nagle odnajdujemy błąd. Aby nie zapomnieć robimy issue do którego po jakimś czasie wracamy. Wypadałoby zrobić brancha dla tego issue i tam na nim pracować - problem w tym, że nie widzę takiej opcji.
Co prawda znalazłem w internecie sposób konwersji issue na pull-request, ale github krzyczy, że ta metoda jest przestarzałą i zostanie usunięta ( ͡° ʖ̯ ͡°) Nie ma również takiej opcji na www więc chyba nie jest to polecany system pracy.

Jakieś rady, jak powinno to wyglądać?

[jaen]

Bierzesz miejsce od którego chcesz naprawiać, branchujesz po prostu, naprawiasz, pushujesz. Żadnego więcej rocket science.
W sensie po prostu:

git checkout tam-gdzie-jest-bug
git checkout -b fix/naprawiam-buga
...

[legolass]

@kiler129: W projektach do których commitowałem działa to tak:
1. Forkujesz repo (jeśli to Twój projekt to nie musisz)
2. Tworzysz sobie brancha do tego issue
3. Naprawiasz błąd
4. Robisz push tego brancha na githuba
5. Tworzysz pull-request do tego zadania (z informacją że naprawia issue #ilestam)
6. Jeśli jest ok pull-request jest mergowany i issue zamykane

[frax]

iszułem

@jaen: <3

@kiler129: W czym konkretnie jest problem? W tym, jak stworzyć branch i pull request, czy jak je powiązać z issue? Żeby powiązać z issue pull request, wystarczy chyba gdzieś w opisie napisać #.

[kiler129]

@jaen: Tyle to ja wiem, ale chodziło mi właśnie aby w samym issue mieć work-log bez robienia issue + pr.

@legolass: Tylko z tego co rozumiem zostaje wtedy issue + pullrequest - trochę to głupie moim zdaniem, a robienie od razu PRa na pusty branch po to aby opisać problem też trochę mało eleganckie.

W pracy używamy JIRA + Stash i tam po prostu przy każdym issue można

[jaen]

@kiler129: no jeżeli zrobisz np. zrobisz merge commit i w nim dasz ten hasztag + numer iszuła to się powinien na stronie iszuła wyświetlić. Tylko będzie to jeden commit, a nei wszystkie, jak PRze, z tego co pamiętam. Lepiej chyba się nie da, ale ja osobiście nie widzę nic złego w zrobieniu i iszuła i PRa.
Kiedyś wysłałem tylko PRa do kioo i maintainer olał, a jak wysłałem iszuła i

[frax]

@kiler129: Nie wiem, jak to dokładnie działa na githubie, ale przypuszczam, że podobnie do bitbucketa, gdzie:

- wpisanie refs # powoduje dodanie komentarza do issue z hashem commita po pushu (nie używam, bo po kilku rebase'ach potrafi się zrobić straszny syf)
- wpisanie fixes # albo resolves # powoduje zamknięcie issue od razu po pushu, niezależnie od zmergowania/niezmergowania - dobre do wpisania w commitmessage przy mergu
- wpisanie # gdzieś w opisie PRa

[MacDada]

@kiler129:

1. Robisz issue na ktos/repo, że coś jest do kitu
2. Forkujesz ktos/repo na ja/repo
3. Klonujesz na kompa ja/repo
4. Robisz

[MacDada]

@kiler129: Ten flow jest słuszny, bo:

* Issue opisuje problem, pełne informacje co nie działa, co chcemy, żeby działało, etc.
* PRy są proponowanymi rozwiązaniami tego problemu – nie opisujesz co źle działa, ale jak to poprawiłeś
* PRów może być kilka (i od różnych osób)
* Wszystkie te informacje są ze sobą powiązane jak dajesz #numerek

[kiler129]

@frax: Podobnie linkuje, co do automatycznego zamykania to nie testowałem.

@MacDada: O, o taką odpowiedź mi chodziło - dzięki wielkie za wyjaśnienie całości. Choć piszę od ładnych kilku lat GitHubem bawię się od niezbyt dawna (a szkoda, dużo fajnego kodu przepadło) ( ͡° ͜ʖ ͡°)