git-filter-branch - Online în cloud

PROGRAM:

NUME

git-filter-branch - Rescrie ramurile

REZUMAT

merge filtru-ramură [--env-filter ] [--tree-filter ]
[--index-filter ] [--parent-filter ]
[--msg-filter ] [--commit-filter ]
[--tag-name-filter ] [--subdirector-filtru ]
[--prune-empty]
[--original ] [-d ] [-f | --forta]
[--] [ ...]

DESCRIERE

Vă permite să rescrieți istoricul reviziilor Git prin rescrierea ramurilor menționate în
opțiuni>, aplicând filtre personalizate la fiecare revizuire. Aceste filtre pot modifica fiecare arbore
(de exemplu, eliminarea unui fișier sau rularea unei rescriere perl pe toate fișierele) sau informații despre fiecare
comite. În caz contrar, toate informațiile (inclusiv orele de comitere originale sau informațiile de îmbinare)
vor fi conservate.

Comanda va rescrie doar pozitiv refs menționate în linia de comandă (de exemplu, dacă dvs
trece a..b, numai b vor fi rescrise). Dacă nu specificați niciun filtre, commit-urile vor fi
reangajat fără nicio modificare, ceea ce în mod normal nu ar avea niciun efect. Cu toate acestea, aceasta
poate fi util în viitor pentru compensarea unor erori Git sau așa ceva, deci un astfel de
utilizarea este permisă.

NOTĂ: Această comandă onorează fișierul .git/info/grafts și refs în spațiul de nume refs/replace/.
Dacă aveți grefe sau referințe de înlocuire definite, rularea acestei comenzi le va face
permanent

AVERTISMENT! Istoricul rescris va avea nume de obiecte diferite pentru toate obiectele și
nu va converge cu ramura originală. Nu vei putea să împingi cu ușurință și
distribuiți ramura rescrisă peste ramura originală. Vă rugăm să nu utilizați asta
comanda dacă nu cunoașteți implicațiile complete și evitați oricum să o utilizați, dacă este simplu
o singură comitere ar fi suficientă pentru a vă rezolva problema. (Consultați „RECUPERAREA DIN Amonte
REBASE" secțiunea în git-rebase(1) pentru informații suplimentare despre rescriere publicate
istorie.)

Verificați întotdeauna că versiunea rescrisă este corectă: Refurile originale, dacă sunt diferite de
cele rescrise, vor fi stocate în spațiul de nume refs/original/.

Rețineți că, deoarece această operațiune este foarte costisitoare I/O, ar putea fi o idee bună să redirecționați
directorul temporar off-disk cu -d opțiune, de exemplu pe tmpfs. Se pare că accelerarea
este foarte vizibil.

Filtre
Filtrele sunt aplicate în ordinea enumerată mai jos. The argumentul este întotdeauna
evaluat în contextul shell folosind eval comanda (cu excepția notabilă a
commit filter, din motive tehnice). Înainte de aceasta, variabila de mediu $GIT_COMMIT
va fi setat să conțină id-ul comitei care este rescris. De asemenea, GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL și
GIT_COMMITTER_DATE sunt preluate din commit-ul curent și exportate în mediu, în
pentru a afecta identitățile autorului și committerului commit-ului înlocuitor creat de
git-commit-tree(1) după ce filtrele au funcționat.

Dacă vreo evaluare a returnează o stare de ieșire diferită de zero, întreaga operațiune va fi
abandonată.

A Hartă este disponibilă o funcție care ia un argument „original sha1 id” și dă rezultate a
„rescris sha1 id” dacă commit-ul a fost deja rescris și „original sha1 id”
in caz contrar; cel Hartă Funcția poate returna mai multe ID-uri pe linii separate dacă filtrul dvs. de commit
a emis mai multe comiteri.

OPŢIUNI

