5 pomysłów na ulepszony przepływ pracy GitHub
W zależności od Twojej historii z działającą kontrolą źródła, sposób, w jaki pracujesz z bazą kodu, robisz zatwierdzenia itp., jest różny.
Co więcej, w zależności od tego, czy używasz Git, Subversion, Mercurial, itd., dyktuje również sposób zarządzania kodem.
Ale jeśli jesteś kimś, kto pracuje z Git (z którego wiem, że wiele osób korzystających z WordPressa zaczyna używać coraz częściej prawie codziennie), zalecam kilka drobiazgów, aby pomóc w zarządzaniu zmianami, zwłaszcza w zespole łatwiejsze w zarządzaniu.
Wskazówki dotyczące ulepszonego przepływu pracy GitHub
1 Nie zobowiązuj się do opanowania
Master powinien być używany specjalnie dla kodu gotowego do produkcji i wdrożenia. To nie twoja gałąź pracy, to nie twoja gałąź pracy.
Ogólnie rzecz biorąc, w tym miejscu wszystkie żądania ściągnięcia są scalane.
2 Staraj się zawsze tworzyć gałęzie
Zawsze, gdy masz zbiór zadań, problemów lub kamieni milowych, utwórz gałąź i upewnij się, że wszystko, nad czym pracujesz, jest ze sobą powiązane. Na przykład nie chcesz wykonywać pracy z bazą danych i JavaScript w swoich żądaniach ściągnięcia.
3 partiami swoją pracę
Nawet jeśli pracujesz wyłącznie nad pracą front-endową, być może będziesz musiał podzielić to na mniejsze gałęzie. To ułatwia przeglądanie kodu i lepsze żądania ściągnięcia.
4 Generuj małe PR
Jest to bardzo podobne do poprzedniego nagłówka, ale pomysł tworzenia małych PR jest znacznie bardziej produktywny niż tworzenie dłuższych żądań ściągnięcia.
- Pomaga to, gdy musisz poprosić o sprawdzenie kodu, ponieważ zapewnia to kolegom z zespołu łatwiejszy sposób obsługi recenzji kodu i oferowania opinii.
- Utrzymuje dziennik zmian i pomaga w tworzeniu szczegółowego raportu na temat tego, co robi konkretna partia kodu.
Ale na czym polega dobry PR?
5 Podaj dobre szczegóły w swoim PR
Jeśli o mnie chodzi, dobry pull request zrobi mały zestaw rzeczy:
- Opisz, w zdaniu lub dwóch, czego osoba przeglądająca Twoje zmiany powinna się spodziewać.
- Połącz PR z biletem, kartą zarządzania projektem (lub jakkolwiek to nazywają w twoim systemie),
- Wymień krótsze wersje komunikatów o zatwierdzeniu, aby ułatwić recenzentowi jak to tylko możliwe.
To powiedziawszy, prawdopodobnie jest więcej rzeczy, które możesz zrobić, ale to są rzeczy, które uważam za najbardziej przydatne (i byłbym zremisowany, gdybym powiedział, że nie nauczyłem się niektórych z tych rzeczy od mojego zespołu ).
Czy jest więcej rzeczy?
Zawsze.
Ale to garść rzeczy, które okazały się coraz bardziej przydatne, szczególnie podczas śledzenia zmian, pracy z innymi i obsługi pull requestów (zarówno tych, z którymi pracuję, jak i tych, którzy współtworzą projekty open source).
Wreszcie żadna z tych rzeczy nie ma charakteru nakazowego. Istnieje krzywa uczenia się (mówiąc z doświadczenia), ale polecam wypróbowanie kilku z nich, jeśli nie z innego powodu niż sprawdzenie, czy nie poprawia to przepływu pracy.
Nawet jeśli to tylko trochę.