Kiedy usuwać oddziały w Git?

Załóżmy, że mamy aplikację, która jest stabilna.

Jutro ktoś zgłasza wielki błąd, który postanowiliśmy od razu naprawić. Dlatego tworzymy gałąź dla tej poprawki poza „master”, nazywamy ją „2011_Hotfix” i podnosimy ją, aby wszyscy programiści mogli współpracować przy jej naprawianiu.

Naprawiamy błąd i łączymy „2011_Hotfix” w „master”, a także w bieżącą gałąź programistyczną. I wciśnij „master”.

Co teraz robimy z „2011_Hotfix”? Czy powinien po prostu siedzieć tam jako gałąź do końca czasów, czy też powinniśmy go teraz usunąć, skoro spełnił swój cel? Wydaje się nieczyste pozostawianie gałęzi leżących wszędzie, ponieważ lista gałęzi prawdopodobnie stanie się bardzo długa, z których większość nie jest już nawet potrzebna.

W przypadku, gdy należy go usunąć, co stanie się z jego historią? Czy to zostanie utrzymane, nawet jeśli faktyczny oddział nie jest już dostępny? Ponadto, jak usunąć zdalną gałąź?

Możesz bezpiecznie usunąć gałąź za pomocą git branch -d yourbranch. Jeśli zawiera nie połączone zmiany (tzn. Stracisz zatwierdzenia poprzez usunięcie gałęzi), git powie ci i nie usunie go.

Tak więc usunięcie połączonego oddziału jest tanie i nie spowoduje utraty historii.

Aby usunąć gałąź zdalną, użyj git push origin :mybranch, zakładając, że twoja nazwa zdalna jest początkowa, a gałąź zdalna, którą chcesz usunąć, nosi nazwę mybranch.

To, co musisz zrobić, to oznaczyć wszystko, co wydasz. Trzymaj gałęzie, gdy aktywnie się rozwijasz.

Usuń stare gałęzie za pomocą

git branch -d branch_name

Usuń je z serwera za pomocą

git push origin --delete branch_name

lub stara składnia

git push origin :branch_name

co brzmi „wcisnąć nic do nazwy_gałęzi u źródła”.

To powiedziawszy, o ile DAG (ukierunkowany wykres acykliczny) może to wskazywać, zatwierdzenia będą istnieć w historii.

Google „git-flow”, który może dać więcej wglądu w zarządzanie wersjami, rozgałęzianie i tagowanie.

Ponieważ pytanie ma znacznik „github”, dodałbym to również: w szczególności w Github , jeśli ściągniesz żądanie gałęzi i zostanie ona scalona (albo przez interfejs użytkownika, albo przez połączenie gałęzi żądania ściągnięcia), nie będziesz stracisz dane żądania ściągnięcia (w tym komentarze), nawet jeśli usuniesz gałąź .

Konsekwencja tego: jeśli włączysz żądania ściągania jako część swojego przepływu pracy (który łączy się słodko z recenzjami kodu), możesz bezpiecznie usunąć gałęzie, gdy tylko zostaną scalone. Jest to tak powszechne, że ostatnio Github dodał (słodką) funkcję, która wyświetla przycisk „usuń gałąź” zaraz po scaleniu żądania ściągnięcia.

Warto jednak zauważyć, że każda grupa powinna przyjąć przepływ pracy, który najbardziej jej odpowiada (i może to prowadzić do usunięcia takich gałęzi). Mój obecny zespół roboczy, na przykład, przycina wszystkie gałęzie, które nie są związane z masterem lub wdrożeniem (np. Produkcja, przemieszczanie itp.), Gdy tylko ich żądania ściągnięcia zostaną scalone, a my nadal mamy pełne śledzenie tego, jak powstały powiązane zatwierdzenia każde przyrostowe ulepszenie każdego produktu.

Oczywiście żadne zarządzanie historią (żądania ściągania lub w inny sposób) nie zastępuje poprawnego oznaczania wersji (które najlepiej zautomatyzować za pomocą tego samego narzędzia / skryptu, który wdraża / pakuje wersję), więc zawsze możesz szybko przełączyć się na to, co akurat użytkownicy używają w danym momencie. Tagowanie jest również kluczem do rozwiązania pierwotnego problemu: jeśli ustalisz, że jakakolwiek gałąź scalona z gałęziami „roboczymi” może i powinna zostać usunięta, a każda, która jest scalona z tagiem wersji, „produkcyjnym” itp., Nie powinna , zawsze będziesz mieć żywe poprawki, dopóki nie zostaną zintegrowane w przyszłej wersji.

