Jakich przewodników lub standardów używasz do kontroli wersji w zespole?

Question

Zaczynam robić niewielki rozwój w mojej firmie. Zamierzam użyć Git do kontroli wersji i chciałbym zobaczyć, jakie wytyczne lub standardy używają ludzie w stosunku do wersji w swoich grupach, podobnie jak standardy kodowania są często zapisywane w grupie dla grupy.

Zakładam, że będą takie rzeczy;

• Commit często (przynajmniej raz na dzień/tydzień/spotkanie itp)
• Release kompilacje są zawsze wykonane z gałęzi głównej
• przed zwolnieniem, nowy oddział zostanie utworzony Badań i oznaczone jako takie . tylko poprawki błędów od tego momentu. Ostateczna wersja tego będą oznaczone jako takie i poprawki połączone z powrotem do bagażnika
• Każdy deweloper będzie miał repo publicznego
• Nowe funkcje powinny się ich własny oddział

Oczywiście dużo tego będzie zależeć od tego, z jakiego VCS korzystasz i jak go zbudowałeś.

Podobne pytania;
git branch naming best practices
Is there a standard naming convention for git tags?

Answer 1

W obecnym miejscu, w którym pracuję, system kontroli wersji jest jednym z najbardziej zaawansowanych i dojrzałych. To jest jak to robimy.

Mamy coś nazywanego "główną" gałęzią, która jest bazą kodu, która będzie w produkcji. Uwaga, podstawa kodu w jednej, ogromnej, gigantycznej strukturze. Powiedz, że jeśli nadejdzie nowy projekt, będziemy musieli ustalić jego zakres i zarezerwować tydzień wydania. Teraz musimy zacząć nad tym pracować. Więc wycinamy gałąź z głównej gałęzi nazywanej gałęzią cech. Zespół lub grupa deweloperów nadal pracuje w tej konkretnej branży. Zauważ, że będzie wiele cięć w gałęziach jednocześnie z głównego oddziału.

Teraz, gdy rozwój już się skończył, aby połączyć kod z powrotem do głównego. Nie zrobimy tego bezpośrednio, ponieważ może spowodować spustoszenie z powodu oczywistych problemów krytycznych. Mamy więc jeszcze jedną gałąź wyciętą z głównej pre-release. Łączymy cały nasz kod z bazą wydań. I wykonaj kompilację na pełnej bazie kodu. Kompilacja powinna przejść. Kiedy to zrobi, wyodrębniamy zielony znacznik czasu (ostatnia aktualizacja). Po otrzymaniu zielonego znacznika czasu kod zostanie scalony z gałęzi przed wydaniem do głównej, a wydanie zostanie sfinalizowane.

Po wprowadzeniu kodu do produkcji i powiedzmy, że mamy do czynienia z kilkoma błędami, wycinamy gałąź z głównej gałęzi nazwanej jako gałąź naprawiająca błędy. Wykonaj wszystkie zmiany. I połączenie go z powrotem; zawsze postępuje zgodnie z procesem pre-release/green timestamp. To nieuniknione.

Ponowna baza. Ok, więc początkowo powiedziałem, że zarezerwowalibyśmy, gdy nasz oddział funkcji zostanie ukończony. W tym czasie na głównej stronie pojawi się wiele aktualizacji kodu. Jest więc bardzo potrzebne, abyś aktualizował swoją bieżącą gałąź funkcji, aby była zsynchronizowana z główną. W tym celu jest wykonywany proces zwany jako rebase. To tak, jak pobranie najnowszego kodu z głównego, tak, że nie pracujesz w gałęzi, która jest tak przestarzała.W moich bieżących organizacjach baza będzie uruchamiana co 2-3 tygodnie, chociaż zasady zalecają 1 tydzień.

Bardziej interesujące funkcje: Załóżmy, że obecnie pracuję nad tak zwanym działem funkcji i chcę uzyskać kod od jednego z pozostałych zespołów, które również pracują we własnej gałęzi funkcji (ten scenariusz, choć zdarza się często, rzadko się zdarza) . W tym celu zmienimy naszą konfigurację (ClearCase jest naszym systemem kontroli wersji), aby wskazywać te pliki wymagane z innego projektu. Można użyć parametru NAJNOWSZY lub można określić TIMESTAMP w celu wyodrębnienia plików pochodzących z innej gałęzi operacji.