--env-filter
Acest filtru poate fi utilizat dacă trebuie doar să modificați mediul în care se commit
va fi efectuat. Mai exact, ați putea dori să rescrieți autorul/comiterul
variabilele de mediu nume/e-mail/oră (vezi git-commit-tree(1) pentru detalii). Nu face
uitați să reexportați variabilele.

--tree-filter
Acesta este filtrul pentru rescrierea arborelui și a conținutului acestuia. Argumentul este evaluat
în shell cu directorul de lucru setat la rădăcina arborelui verificat. Noul
arborele este apoi folosit așa cum este (fișierele noi sunt adăugate automat, fișierele dispărute sunt eliminate automat
- nici fișierele .gitignore și nici alte reguli de ignorare AVEA orice EFECT).!

--index-filter
Acesta este filtrul pentru rescrierea indexului. Este asemănător cu filtrul de arbore, dar are
nu verificați copacul, ceea ce îl face mult mai rapid. Folosit frecvent cu git rm
--cached --ignore-unmatch ..., vezi EXEMPLE de mai jos. Pentru cazurile păroase, vezi git-update-
index(1).

--parent-filter
Acesta este filtrul pentru rescrierea listei părinte a commit-ului. Îl va primi pe părinte
șir pe stdin și va scoate noul șir părinte pe stdout. Șirul părinte este
în formatul descris în git-commit-tree(1): gol pentru comiterea inițială, „-p
părinte" pentru o comitere normală și "-p părinte1 -p părinte2 -p părinte3 ..." pentru o îmbinare
comite.

--msg-filter
Acesta este filtrul pentru rescrierea mesajelor de comit. Argumentul este evaluat în
shell cu mesajul de comitere original la intrarea standard; ieșirea sa standard este utilizată
ca noul mesaj de confirmare.

--commit-filter
Acesta este filtrul pentru efectuarea commit-ului. Dacă acest filtru este specificat, va fi
numit în loc de merge commit-tree comanda, cu argumente de forma "
[(-p )...]" și mesajul de jurnal pe stdin. Este așteptat ID-ul de comitere
pe stdout.

Ca extensie specială, filtrul de comitere poate emite mai multe ID-uri de comitere; in acest caz,
copiii rescriși ai comitului original îi vor avea pe toți ca părinți.

Aveți posibilitatea să utilizați Hartă funcția de confort în acest filtru și alte comodități
funcții, de asemenea. De exemplu, a suna skip_commit „$@” va omite curentul
commit (dar nu modificările sale! Dacă doriți asta, utilizați merge depășește în schimb).

De asemenea, puteți utiliza arborele git_commit_non_empty_tree „$@” în loc de arborele de comitere git „$@” dacă
nu doriți să păstrați commit-urile cu un singur părinte și asta nu aduce nicio schimbare la
copac.

--tag-name-filter
Acesta este filtrul pentru rescrierea numelor de etichete. Când va fi trecut, va fi chemat pentru fiecare
etichetă ref care indică către un obiect rescris (sau către un obiect etichetă care indică către a
obiect rescris). Numele etichetei inițiale este transmis prin intrarea standard și noua etichetă
numele este așteptat pe ieșirea standard.

Etichetele originale nu sunt șterse, dar pot fi suprascrise; utilizați „--tag-name-filter cat”
pentru a actualiza pur și simplu etichetele. În acest caz, fii foarte atent și asigură-te că ai
etichetele vechi au fost făcute copii de rezervă în cazul în care conversia s-a defectat.

Este acceptată rescrierea aproape corectă a obiectelor etichete. Dacă eticheta are un mesaj
atașat, un nou obiect etichetă va fi creat cu același mesaj, autor și
timestamp-ul. Dacă eticheta are atașată o semnătură, semnătura va fi eliminată. Este
prin definiție imposibil de păstrat semnăturile. Motivul pentru care acest lucru este „aproape” corect,
este pentru că, în mod ideal, eticheta nu s-a schimbat (indică același obiect, are același
nume etc.) ar trebui să păstreze orice semnătură. Nu este cazul, semnăturile vor fi
să fie întotdeauna eliminat, cumpărător ferește-te. De asemenea, nu există suport pentru schimbarea autorului sau
marca temporală (sau mesajul etichetei). Etichetele care indică alte etichete vor fi
rescris pentru a indica comiterea de bază.

