GIT - utrzymanie nazwy brancha po jego usunięciu

Hej, pytanie odnośnie GITa. Taka sytuacja. Mam brancha MASTER. Robię z niego dev. Z Tego deva robię np. Feature1. Potem wszystko merguję do mastera. Teraz w historii jest widoczne, że Feature1 został zmergowany z masterem. Następnie usuwam gałąź Feature1. W tym momencie z historii znika ta informacja. Do tej pory po prostu dodaję labela, ale może jest jakiś inny sposób, żeby utrzymać nazwę mergowanego brancha w historii po jego usunięciu?

Czy merge tego brancha masz potwierdzony commitem? Możesz mergować bez commita z informacją o mergowaniu, a to co widzisz, to prawdopodobnie tylko ułatwienie pod stronie IDE, z którego korzystasz do obsługi gita.

Lokalnie i ratunkowo masz git reflog
Na remote branch (usunięty lokalnie) sam nie usuwa się

Last but not least: co naprawdę chcesz osiągnąć?

Możesz wyjaśnić dokładniej co masz na myśli pisząc:

Teraz w historii jest widoczne, że Feature1 został zmergowany z masterem. Następnie usuwam gałąź Feature1. W tym momencie z historii znika ta informacja

Dwa scenariusze widzę:

• Jeśli mówiąc "branch" masz na myśli to, co ja, czyli gałąź zmian w kontroli wersji to to nie znika. Historia obu branchy nadal jest, nawet po jego usunięciu.

• Jeśli natomiast mówiąc "znika branch" masz na myśli "nie widzę już nazwy brancha", no to nie zobaczysz jej. Branch to jest tylko etykietka na ostatni commit, jak usuniesz etykietkę to jej już nie ma.

  Twoje wyjścia to:

  • w message'u merge commita napisać byłą nazwę brancha
  • nie usuwać brancha
  • dodać tag
  • prefixować commity nazwą brancha (np. zamiast commitów Fix 1, Fix 2, Fix 3, robić Feature1 - Fix 1, Feature1 - Fix 2, etc.)

Tak na prawdę Twój problem brzmi: "Usunąłem etykietkę brancha, i teraz nie widzę etykietki brancha".

Poza tym, wydaje mi się że masz w błąd rozumieniu tego co się dzieje. Jeśli mówisz, że faktycznie domergowujesz Feature1 do mastera, to Twoje zdanie "że Feature1 został zmergowany z masterem" jest błędne, bo Feature1 nie został zmergowany z masterem. Jak już coś, to master z Feature1.

Twoje wyjścia to:

Jeśli się nie obrazisz @TomRiddle to szereguje twoje pomysły od najgorszego :)
Szereguje według tego co spotkałem w pracy przez te 5 lat używania komercyjnie gita

• nie usuwać brancha

Zdecydowanie najgorsze rozwiązanie mimo że wydaje się najprostsze. Gałęzie to przesuwna etykieta. Nie ma sensu trzymać przesuwnych etykiet do nieprzesuwającego się historycznego miejsca. Dodatkowo trudno potem cokolwiek znaleźć w wielu serwerach CI typu Jenkins jak ma się za dużo Gałęzi

• w message'u merge commita napisać byłą nazwę brancha

Po namyśle przenoszę wyżej Już nawet zapomniałem że tak można. Ostatnie 2 lata merdzuje tylko na serwerze a nie lokalnie XD W zasadzie to w jednej firmie nawet nie tworzył się ten commit bo były ustawione reguły na serwerze robiące rebase zamiast merge żeby historia bardziej liniowa. Lokalne robienie merge'ów było faux pas

• dodać tag

Tag to nieprzesuwna etykieta więc wydaje się być idealny do tego. Jednak nie wyobrażam sobie że żeby tagować każdego merge'a. Taguje się zwykle jakieś większe zmiany (wersję która poszła do klienta, wersję wydaną na serwer testowy). Chodzi też o to żeby w tagach nie utonąć

• prefixować commity nazwą brancha (np. zamiast commitów Fix 1, Fix 2, Fix 3, robić Feature1 - Fix 1, Feature1 - Fix 2, etc.)

Zdecydowanie najlepsze rozwiązanie. Co coś w końcu krótki message commitu ma do 50 znaków (długi jest chyba nieograniczony). Zmieści się i nazwa gałęzi, i nr zadania, i prosta etykieta czy to bugfix czy feature. W zasadzie jest to dla mnie jedyne porządne rozwiązanie. Gałąź można usunąć, taga - zapomnieć dodać. A jak ktoś ma zły opis commita to mu nawet przegląd kodu nie przejdzie (przynajmniej tam gdzie teraz brakuję)

KamilAdam napisał(a):

Jeśli się nie obrazisz @TomRiddle to szereguje twoje pomysły od najgorszego :)

Chyba od najmniej pasującego do Twojej osobliwej wizji.

KamilAdam napisał(a):

Tag to nieprzesuwna etykieta więc wydaje się być idealny do tego. Jednak nie wyobrażam sobie że żeby tagować każdego merge'a. Taguje się zwykle jakieś większe zmiany (wersję która poszła do klienta, wersję wydaną na serwer testowy). Chodzi też o to żeby w tagach nie utonąć

Na czym polega "tonięcie w tagach"?
Do mastera merguje się albo skończony feature albo naprawionego buga, każda z tych rzeczy podbija wersję, i każda powinna skutkować utworzeniem taga z numerkiem wersji. Wtedy jest porządek.

Juhas napisał(a):

Do tej pory po prostu dodaję labela, ale może jest jakiś inny sposób, żeby utrzymać nazwę mergowanego brancha w historii po jego usunięciu?

git merge --no-ff feature1

I będziesz miał nazwę zmergowanego brancha w opisie commita. Nie wiem po co Ci ta informacja, ale będzie.