Ustawy-o-PIT
Ustawy-o-PIT copied to clipboard
ProjektyUstaw
Gitflow
Hej, co myślicie o dodaniu prostego Gitflow do łatwiejszego wersjonowania repozytorium? Moja propozycja, to dodanie gałęzi 'develop', do której będą wrzucane pull requesty. Dopiero po odpowiedniej walidacji 'develop' będzie mergowany do 'main'. Dzięki temu nie będzie tysiąca wersji głównej gałęzi, a pojedyncze większe zmiany będą prowadziły do v1.1, v1.2 itd.
Korzystając z terminala (np. Git Bash) będą to następujące komendy:
- cd Ustawy-o-PIT\ (jeżeli nie znajdujemy się jeszcze w folderze repozytorium)
- git checkout -b "develop" (znajdując się na gałęzi main, git checkout tworzy jej kopię nadając nową nazwę "develop")
- git push
Git push może wypluć: "fatal: The current branch develop has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin develop",
ale wtedy wpisujemy:
- git push --set-upstream origin develop
I gałąź develop powinna być widoczna w repozytorium.
Ja jestem za ale mam jedno ale 😄 Na razie nie wiemy w jaki sposób i czy w ogóle projekt będzie utrzymywany przez społeczność i twórców. Moim zdaniem na samiutkim początku nie ma to sensu, dopiero wraz z dojrzewaniem projektu będziemy wiedzieli czego się spodziewać i czy faktycznie przyniesie to jakieś zalety. Zdaję sobie sprawę że jest to standard w większości projektów, aczkolwiek najpierw zastanowiłbym się czy jest taka potrzeba, a dopiero gdy okaże się że faktycznie zmian będzie odpowiednio dużo albo np. będą planowane release'y z określonymi taskami do zrobienia. Na ten moment wstrzymałbym się z tym pomysłem na jakiś czas np. 1-2 tygodnie żeby zobaczyć jak projekt jest prowadzony przez twórców i społeczność. Może się równie dobrze okazać że projekt "umrze" (oby nie) za jakiś czas i wprowadzi to komplikacje co sprawi że próg wejścia dla osób nie będących zaznajomionych z gitem wzrośnie.
Precz z branchami, utrudni to pracę osobom nietechnicznym. Tylko Continuous Integration, nie jakieś pseudo CI ;) Wystarczy możliwość tagowania konkretnych commitów, a tagowanie generowałoby wydanie. Nowsze commity od ostatniego taga mogłyby być traktowane jako wersja rozwojowa. Pomoże w tym wszystkim mkdocs + mike, bo da ładnie dostęp do każdego wygenerowanego wydania i aktualnie rozwijanej wersji ustaw.
Podaję przykładową nawigację w dokumentacji mkdocs + material + mike, którą tworzyłem dla projektu technicznego:
Górna belka, wybierak wersji, link do repozytorium, link do dokumentu w PDFie:
Przykładowe wersje wygenerowane na podstawie tagów:
Widok różnych wersji dokumentu w PDFie:
Każda strona ma bezpośredni link do pliku markdown, z którego wygenerowano daną stronę:
Wiadomo kto i kiedy wprowadzał zmiany na stronie:
Wszystkie wygenerowane wersje są wersjonowane w dedykowananej gałęzi gh-pages (jest to konfigurowalne) i są zarządzane przez mike'a — tu nic nie zmieniamy we własnym zakresie.
Raczej należy stworzyć aplikacjhe internetową, gitującą . Odpowiedni interfejs powinnien być intuicyjny - nie wierzę, że każdy będzie uczył suię gita, żeby napisać posta na forum ... Bo dla przeciętnego człowieka git to forum z laserami i tyle.
@Heuristics-Adhoc Co masz na myśli aplikacje gitującą? Masz jakąś dokumentację tego co chciałbyś osiągnąć i jakie problemy rozwiązać?
Zapewne chodzi o jakieś narzędzie bardziej w formie wiki, ale oprate o Git, gdzie można dodawać uwagi, zgłaszać issue robić PRki do tekstu, czyli taki github ale zorientowany na wspóle pisanie tekstu a nie programów i najlepiej wszystko w przeglądarce. Chyba nie ma czegoś takiego, a najbliżej jest: https://www.gitbook.com/
Zapewne chodzi o jakieś narzędzie bardziej w formie wiki, ale oparte o Git, gdzie można dodawać uwagi, zgłaszać issue robić PR-ki do tekstu, czyli taki github ale zorientowany na wspólne pisanie tekstu a nie programów i najlepiej wszystko w przeglądarce. Chyba nie ma czegoś takiego, a najbliżej jest: https://www.gitbook.com/
Tak, najlepiej, żeby była możliwość pisania pluginów - będzie można wdrażać różne sposoby opracowywania konkretnych ustaw. Właśnie poleconyprzez Ciebi gitbook ma taką możliwość
Znacie wikikrację ? Tam też jest ciekawe rozwiązanie, gdzie można trochę przesiać kontrybutorów - tam są społeczności, do których wejście jest głosowane. Społeczności można wykorzystać jako kolegiaty do dopieszczania ustaw ale to później.
Uważam, że potrzebujemy porządku w dyskusjach bo już jest 62 issues a to dopiero początek. Należy już myśleć nad organizacją.
Osobiście proponowałbym, żeby rozpocząć kilka dyskusji, dopracować pomysły, a następnie złożyć sugestię właścicielowi - on wszystkiego nie ogarnie, a jest ryzyko, że jak nie zajmiemy się konkretami, to zgubimy logikę tego przedsięwzięcia.
Rzeczywistość pokazała, że nie masz aż tylu PRów, żeby komplikować proces dodatkowymi branchami. Śmiało róbcie PRy do maina.
Co do tagowania: numerki wersji można podbijać w opisie commita przy pomocy #major i #minor.
Dziękujemy za sugestie i propozycje!