--subdirector-filtru
Uită-te doar la istoricul care atinge subdirectorul dat. Rezultatul va conține
acel director (și numai acela) ca rădăcină a proiectului. Implica secțiunea numită „Remap
către strămoș”.

--prune-gol
Un fel de filtre vor genera comite-uri goale, care au lăsat arborele neatins. Acest
comutator permite git-filter-branch să ignore astfel de comiteri. Cu toate acestea, doar acest comutator
se aplică pentru comiteri care au unul și un singur părinte, prin urmare va păstra îmbinări
puncte. De asemenea, această opțiune nu este compatibilă cu utilizarea --commit-filter. Deşi
trebuie doar să folosești funcția git_commit_non_empty_tree „$@” în loc de git
Expresia „$@” din arborele de comitere din filtrul de comitere pentru a face acest lucru.

--original
Utilizați această opțiune pentru a seta spațiul de nume în care vor fi stocate commit-urile originale. The
valoarea implicită este refs/original.

-d
Utilizați această opțiune pentru a seta calea către directorul temporar utilizat pentru rescriere. Cand
aplicând un filtru de arbore, comanda trebuie să verifice temporar arborele pentru unii
director, care poate consuma spațiu considerabil în cazul proiectelor mari. În mod implicit
face asta în .git-rewrite/ director, dar puteți trece peste această alegere prin aceasta
parametru.

-f, --forță
merge filtru-ramură refuză să înceapă cu un director temporar existent sau când există
sunt deja refs care încep cu refs/original/, cu excepția cazului în care este forțat.

...
Argumente pentru merge rev-list. Toate referințele pozitive incluse în aceste opțiuni sunt rescrise.
De asemenea, puteți specifica opțiuni precum --toate, dar trebuie să utilizați -- pentru a le separa de
il merge filtru-ramură Opțiuni. Implica secțiunea numită „Remap la strămoș”.

Remapează la strămoş
Prin folosirea rev-list(1) argumente, de exemplu, limitatoare de cale, puteți limita setul de revizuiri
care sunt rescrise. Cu toate acestea, se disting refs pozitivi pe linia de comandă: noi
nu-i lăsați excluși de astfel de limitatori. În acest scop, sunt în schimb rescrise
pentru a indica cel mai apropiat strămoș care nu a fost exclus.

EXEMPLE

Să presupunem că doriți să eliminați un fișier (care conține informații confidențiale sau drepturi de autor
încălcare) din toate comiterile:

git filter-branch --tree-filter 'rm filename' HEAD

Cu toate acestea, dacă fișierul este absent din arborele unor comite, un nume de fișier rm simplu va fi
eșuează pentru acel copac și comite. Astfel, este posibil să doriți în schimb să utilizați rm -f nume de fișier ca
script-ul.

Folosind --index-filter cu merge rm produce o versiune semnificativ mai rapidă. Ca și cu utilizarea rm
filename, git rm --cached filename va eșua dacă fișierul este absent din arborele unui
comite. Dacă doriți să „uitați complet” un fișier, nu contează când a fost introdus
istoric, așa că adăugăm și --ignore-unmatch:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

Acum, veți primi istoricul rescris salvat în HEAD.

Pentru a rescrie depozitul pentru a arăta ca și cum foodir/ ar fi fost rădăcina proiectului său și renunțați la toate
alta istorie:

git filter-branch --subdirectory-filter foodir -- --all

Astfel, puteți, de exemplu, să transformați un subdirector de bibliotecă într-un depozit propriu. Rețineți că --
care separă filtru-ramură opțiunile din opțiunile de revizuire și --all pentru a rescrie toate
ramuri și etichete.

