Jak mam kontrolować wersje mojego projektu na GitHub

Staram się spędzać tyle czasu, ile tylko mogę na GitHub obecnie (nawet ja jestem jedyną osobą w zespole w pracy) , aby naprawdę poczuć, jak to będzie jak dla aplikacji korporacyjnych świata rzeczywistego.

Jedno z moich pytań dotyczy kontroli wersji . Powiedzmy, że rozpoczęliśmy projekt. Następnie członkowie zespołu utworzyli niektóre oddziały i tam się rozwijają. Kiedy jesteśmy gotowi do produkcji, połączyliśmy wszystkie oddziały z masteroddziałem. Na koniec udostępniamy wersję 1.0.

Ta wersja 1.0jest już dostępna i mamy zgłoszone problemy dotyczące tej wersji tego oprogramowania. Chcielibyśmy zacząć opracowywać wersję 1.1, aby naprawić problemy, które wprowadziliśmy, przyspieszając projekt.

Teraz pytanie brzmi:

Jak powinniśmy tutaj kontrolować wersjonowanie?

Czy powinniśmy stworzyć nową gałąź v1.0i zachować tam wersję 1.0oprogramowania i rozwijać się w niektórych gałęziach (lub nie), połączyć je z master, uruchomić z wersją 1.1?

Czy istnieje konwencja dla takich sytuacji?

— tugberk
źródło

Odpowiedzi:

Znalazłem (i zacząłem adoptować) następujący model gałęzi :

Zdjęcie z nvie.com

^{(zdjęcie z artykułu)}

Istnieje wiele świetnych praktyk i ścisłych zasad opisanych w tym artykule, bardzo go polecam.

Punkty zainteresowania:

Główny oddział to miejsce, w którym oznaczasz swoje wersje. Tutaj nie dzieje się żaden rozwój. W przypadku błędu, który został wdrożony w wersji produkcyjnej, naprawiasz błąd w gałęzi poprawki, łączysz ponownie i otagujesz nową wersję.
Rozwój odbywa się w gałęzi rozwijania i funkcji. Osobiście naprawiam błędy w gałęzi devel i funkcje w gałęziach funkcji.
Kiedy oprogramowanie zaczyna docierać do wydania, rozgałęziam się, aby wydać oddział. Gałąź wydania to miejsce, gdzie dokonuję ostatnich poprawek. Podbij numery wersji, zmień metadane itp. I drobne poprawki błędów. Po zakończeniu scalam go, aby opanować, oznaczyć i nazwać wersją.
Dwie główne gałęzie: mistrz to „święta gałąź”; HEAD jest zawsze najnowszym kodem produkcyjnym, a programowanie to gałąź nocna; jego HEAD zawsze odzwierciedla najnowsze (ale możliwe niestabilne) dodatki do kodu.

W twoim konkretnym przypadku kroki będą zależeć od tego, jak szybko ta wersja została rzucona. Jeśli pominięto funkcje, wróciłbym do wersji dla programistów i zrobiłbym to wszystko jeszcze raz. Jeśli są to błędy we wdrożonej wersji, rozgałęzię się do gałęzi poprawki, naprawię błędy, scalę z powrotem i oznaczę v1.1. Jeśli jest to jedno i drugie, najpierw naprawię błędy, a następnie dodam funkcje zgodnie z opisem.

— Tamás Szelei
źródło

Bardzo pouczające i szczegółowe. A także idealna praktyka. Ma to również sens. Posiadanie mistrza dla produ ułatwia jedynie utrzymanie. Nie znam tagowania gałęzi (lub zatwierdzenia?). Czy możesz podać mi kilka szczegółów na ten temat? jak możemy to zrobić zgodnie z powyższym modelem?

— tugberk

W git celem tagowania jest zatwierdzenie. Oznacza to, że mówisz: „oto ten zatwierdzenie i od tej pory nazywam go„ v1.3 ”. W praktyce oznacza to przejście do gałęzi master, scalenie w (teraz stabilnej) gałęzi devel, zatwierdzenie i tagowanie. Następnie możesz wymienić wszystkie tagi, powrócić do tego kodu na wypadek, gdybyś chciał zobaczyć, co weszło do produkcji w poprzedniej wersji. Znaczniki mają nieco więcej (jest to przydatne w przypadku rozproszonego programowania na dużą skalę, takiego jak jądro Linuksa). Jeśli jesteś zainteresowany, sugeruję książkę progit .

— Tamás Szelei

ProGit to jedna z książek, które na pewno przeczytam od zera. Na razie czytam tylko te części, które mnie interesują, aby wykonać zadanie. Do tej pory rozwijaliśmy się w gałęzi master i myślę, że powinienem to utrzymać. Ale otworzę kolejną gałąź o nazwie productioni użyję jej jako mastergałęzi zgodnie z powyższym modelem.

— tugberk

podczas wypróbowania tego modelu, walczę o jedno: istnieją pewne gałęzie wspierające omówione w tym artykule, gałęzie funkcji i wydania. może istnieć wiele przyszłych oddziałów. Na przykład FeedbackForm to jeden przyszły oddział, a ContactForm to kolejny. Zgadza się z tym modelem? Czy powinny istnieć również liczne gałęzie wydania? a jeśli tak, to jak mam je nazwać?

— tugberk

Przede wszystkim nie musisz podążać za tym listem, po prostu ustal zasady, których będziesz przestrzegać. Rób, co najlepsze dla ciebie i stylu swojego zespołu. Po drugie, tak, wiele gałęzi funkcji i wersji jest normalnych, chyba że masz krótkotrwały projekt z jedną funkcją i jedną wersją :). Nazywanie, zgodnie z artykułem to release- * i feature- *. Wydaje mi się, że umieścisz przyszły numer wersji w miejscu gwiazdki dla wydania, a identyfikator śledzenia problemów w przypadku gałęzi funkcji.

— Tamás Szelei

Przez większość czasu byłem świadkiem:

Master jest dla Ciebie produktem. Ostatecznie cała twoja przyszła wersja x.0 będzie na masterie.
Tworzysz znacznik / gałąź dla każdej wersji produkcyjnej, aby nadal móc je obsługiwać dla każdego wymagającego klienta.
Łączenie poprawek z jednego lub drugiego ma dotyczyć poszczególnych przypadków.

— xsace
źródło

dzięki! więc uważasz, że rozsądnie jest mieć oddział o nazwie v1.0, v1.2 jest uzasadnione?

— tugberk

@tugberk, dopóki odpowiednie oprogramowanie istnieje w tej wersji, sensowne jest utrzymywanie gałęzi w pobliżu, abyś mógł je szybko rozwidlić, jeśli potrzebujesz konkretnej gałęzi poprawki. Jeśli oprogramowanie już nie istnieje w tej wersji (nie jest już obsługiwane, więc nie można już więcej pracować), warto wykonać ostateczne scalenie gałęzi, a następnie usunąć je. Możesz nawet utworzyć ostatnie puste zatwierdzenie (robię to często na początku gałęzi), żeby powiedzieć „Zamykanie gałęzi XXXX”, w przeciwnym razie nie będziesz przechowywać historii gałęzi (reflog może trochę pomóc, ale jest to dla repozytorium)

— Patrick Mevzek,