Używamy SVN w pracy, ale do moich osobistych projektów zdecydowałem się użyć Git. Więc zainstalowałem Git wczoraj i zastanawiam się, jaki jest odpowiednik numeru wersji w Git .
Załóżmy, że pracujemy nad wersją 3.0.8, a każda poprawka błędu ma swój własny numer wersji, którego możemy użyć, gdy mówimy o tej poprawce. Więc jeśli otaguję kod w Git do 3.0.8, co wtedy mogę użyć jako numeru wersji lub innego bardziej szczegółowego rodzaju identyfikacji? Uważam, że skrót nie jest tak przyjazny dla ludzi.
Odpowiedzi:
Dobra lub zła wiadomość dla Ciebie, że skrót to numer wersji. Miałem też z tym problem, kiedy przestawiłem się z SVN na git.
Możesz użyć „tagowania” w git, aby oznaczyć określoną wersję jako „wydanie” dla konkretnej wersji, dzięki czemu można łatwo odnieść się do tej wersji. Sprawdź ten post na blogu .
Kluczową rzeczą do zrozumienia jest to, że git nie może mieć numerów wersji - pomyśl o zdecentralizowanej naturze. Jeśli użytkownicy A i B zobowiązują się do swoich lokalnych repozytoriów, w jaki sposób git może rozsądnie przypisać sekwencyjny numer rewizji? A nie ma wiedzy o B, zanim nie popchną / nie pociągną za siebie zmian.
Inną rzeczą, na którą warto zwrócić uwagę, jest uproszczone rozgałęzianie gałęzi z poprawkami:
Zacznij od wydania: 3.0.8. Następnie po wydaniu wykonaj następujące czynności:
Spowoduje to utworzenie gałęzi dla poprawek błędów. Kasa w oddziale:
Teraz wprowadź zmiany, które chcesz naprawić.
Zatwierdź je i wróć do głównej gałęzi:
Następnie pobierz te zmiany z drugiej gałęzi:
W ten sposób masz osobną gałąź poprawek błędów dla poszczególnych wydań, ale wciąż przenosisz zmiany do głównego pnia programistów.
źródło
fixed in 547cc3e..c4b2eba
, a masz inną wersję, nie masz pojęcia, czy Twój kod powinien zawierać poprawkę ?! Z pewnością gity w git-central mają na to rozwiązanie?!?!Dzięki nowoczesnemu Gitowi (w moim przypadku 1.8.3.4) i nie używaniu gałęzi możesz:
źródło
git rev-list --count --first-parent HEAD
git rev-list --count HEAD
zależności od tego, kiedy zostały wykonane ostatnie pushy i pully.--first-parent
dotyczy twojego problemu? Nie chciałbym unikać pozornie najprostszego rozwiązania ze względu na rzadki przypadek, jeśli istnieje równie proste obejście lub sposób, aby uczynić go bardziej niezawodnym.--first-parent
pomaga. Tak długo, jak nie dokonuje się zmiany baz, a ta sama gałąź jest zawsze używana do tworzenia wydań (i obliczania tego numeru wydania, oczywiście), myślę, że można to wykorzystać. Mimo to wciąż nie jestem pewien, czy zawsze jednoznacznie identyfikuje zatwierdzenie, z którego pochodzi wydanie. Jest tak wiele rzeczy, które mogą pójść nie tak ... ale w tej chwili nie mogę wymyślić czegoś, co na pewno by to zepsuło (biorąc pod uwagę moje powyższe „tak długo jak” stwierdzenia).git describe
Metoda wspomniano w innym odpowiedź jest droga. Utwórz tag, jeśli chcesz coś czytelnego dla człowieka.git describe
Polecenie tworzy nieco bardziej czytelnej nazwę, która odnosi się do konkretnego popełnił. Na przykład z dokumentacji:Dopóki używasz rozsądnie nazwanych tagów do oznaczania poszczególnych wydań, można to uznać za w przybliżeniu równoważne „numerowi wersji” SVN.
źródło
git
repozytorium ma już tagi; jeśli nie, może się zdarzyć, że git description zakończy się niepowodzeniem słowem „fatal: Nie znaleziono nazw, nic nie można opisać”. - Przepełnienie stosu ; co oznacza, że musisz sam skonfigurować tagi.git describe
nigdy nie zawieść, skorzystaj zgit describe --always
opcji.git describe
być użyte do znalezienia zatwierdzenia źródła? Mam na myśli brak ręcznego liczenia zatwierdzeń w dzienniku.v1.0.4
), jak i najnowszy commit id (2414721
) są już częścią danych wyjściowych git description.Inne plakaty mają rację, nie ma „numeru wersji”.
Myślę, że najlepszym sposobem jest użycie tagów do „wydań”!
Ale skorzystałem z poniższych do fałszywych numerów wersji (tylko dla klientów, aby zobaczyć wersje i postęp, ponieważ chcieli mieć takie same rosnące wersje z git, jak oni używali przez subversion).
Pokaż, że „bieżąca wersja” HEAD jest symulowana przy użyciu:
git rev-list HEAD | wc -l
Ale co, jeśli klient powie mi, że w „wersji” 1302 występuje błąd?
W tym celu do sekcji [alias] mojego ~ / .gitconfig dodałem:
show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'
użycie
git show-rev-number 1302
spowoduje wydrukowanie skrótu dla „wersji” :)Jakiś czas temu napisałem post na blogu (w języku niemieckim) na temat tej „techniki”.
źródło
git bisect
(link) jest odpowiednim narzędziem do identyfikacji tego, co się zmieniło przez kogo.git rev-list --reverse HEAD | awk "{ print NR }" | tail -n 1
Git nie ma tej samej koncepcji numerów wersji jak subversion. Zamiast tego każda podana migawka wykonana z zatwierdzeniem jest oznaczona sumą kontrolną SHA1. Czemu? Istnieje kilka problemów z działającym revno w rozproszonym systemie kontroli wersji:
Po pierwsze, ponieważ rozwój nie jest w ogóle liniowy, dołączenie liczby jest raczej trudne jako problem do rozwiązania w sposób, który zaspokoi twoją potrzebę jako programisty. Próba naprawienia tego przez dodanie numeru może szybko stać się problematyczna, gdy liczba nie będzie działać zgodnie z oczekiwaniami.
Po drugie, numery wersji mogą być generowane na różnych komputerach. To znacznie utrudnia synchronizację liczb - zwłaszcza, że łączność jest jednokierunkowa; możesz nawet nie mieć dostępu do wszystkich komputerów, które mają repozytorium.
Po trzecie, w git, nieco zapoczątkowany przez nieistniejący już system OpenCM, tożsamość zatwierdzenia (czym jest zatwierdzenie) jest równoważna jego nazwie (identyfikator SHA). Ta koncepcja nazewnictwa = tożsamości jest bardzo silna. Kiedy siedzisz z nazwą zatwierdzenia w dłoni, identyfikuje ona także zatwierdzenie w sposób niewybaczalny. To z kolei pozwala sprawdzić wszystkie swoje zobowiązania z powrotem do pierwszego początkowego pod kątem uszkodzenia za pomocą
git fsck
polecenia.Teraz, ponieważ mamy DAG (Directed Acyclic Graph) wersji, które stanowią obecne drzewo, potrzebujemy narzędzi do rozwiązania twojego problemu: Jak rozróżnić różne wersje. Po pierwsze, możesz pominąć część skrótu, jeśli dany prefiks, powiedzmy 1516bd , jednoznacznie identyfikuje twoje zatwierdzenie. Ale jest to również wymyślone. Zamiast tego sztuczka polega na użyciu tagów i / lub gałęzi. Znacznik lub gałąź przypomina „żółtą karteczkę, którą dołączasz” do danego zatwierdzenia SHA1-id. Tagi są w zasadzie nieruchome, podczas gdy gałąź będzie się poruszać, gdy zostaną wprowadzone nowe zatwierdzenia do jej HEAD. Istnieją sposoby odwoływania się do zatwierdzenia wokół tagu lub gałęzi, zobacz stronę man git-rev-parse.
Zwykle, jeśli musisz pracować nad konkretnym fragmentem kodu, ten fragment podlega zmianom i jako taki powinien być gałęzią o mówiącej nazwie tematu. Tworzenie wielu gałęzi (20-30 na programistę nie jest niespotykane, z niektórymi 4-5 opublikowanymi dla innych do pracy) jest sztuczką dla skutecznego git. Każda praca powinna rozpocząć się jako osobna gałąź, a następnie zostać scalona podczas testowania. Niepublikowane gałęzie można całkowicie przepisać, a ta część niszczenia historii jest siłą rażenia.
Kiedy zmiana zostanie zaakceptowana jako master , nieco się zawiesza i staje się archeologią. W tym momencie możesz go oznaczyć, ale częściej w śledzeniu błędów lub śledzeniu błędów pojawia się odniesienie do konkretnego zatwierdzenia za pomocą sumy sha1. Tagi są zwykle zarezerwowane dla wypukłości wersji i punktów rozgałęzień dla gałęzi konserwacji (dla starszych wersji).
źródło
Jeśli jesteś zainteresowany, automatycznie zarządzałem numerami wersji z informacji git tutaj w formacie
gdzie build to całkowita liczba zatwierdzeń. Zobaczysz ciekawy kod w
Makefile
. Oto odpowiednia część umożliwiająca dostęp do innej części numeru wersji:źródło
Funkcja Bash:
wypisuje coś podobnego
To jest
źródło
Hash SHA1 z popełnić jest odpowiednikiem numeru wersji Subversion.
źródło
Tak zrobiłem w moim makefile opartym na innych rozwiązaniach. Uwaga: kod ten nie tylko nadaje kodowi numer wersji, ale także dodaje skrót, który pozwala odtworzyć wydanie.
źródło
git-describe
uniknięcie błędów, zgit describe --always --dirty --long --tags
którym działa we wszystkich przypadkach, o których myślę.Problem z używaniem skrótu git jako numeru kompilacji polega na tym, że nie rośnie monotonicznie. OSGi sugeruje użycie znacznika czasu dla numeru kompilacji. Wygląda na to, że zamiast zatwierdzenia zmiany lub zmiany perforacji można użyć liczby zatwierdzeń do gałęzi.
źródło
Napisałem kilka narzędzi PowerShell do pobierania informacji o wersji z Git i uproszczenia tagowania
funkcje: Get-LastVersion, Get-Revision, Get-NextMajorVersion, Get-NextMinorVersion, TagNextMajorVersion, TagNextMinorVersion:
źródło
Każde zatwierdzenie ma unikatowy skrót. Poza tym w git nie ma numerów wersji. Będziesz musiał tagować zobowiązania, jeśli chcesz bardziej przyjazny dla użytkownika.
źródło
Chciałbym tylko zwrócić uwagę na inne możliwe podejście - i to za pomocą
git
git-notes (1) , istniejącego od wersji 1.6.6 ( Note to Self - Git ) (używamgit
wersji 1.7.9.5).Zasadniczo
git svn
klonowałem repozytorium SVN z historią liniową (bez standardowego układu, bez rozgałęzień, bez tagów) i chciałem porównać numery wersji w sklonowanymgit
repozytorium. Ten klon git nie ma domyślnie tagów, więc nie mogę go użyćgit describe
. Strategia tutaj prawdopodobnie działałaby tylko dla historii liniowej - nie jestem pewien, jak to się skończy z fuzjami itp .; ale oto podstawowa strategia:git rev-list
o listę wszystkich historii zatwierdzeńrev-list
domyślnie jest w „odwrotnym porządku chronologicznym”, użyjemy jego--reverse
przełącznika, aby uzyskać listę zatwierdzeń posortowanych według najstarszychbash
powłoki dogit log
przy pomocy--notes
, co spowoduje również zrzucenie notatki zatwierdzenia, która w tym przypadku byłaby „numerem wersji”git status
zatwierdzone, czy nie; tak naprawdę nie pojawiają się )Po pierwsze, zwróćmy uwagę, że
git
ma domyślną lokalizację notatek - ale możesz także określićref
(erence) dla notatek - która zapisałaby je w innym katalogu.git
; na przykład, gdy jesteś wgit
folderze repo, możesz zadzwonić,git notes get-ref
aby zobaczyć, jaki to będzie katalog:Należy zauważyć, że jeśli używasz
notes add
znaku a--ref
, musisz także użyć tego odwołania ponownie - w przeciwnym razie mogą pojawić się błędy typu „ Nie znaleziono notatki dla obiektu XXX ... ”.W tym przykładzie zdecydowałem się nazwać
ref
notatkę „linrev” (dla wersji liniowej) - oznacza to również, że jest mało prawdopodobne, że procedura będzie kolidować z już istniejącymi nutami. Używam również--git-dir
przełącznika, ponieważ będącgit
nowicjuszem miałem problemy z jego zrozumieniem - dlatego chciałbym „zapamiętać na później”:)
; i używam również--no-pager
do tłumienia pojawiania sięless
podczas używaniagit log
.Zakładając, że jesteś w katalogu z podfolderem,
myrepo_git
który jestgit
repozytorium; można zrobić:Tak więc, przynajmniej w moim konkretnym przypadku w pełni liniowej historii bez rozgałęzień, numery wersji wydają się pasować do tego podejścia - i dodatkowo wydaje się, że to podejście pozwoli na użycie
git log
z zakresami wersji, przy jednoczesnym uzyskaniu odpowiednich numerów wersji - YMMV jednak w innym kontekście ...Mam nadzieję, że to komuś pomoże,
zdrowie!
EDYCJA: Ok, tutaj jest trochę łatwiej, z
git
aliasami dla powyższych pętli, nazwanymisetlinrev
iunsetlinrev
; znajdując się w folderze repozytorium git, wykonaj następujące czynności ( zwróć uwagę na paskudnąbash
ucieczkę, zobacz także # 16136745 - Dodaj alias Git zawierający średnik ):... więc możesz po prostu wywołać
git setlinrev
przed próbą wykonania dziennika zawierającego liniowe notatki z rewizji; igit unsetlinrev
aby usunąć te notatki, gdy skończysz; przykład z katalogu git repo:Czas potrzebny powłoce na uzupełnienie tych aliasów będzie zależał od wielkości historii repozytorium.
źródło
Dla osób, które mają proces kompilacji Ant , możesz wygenerować numer wersji projektu na git z tym celem:
Wynik wygląda następująco:
Flaga „brudna” pojawia się, gdy pliki nie są zatwierdzone podczas generowania numeru wersji. Ponieważ zwykle podczas budowania / pakowania aplikacji każda modyfikacja kodu musi znajdować się w repozytorium.
źródło
Oprócz identyfikatora zatwierdzenia SHA-1, data i godzina czasu serwera pomogłyby?
Coś takiego:
źródło
W podręczniku Git tagi są świetną odpowiedzią na ten problem:
Sprawdź 2.6 Podstawy Git - Tagowanie
źródło
By default, the git push command doesn’t transfer tags to remote servers.
Używamy tego polecenia, aby pobrać wersję i wersję z git:
Powraca
gcc7b71f
)v2.1.0
używana w wydaniach)v5.3.0-88-gcc7b71f
)v5.3.0-88-gcc7b71f-dirty
)Zobacz także: https://www.git-scm.com/docs/git-describe#Documentation/git-describe.txt
źródło
Zdarzenie po kompilacji dla programu Visual Studio
źródło
Rozważ użycie
git-rev-label
Podaje informacje o rewizji repozytorium Git w formacie podobnym do
master-c73-gabc6bec
. Może wypełnić ciąg szablonu lub plik zmiennymi środowiskowymi i informacjami z Git. Przydatne do dostarczenia informacji o wersji programu: gałąź, znacznik, hash zatwierdzenia, liczba zatwierdzeń, status „brudny”, data i godzina. Jedną z najbardziej przydatnych rzeczy jest liczba zatwierdzeń, nie biorąc pod uwagę połączonych gałęzi - tylko pierwszego rodzica.źródło