Wpis z mikrobloga

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ć?
  • 9
Bierzesz miejsce od którego chcesz naprawiać, #!$%@? po prostu, naprawiasz, #!$%@?. Żadnego więcej rocket science.
W sensie po prostu:

git checkout tam-gdzie-jest-bug
git checkout -b fix/naprawiam-buga
...
git add -A
git commit -m 'Naprawilem buga #12'
git push origin fix/naprawiam-buga

Potem robiusz w UI Githuba PR dla tego brancha i jesteś zadowolony. Jeżeli chcesz to możesz w commicie użyć #numer-issue-lub-pr (tak jak tam wyżej zrobiłem), żeby dany commit został powiązany
@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
@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 dodać sobie
@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 PRa
@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
@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 nowego brancha poprawka
5. Pracujesz na poprawka, commitujesz zmiany
6. Dodajesz ktos/repo jako upstream
7. Rebase'ujesz poprawka względem upstream, bo może coś doszło i będą konflikty (oraz, żeby zapoznać się ze zmianami i uliniowić historię)
8. Push poprawka do ja/repo
9. Pull Request ja/repo/poprawka do
@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 dzięki Githubowi
* Właściciel repo może bezproblemowo odrzucić rozwiązanie (odrzucić PRa), a zachować opis
@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) ( ͡° ͜ʖ ͡°)