Pentru a seta un commit (care de obicei este la vârful unui alt istoric) să fie părintele lui
comitere inițială curentă, pentru a lipi cealaltă istorie în spatele istoriei curente:

git filter-branch --parent-filter 'sed "s/^\$/-p /"' CAP

(dacă șirul părinte este gol - ceea ce se întâmplă atunci când avem de-a face cu comiterea inițială
- adăugați graftcommit ca părinte). Rețineți că aceasta presupune istoria cu o singură rădăcină (care
este, nu sa întâmplat o fuziune fără strămoși comuni). Dacă nu este cazul, utilizați:

git filter-branch --parent-filter \
'test $GIT_COMMIT = && ecou "-p „ || CAP de pisică

sau chiar mai simplu:

echo "$commit-id $graft-id" >> .git/info/grafts
git filter-branch $graft-id..HEAD

Pentru a elimina din istoric comenzile create de „Darl McBribe”:

git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
apoi
skip_commit „$@”;
altfel
git commit-tree „$@”;
fi' CAP

Funcția skip_commit este definit după cum urmează:

skip_commit()
{
schimb;
în timp ce [ -n "$1" ];
do
schimb;
harta „$1”;
schimb;
Terminat;
}

Magia de schimbare mai întâi aruncă id-ul arborelui și apoi parametrii -p. Rețineți că aceasta
se ocupă de îmbinări! În cazul în care Darl a comis o fuziune între P1 și P2, va fi
propagat corect și toți copiii fuzionarii vor deveni comite de îmbinare cu P1, P2 ca
părinții lor în loc de comite de fuziune.

NOTĂ modificările introduse de comite-uri și care nu sunt reversate ulterioare
commits, va fi în continuare în ramura rescrisă. Dacă vrei să arunci schimbari împreună
cu commit-urile, ar trebui să utilizați modul interactiv al merge depășește.

Puteți rescrie mesajele de jurnal de comitere folosind --msg-filter. De exemplu, merge svn-id
șiruri într-un depozit creat de merge SVN poate fi eliminat astfel:

git filter-branch --msg-filter '
sed -e "/^git-svn-id:/d"
'

Dacă trebuie să adăugați Acked-by linii către, să zicem, ultimele 10 comite-uri (nici unul dintre acestea nu este o îmbinare),
utilizați această comandă:

git filter-branch --msg-filter '
pisică &&
echo „Acked-by: Bugs Bunny[e-mail protejat]>"
' CAP~10..Cap

Opțiunea --env-filter poate fi folosită pentru a modifica identitatea committerului și/sau a autorului. Pentru
de exemplu, dacă ați aflat că commit-urile dvs. au o identitate greșită din cauza unei configurații greșite
user.email, puteți face o corectare, înainte de a publica proiectul, astfel:

git filter-branch --env-filter '
dacă testul „$GIT_AUTHOR_EMAIL” = „rădăcină@localhost”
apoi
GIT_AUTHOR_EMAIL=[e-mail protejat]
exportați GIT_AUTHOR_EMAIL
fi
dacă testul „$GIT_COMMITTER_EMAIL” = „rădăcină@localhost”
apoi
GIT_COMMITTER_EMAIL=[e-mail protejat]
exportați GIT_COMMITTER_EMAIL
fi
' -- --toate

Pentru a restricționa rescrierea doar la o parte a istoricului, specificați un interval de revizuire în plus față de
noul nume al sucursalei. Noul nume de ramură va indica cea mai înaltă revizuire care a merge
rev-list din acest interval se va imprima.

Luați în considerare această istorie:

D--E--F--G--H
/ /
A--B-----C

Pentru a rescrie, comite doar D,E,F,G,H, dar lăsați A, B și C în pace, utilizați:

git filter-ramură ... C..H

Pentru a rescrie comiterile E,F,G,H, utilizați una dintre acestea:

git filter-branch ... C..H --nu D
git filter-branch ... D..H --nu C

Pentru a muta întregul arbore într-un subdirector sau pentru a-l elimina de acolo:

