[GIT] Opschonen oude branches/tags

[Tjolk]

Ik heb het beheer over een applicatie gekregen met behoorlijk wat historie. Er zijn een dikke 500 branches en een dikke 400 tags in remote die niet meer gebruikt worden. Dit is exclusief een aantal branches en tags voor de huidige productie c.q. ontwikkelversie.

Om wat overzicht te krijgen wil ik alles wat oud is (en dus al lang gemerged en opgeleverd) opruimen. Ik heb ze weten te identificeren en in een text file weten te zetten dmv

code:

git ls-remote | grep "JIRA_*"

en die output even simpelweg gekopieerd naar een txt. De hash die geoutput wordt heb ik eraf gehaald, wat een lijst oplevert als:

code:

refs/heads/JIRA_21505
refs/heads/JIRA_21507
refs/heads/JIRA_21508
refs/heads/JIRA_21509
refs/heads/JIRA_21510
[...]

En

code:

refs/tags/test_16.1.3
refs/tags/test_16.1.4
refs/tags/test_16.1.5
refs/tags/test_16.1.6
[...]

Mijn vraag is nu: volgens mij moet ik relatief eenvoudig met behulp van deze txt files de bijbehorende branches en tags uit de origin kunnen halen, maar de enige syntax die ik daarvoor ken is regel voor regel... Dat moet vlotter kunnen denk ik. Alternatief is een script schrijven wat hier doorheen loopt en het "per regel" commando uitvoert, maar ik kan me bijna niet indenken dat Git hier niet iets op bedacht heeft. In het git book krijg ik het niet gevonden.

Is er iemand die hier ook eens tegenaan gelopen is?

[CurlyMo]

Een kleine zoektocht onder de term Bulk remove git branches gaf terug dat dit gewoon werkt:

git branch -D `git branch | grep -E '^3\.2\..*'`

https://stackoverflow.com...s-in-one-command-with-git

Dit moet jij vast wel kunnen aanpassen naar jouw situatie.

[DataGhost]

Dit is niet een actie die je regelmatig uit hoort te voeren in een VCS, en hoe die precies uit te voeren hangt ontzettend van je gebruikte layout af. Er is dus niet echt een one-size-fits-all oplossing. Ik denk dat ze gedacht hebben dat iemand die een VCS beheert ook wel slim genoeg is om een scriptje te schrijven om oude meuk op te schonen.

Verder is het gewoon de computer het werk laten doen, het lijkt me niet enorm time-critical dat dit "vlot" gebeurt. Al duurt het een minuut per branch als je het door een scriptje "per regel" laat doen, zet je het aan in een screen en binnen een dag is het geregeld. Alle extra uren die je hier in steekt om straks een oplossing te hebben die 5 minuten nodig heeft ipv 2 uur is verloren tijd, en waarschijnlijk gaat het "per regel" ook behoorlijk snel.

[ Voor 41% gewijzigd door DataGhost op 23-09-2019 15:17 ]

[ACM]

Tjolk schreef op maandag 23 september 2019 @ 15:11:
Mijn vraag is nu: volgens mij moet ik relatief eenvoudig met behulp van deze txt files de bijbehorende branches en tags uit de origin kunnen halen, maar de enige syntax die ik daarvoor ken is regel voor regel... Dat moet vlotter kunnen denk ik. Alternatief is een script schrijven wat hier doorheen loopt en het "per regel" commando uitvoert, maar ik kan me bijna niet indenken dat Git hier niet iets op bedacht heeft. In het git book krijg ik het niet gevonden.

Wellicht kan je met xargs wat leuks doen

Die kan effectief je txt-file als input krijgen (met -a of door via cat te pipen) en combineert dan zoveel van de elementen als passen binnen de systeemlimiet voor commando-lengtes (of een andere ingestelde limiet) net zo vaak tot alle regels gedaan zijn.

[ Voor 9% gewijzigd door ACM op 23-09-2019 21:30 ]

[Hydra]

DataGhost schreef op maandag 23 september 2019 @ 15:15:
Dit is niet een actie die je regelmatig uit hoort te voeren in een VCS

Mensen 'horen' ook niet al hun branches te laten staan na een merge. Normaliter delete je die bij een merge.

[DataGhost]

Hydra schreef op dinsdag 24 september 2019 @ 10:58:
[...]


Mensen 'horen' ook niet al hun branches te laten staan na een merge. Normaliter delete je die bij een merge.

Lees alsjeblieft de rest van die zin en alinea ook, of heb jij een plan/script wat op *elke* repository werkt om oude, ongebruikte branches weg te halen? Dan kan je dat namelijk in git (laten) bouwen. Ik probeer alleen maar uit te leggen waarom het er niet in zit.

[itons]

https://stackoverflow.com...es-which-have-been-merged

Verder hebben tools zoals Azure DevOps ook een 'stale branches'-view: https://docs.microsoft.co...ps#organize-your-branches

Gitlab idem: https://docs.gitlab.com/e...s/#delete-merged-branches

Verder heeft @Hydra natuurlijk gelijk dat het een goed gebruik is om bij het sluiten van een PR/MR de source branch te verwijderen

[Tjolk]

itons schreef op dinsdag 24 september 2019 @ 11:34:

Verder heeft @Hydra natuurlijk gelijk dat het een goed gebruik is om bij het sluiten van een PR/MR de source branch te verwijderen

Ja, ik snap ook eerlijk gezegd niet wat de vorige beheerder gedacht heeft om ze allemaal te laten staan. Echt vanaf de eerste import in Git staat elke branch en tag er nog in (ook het aantal tags... wtf zeg).

Maar goed, opruimen lijkt dus goed mogelijk. Ik ga eens in de suggesties duiken.

[Hydra]

DataGhost schreef op dinsdag 24 september 2019 @ 11:07:
Lees alsjeblieft de rest van die zin en alinea ook

Het is al sinds internetmensenheugenis een best-practice om niet integraal hele berichten te quoten, maar genoeg om de context van de reactie weer te geven. Je moet er dus niet vanuit gaan dat als iemand niet je hele bericht quote ze het dus niet gelezen hebben.

Ik probeer alleen maar uit te leggen waarom het er niet in zit.

De reden dat het er niet inzit is omdat Git simpelweg geen notie heeft van 'merge requests'. Mijn reactie was niet bedoeld als tegenwerping ofzo, maar als aanvulling: dat het gewoon 'normaal' is om branches te deleten bij het sluiten van een MR.

Daarbij; @CurlyMo heeft al geantwoord hoe de TS dat 't beste kan doen.