Dodam, że wadą usuwania gałęzi jest to, że łamiesz wszelkie hiperłącza do tych gałęzi w GitHub (to pytanie jest oznaczone jako github). Pojawi się 404 Not Foundbłąd dla tych linków. Dlatego zmieniam moje linki, aby wskazywały na zatwierdzenie lub tag po usunięciu gałęzi w GitHub.

Ponieważ niektórych linków nie można zmienić, na przykład w wiadomości e-mail, teraz unikam całkowicie hiperłącza do gałęzi GitHub i od samego początku linkuję do zatwierdzenia lub tagu.

Wolę usuwać gałęzie po ich scaleniu. Zapobiega to wizualnemu bałaganowi długiej listy gałęzi w twoim repozytorium. Gałęzie te są również propagowane do wszystkich forków repozytorium.

Najpierw usuwam mój lokalny oddział. Zapobiega to przypadkowemu popchnięciu go później.

git branch -d branchName

Następnie usuwam gałąź zdalnego śledzenia

git branch -dr remoteName\branchName

Następnie usuwam gałąź na GitHub. Korzystam z interfejsu internetowego, ale równoważne polecenie znajduje się poniżej.

git push remoteName :branchName

Nawet jeśli gałąź nigdy nie zostanie scalona, ​​zazwyczaj nadal chciałbym zachować zatwierdzenia dla potomności. Nadal jednak chcę usunąć gałąź. Aby rozłożyć zatwierdzenia i zapobiec ich zjedzeniu przez śmieciarza, tworzę adnotację oznaczającą ten sam zatwierdzenie, co usunięta gałąź.

git tag -a tagName commitOrBranchName

Następnie przesuwam tag do github

git push remoteName tagName

Wygląda na to, że chcesz usunąć 2011_Hotfixgałąź bez utraty jej historii. Omówię najpierw usunięcie, a historię drugie.

Zwykłe gitmetody usuwania gałęzi zostały już opisane powyżej i działają zgodnie z oczekiwaniami. gitnie ma polecenia składającego się z jednego lub dwóch słów, co oznacza: „Hej git, usuń gałąź lokalną i zdalną”. Ale to zachowanie można naśladować za pomocą skryptu powłoki. Weźmy na przykład skrypt powłoki Zach Holmana „git-nuke” . To bardzo proste:

#!/bin/sh
git branch -D $1
git push origin :$1

Umieść to w pliku wykonywalnym (np. git-nuke) W jednym z $PATHkatalogów. Jeśli nie jesteś w 2011_Hotfixoddziale, po prostu uruchomienie git-nuke 2011_Hotfixusunie zarówno oddziały lokalne, jak i zdalne. Jest to o wiele szybsze i prostsze - choć być może bardziej niebezpieczne - niż standardowegit polecenia.

Twoja troska o zachowanie historii jest dobra. W takim przypadku nie musisz się martwić. Po scaleniu 2011_Hotfixna masterwszystkie rewizje od 2011_Hotfixzostaną dodane do master„s popełnić historię. Krótko mówiąc, nie stracisz historii po zwykłym połączeniu.

Chciałbym dodać jeszcze jedno słowo, które być może wykracza poza zakres twojego pytania, ale jest jednak istotne. Wyobraźmy sobie, że istnieje 20 drobnych „prac w toku” 2011_Hotfix; chcesz 2011_Hotfixjednak dodać tylko jedno pełne zatwierdzenie do masterhistorii. Jak połączyć wszystkie 20 małych zatwierdzeń w jeden duży zatwierdzenie? Na szczęście gitumożliwia konsolidację wielu zatwierdzeń w jednym zatwierdzeniu za pomocą git-rebase. Nie wyjaśnię tutaj, jak to działa; jednak jeśli jesteś zainteresowany, dokumentacjagit-rebase jest doskonała. Zwróć uwagę, że git rebaseprzepisuje historię, więc powinna być używana rozsądnie, zwłaszcza jeśli dopiero zaczynasz. Wreszcie, twój 2011_Hotfixscenariusz dotyczy zespołu deweloperów, a nie solistów. Jeśli używają członkowie zespołu projektowegogit rebase, mądrze jest, aby zespół miał wyraźne wytyczne dotyczące użytkowania git rebase, aby jakiś kowbojski twórca w zespole nieświadomie zniszczył githistorię projektu.

Jeśli został pomyślnie scalony z powrotem, a może nawet oznaczony, powiedziałbym, że nie ma już sensu. Możesz więc bezpiecznie zrobić git branch -d branchname.

Jeśli chcesz przycinać lokalne oddziały, które zostały usunięte z pochodzenia, możesz również przycinać podczas używania git fetch

git fetch --prune

Możesz usuwać gałęzie we wszystkich głównych internetowych interfejsach użytkownika, takich jak github, BitBucket. Po usunięciu oddziału online możesz usunąć oddział lokalny za pomocą

git remote prune origin