git filter-branch --index-filter \
'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.nou \
git update-index --index-info &&
mv „$GIT_INDEX_FILE.new” „$GIT_INDEX_FILE”’ HEAD

LISTA DE VERIFICARE PENTRU RIDICARE A REPERTORIU

git-filter-branch poate fi folosit pentru a scăpa de un subset de fișiere, de obicei cu unele
combinație de --index-filter și --subdirectory-filter. Oamenii se așteaptă la rezultat
depozitul să fie mai mic decât cel original, dar aveți nevoie de câțiva pași în plus pentru a face efectiv
este mai mic, pentru că Git încearcă din greu să nu-ți piardă obiectele până când îi spui. Primul
asigura-te ca:

· Ați eliminat într-adevăr toate variantele unui nume de fișier, dacă un blob a fost mutat pe durata de viață.
git log --name-only --follow --all -- filename vă poate ajuta să găsiți redenumiri.

· Ai filtrat cu adevărat toate referințele: folosește --tag-name-filter cat -- --all când apelezi
git-filter-ramură.

Apoi, există două moduri de a obține un depozit mai mic. O modalitate mai sigură este de a clona, ​​care rămâne
originalul tău intact.

· Clonează-l cu git clone file:///path/to/repo. Clona nu va fi eliminată
obiecte. Vedea git-clone(1). (Rețineți că clonarea cu o cale simplă doar hardlinks
Tot!)

Dacă într-adevăr nu doriți să-l clonați, din orice motiv, verificați următoarele puncte
în schimb (în această ordine). Aceasta este o abordare foarte distructivă, deci face a de rezervă sau du-te înapoi
pentru a-l clona. Ai fost avertizat.

· Eliminați referințele originale susținute de git-filter-branch: spuneți git for-each-ref
--format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d.

· Expira toate reflogurile cu git reflog expire --expire=now --all.

· Garbage colectează toate obiectele fără referință cu git gc --prune=now (sau dacă git-gc este
nu este suficient de nou pentru a susține argumente pentru --prune, utilizați git repack -ad; git prune
în schimb).

NOTE

git-filter-branch vă permite să faceți rescrieri complexe cu scripturi shell ale istoriei dvs. Git,
dar probabil că nu aveți nevoie de această flexibilitate dacă sunteți pur și simplu eliminarea nedorit de date ca
fișiere mari sau parole. Pentru acele operațiuni pe care poate doriți să le luați în considerare BFG
Repo-Cleaner[1], o alternativă bazată pe JVM la git-filter-branch, de obicei cel puțin 10-50x
mai rapid pentru acele cazuri de utilizare și cu caracteristici destul de diferite:

· Orice versiune specială a unui fișier este curățată exact dată. BFG, spre deosebire de
git-filter-branch, nu vă oferă posibilitatea de a trata un fișier diferit
în funcție de locul sau când a fost comis în istoria dvs. Această constrângere dă
beneficiul principal de performanță al BFG și este potrivit pentru sarcina de curățare rău
date - nu-ți pasă Unde datele proaste sunt că doar le vrei plecat.

· În mod implicit, BFG profită din plin de mașinile multi-core, curățând comiterea
arbori de fișiere în paralel. git-filter-branch curăță comiterile secvenţial (adică într-un
cu un singur fir), deși is posibil să scrieți filtre care să includă propriile lor
paralelism, în scripturile executate împotriva fiecărui commit.

· comandă Opțiuni[2] sunt mult mai restrictive decât ramura git-filter și dedicate
doar la sarcinile de eliminare a datelor nedorite, de exemplu: --strip-blobs-bigger-than 1M.

GIT

O parte din merge(1) apartament

NOTE

1. BFG Repo-Cleaner
http://rtyley.github.io/bfg-repo-cleaner/

2. opțiuni de comandă
http://rtyley.github.io/bfg-repo-cleaner/#exemple

Utilizați git-filter-branch online folosind serviciile onworks.net