Buduj sekwencjonowanie podczas korzystania z rozproszonej kontroli wersji

W tej chwili używamy Perforce do kontroli wersji. Ma przydatną funkcję ściśle rosnącej liczby zmian, której możemy użyć, aby odnieść się do kompilacji, np. „Dostaniesz poprawkę, jeśli twoja kompilacja ma co najmniej 44902”.

Chciałbym przełączyć się na korzystanie z systemu rozproszonego (prawdopodobnie git), aby ułatwić rozgałęzianie się i pracę z domu. (Oba są całkowicie możliwe w Perforce, ale przepływ pracy git ma pewne zalety). Chociaż „rozwój dopływu” byłby rozpowszechniany i nie odnosi się do wspólnego sekwencjonowania wersji, nadal utrzymywalibyśmy główne repozytorium git, które wszystkie zmiany trzeba się wtrącić przed utworzeniem kompilacji.

Jaki jest najlepszy sposób zachowania ściśle rosnących identyfikatorów kompilacji? Najprostszym sposobem, jaki mogę sobie wyobrazić, jest posiadanie pewnego rodzaju haka post-commit, który odpala za każdym razem, gdy master repo zostaje zaktualizowany, i rejestruje (skrót) nowego obiektu drzewa (lub zatwierdza obiekt? git) ze scentralizowaną bazą danych, która rozdaje identyfikatory. (Mówię „baza danych”, ale prawdopodobnie robię to za pomocą znaczników git i po prostu szukam następnego dostępnego numeru znacznika lub czegoś takiego. Tak więc „baza danych” to naprawdę .git / refs / tags / build-id /. )

Jest to wykonalne, ale zastanawiam się, czy istnieje łatwiejszy lub już wdrożony lub standardowy / „najlepszy sposób postępowania” sposób osiągnięcia tego.

questionAnswers(8)

yourAnswerToTheQuestion