Po upływie pewnego czasu od rozpoczęcia projektu odcięta gałąź funkcji nie jest potrzebna. Można go usunąć z systemu, powiedzmy po latach, że przestrzeń powinna być ograniczeniem.

Answer 2

Tylko jeden standard:

1. Sprawdzanie zmiany zerwania spowoduje kopanie.

Answer 3

Mój "cvs" to TFS, więc weź go za to, co jest warte.

Jeśli ktoś łamie build, reguła dotyczy pączka (przynosi pudełko pączek następny dzień)

Wspomniałeś popełnienia często opiera się na dzień, tydzień lub spotkania. Czy ten system nie wprowadziłby niekompletnego kodu? Po zatwierdzeniu kodu może być bardziej stabilne zatwierdzenie.

Rozpoczęcie testów jednostkowych byłoby dobrą praktyką, ponieważ jest tak, jakby mieć drugi zespół ds. Kontroli jakości pracujący w ciągu nocy (gdy te testy jednostkowe działają jako część składanki nocnej).

Jeśli chodzi o posiadanie oddziału na obiekt, to nie jest to coś, czego użyłem, ale coś, o czym rozmawialiśmy, gdy ktoś zepsuł kompilację, ponieważ jeśli jeden zespół złamał jakąś funkcję, reszta rzeczy wciąż była budowana. Aby to działało, program instalacyjny musi być wystarczająco elastyczny, aby można go było zainstalować i móc go wdrożyć, nawet jeśli brakuje opcjonalnych funkcji.

Budowanie według takich funkcji może zwiększyć produktywność, ponieważ kontrola jakości może rozpocząć testowanie już następnego dnia, zamiast być blokowana przez uszkodzoną kompilację, dopóki nie zostanie naprawiona później po południu, lub nawet odepchnie następną, aby zobaczyć inny podobny problem.

CVS jest dobrze znana, ale jeśli będę rozpoczynając Development Team/projektu, mogę rozważyć zaglądając do Jira Studio

http://www.youtube.com/watch?v=2w2uN3c8pfA http://www.youtube.com/watch?v=c9pm_r8vSwM&feature=related

Answer 4

Gdy masz swój główny oddział, każde zadanie lub funkcja, nad którą chcesz pracować, powinna być rozwijana we własnym oddziale. Staraj się, aby gałąź główna była stabilna, a produkcja zawsze gotowa. Ilekroć masz zadanie, rozwidnij gałąź, wykonaj tam swoją pracę, napraw błędy, a następnie wróć do master.

Nie trzeba przeprowadzać odprawy dziennie (ani żadnej innej jednostki czasu). Zawsze przeprowadzamy nasze odprawy w oparciu o uzupełnianie funkcji, niekoniecznie kompletny zestaw funkcji, ale w małych logicznych porcjach. Pozwala nam to łatwiej znajdować błędy niż codzienne sprawdzanie całego kodu, niezależnie od tego, czy jest ono powiązane, czy nie.

Zachowaj wyraźne komunikaty dotyczące zatwierdzeń i do rzeczy, to pomoże ci ogromnie, gdy ponownie włączysz swój kod.

Małe gówno z git, kiedy widelec jest rozgałęziony, jest rozgałęziony z gałęzi, w której aktualnie się znajdujesz, a nie od mistrza. Jest to oczywiste, ale zawsze sprawdź dokładnie swoją obecną gałąź, zanim rozwiniesz nowy oddział.

Użyj.Plik gitignore do przechowywania plików, których nie chcesz śledzić w kontroli wersji, zamiast zaśmiecać komunikaty o stanie git lub nadpisywać plik, który nie powinien być w kontroli wersji (w pierwszej kolejności) (konfiguracja DB i inne)

Answer 5

Tylko kontrola w (lub promuj, w zależności od narzędzia) działający kod do "głównej" gałęzi/strumienia/magazynu/repozytorium (wybierz własną definicję "głównego"). Ta "główna" gałąź powinna pozostać kompilowana i testowalna przez cały czas.