Ištrinkite konfidencialius failus ir jų įsipareigojimus iš „Git“ istorijos

Norėčiau įdėti „Git“ projektą į „GitHub“, tačiau jame yra tam tikrų failų su slaptais duomenimis (naudotojų vardais ir slaptažodžiais, pvz., /Config/deploy.rb „capistrano“).

Žinau, kad galiu pridėti šiuos failų pavadinimus į .gitignore , tačiau tai neištrins jų istorijos „Git“.

Aš taip pat nenoriu iš naujo pradėti ištrinti /.git katalogą.

Ar yra būdas pašalinti visus tam tikro failo pėdsakus „Git“ istorijoje?

297
16 мая '09 в 17:49 2009-05-16 17:49 Stefanas paklausė gegužės 16 d., 17:49, 2009-05-16 17:49
@ 11 atsakymų

Visais praktiniais tikslais pirmas dalykas, kuris jums trukdo, yra Pakeisti savo slaptažodį! Neaišku, ar jūsų git saugykla yra visiškai vietinė, ar kitur turite nuotolinį saugyklą; jei jis yra ištrintas ir nėra apsaugotas nuo kitų, turite problemų. Jei kas nors klonuodavo šią saugyklą prieš ją ištaisydami, turėsite savo slaptažodžių kopiją savo vietinėje mašinoje, todėl negalėsite jų atnaujinti „fiksuotos“ versijos, jei ji išėjo iš istorijos. Vienintelis dalykas, kurį galite padaryti, yra pakeisti savo slaptažodį į kitą, kur jį naudojote.


Su šia šalimi, kaip tai išspręsti. „GitHub“ atsakė į šį klausimą atsakydamas į DUK :

Pastaba „Windows“ vartotojams : naudokite dvigubas kabutes („“), o ne vieninteles šiame komandoje

 git filter-branch --index-filter \ 'git update-index --remove filename' <introduction-revision-sha1>..HEAD git push --force --verbose --dry-run git push --force 

Atminkite, kad perkėlę šį kodą į nuotolinį saugyklą, pvz., „GitHub“, o kiti klonavo šį nuotolinį saugyklą, dabar esate tokioje situacijoje, kur perrašote istoriją. Kai kiti po to bandys nusiimti paskutinius pakeitimus, jie gaus pranešimą, kad pakeitimai negali būti taikomi, nes tai nėra greitas į priekį.

Norėdami išspręsti šią problemą, jie turės arba ištrinti esamą saugyklą, arba ją iš naujo klonuoti, arba vadovaudamiesi instrukcijomis, esančiomis „ gest -rebase“ puslapio skyriuje „RESTORE FROM UPSTREAM RESERVATION“.


border=0

Ateityje, jei netyčia atliksite tam tikrus pakeitimus konfidencialia informacija, tačiau pastebėsite spustelėję nuotolinį saugyklą, yra keletas paprastų pataisymų. Jei paskutinis įvykis yra tas, kuris prideda konfidencialią informaciją, galite tiesiog ištrinti konfidencialią informaciją ir paleisti:

 git commit -a --amend 

Tai pakeis ankstesnį įsipareigojimą su naujais pakeitimais, įskaitant pilną failų, pagamintų naudojant „ git rm ištrynimą. Jei pakeitimai grąžinami į istoriją, bet neperduodami į nuotolinį saugyklą, galite atlikti interaktyvų perkėlimą:

 git rebase -i origin/master 

Tai atveria redaktorių su paskutinio bendro protėvio prisiimtais įsipareigojimais su nuotoliniu saugykla. Pakeiskite „pick“ į „redaguoti“ bet kokiose eilutėse, atstovaujančiose įvykdyti konfidencialią informaciją, ir išsaugokite bei uždarykite. „Git“ atliks pakeitimus ir paliks jus ten, kur galite:

 $EDITOR file-to-fix git commit -a --amend git rebase --continue 

Už kiekvieną pasikeitimą su konfidencialia informacija. Galų gale, grįšite į savo filialą ir galėsite saugiai paspaudę naujus pakeitimus.

377
16 мая '09 в 19:04 2009-05-16 19:04 atsakymas duotas natacado gegužės 16 d. 09:04 2009-05-16 19:04

Slaptažodžių keitimas yra gera idėja, tačiau norint pašalinti slaptažodį iš savo atpirkimo istorijos, rekomenduoju BFG Repo-Cleaner , greitesnę ir paprastesnę alternatyvą git-filter-branch , kurie yra aiškiai skirti pašalinti asmens duomenis iš „Git“ saugyklų.

Sukurkite private.txt failą, kuriame išvardyti slaptažodžiai ir tt, kuriuos norite ištrinti (po vieną įrašą kiekvienoje eilutėje), ir tada paleiskite šią komandą:

 $ java -jar bfg.jar --replace-text private.txt my-repo.git 

Visi failai po slenksčio dydžiu (pagal nutylėjimą 1 MB) jūsų repo istorijoje bus nuskaityti, o bet kuri atitinkama eilutė (kuri nėra įtraukta į jūsų paskutinį pataisą) bus pakeista eilute „*** REMOVED ***“. Tada galite naudoti git gc kad išvalytumėte mirusius duomenis:

border=0
 $ git gc --prune=now --aggressive 

BFG paprastai yra 10–50 kartų greitesnis už einamojo git-filter-branch veikimą, o parametrai yra supaprastinti ir pritaikyti prie šių dviejų bendrų naudojimo atvejų:

  • Ištrinti „ Crazy Big Files“
  • Slaptažodžių, įgaliojimų ir kitos asmeninės informacijos trynimas

Visiškas atskleidimas: esu BFG Repo-Cleaner autorius.

70
02 февр. Atsakymą pateikė Roberto Tyley 02 vasaris. 2013-02-02 01:46 '13 at 1:46 2013-02-02 01:46

Aš rekomenduoju šį „ David Underrhill“ scenarijų , kuris man atrodo kaip žavesys.

Jis prideda šias komandas papildomam „natacado“ filtrų skyriui, kad pašalintų netvarą, kurią jis palieka:

 #!/bin/bash set -o errexit # Author: David Underhill # Script to permanently delete files/folders from your git repository. To use # it, cd to your repository root and then run the script with a list of paths # you want to delete, eg, git-delete-history path1 path2 if [ $# -eq 0 ]; then exit 0 fi # make sure we're at the root of git repo if [ ! -d .git ]; then echo "Error: must run this script from the root of a git repository" exit 1 fi # remove all paths passed as arguments from the history of the repo files=$@ git filter-branch --index-filter \ "git rm -rf --cached --ignore-unmatch $files" HEAD # remove the temporary history git-filter-branch # otherwise leaves behind for a long time rm -rf .git/refs/original/  \ git reflog expire --all  \ git gc --aggressive --prune 

Paskutinės dvi komandos gali geriau dirbti, jei jos pakeistos į šiuos:

 git reflog expire --expire=now --all  \ git gc --aggressive --prune=now 
16
22 нояб. Atsakymą pateikė Jason Goemaat lapkritis 22 2011-11-22 04:05 '11, 4:05, 2011-11-22 04:05

Jei jau spustelėjote „GitHub“, duomenys yra pažeisti, net jei jūs priverstinai ją paleisite vieną sekundę vėliau, nes:

Norėdami tai patikrinti, sukūriau repo: https://github.com/cirosantilli/test-dangling ir atlikiau:

 git init git remote add origin git@github.com:cirosantilli/test-dangling.git touch a git add . git commit -m 0 git push touch b git add . git commit -m 1 git push touch c git rm b git add . git commit --amend --no-edit git push -f 

Tačiau, jei ištrinsite saugyklą , įvykdytos operacijos iš karto išnyksta net iš API ir suteiks 404, pavyzdžiui, https://api.github.com/repos/cirosantilli/test-dangling-delete/commits/8c08448b5fbf0f891696819f3b2b2d653f7a3824. Tai veikia netgi tada, kai vėl sukuriate kitą saugyklą su tuo pačiu pavadinimu.

Todėl mano rekomenduojamas veiksmas yra:

  • pakeisti savo įgaliojimus

  • jei to nepakanka (pvz., nude nuotraukos):

    • ištrinti saugyklą
    • Kontaktinė pagalba
10
29 сент. Ciro Santilli atsakymas 改造 改造 中心 六四 事件 法轮功 29 Sep 2015-09-29 12:17 '15 , 12:17 2015-09-29 12:17

Aišku: priimtinas atsakymas yra teisingas. Išbandykite pirmiausia. Tačiau kai kuriems naudojimo atvejams tai gali būti be galo sunku, ypač jei susidūrėte su tokiomis nemaloniomis klaidomis kaip „mirtina: bloga parinktis yra„ tuščia “), arba tikrai nežino, kiek yra jūsų atpirkimo sandoris.

Alternatyva gali būti:

Tai, žinoma, pašalins visas įsipareigojimo istorijos šakas ir problemas, susijusias su tiek „github“ registru, tiek vietos git repo. Jei tai nepriimtina, turėsite naudoti alternatyvų metodą.

Tai vadinama branduoline galimybe.

8
26 янв. atsakymas, kurį pateikė lostphilosopher Jan 26 2015-01-26 02:38 '15 at 2:38 2015-01-26 02:38

Čia yra mano sprendimas >

„git filter-branch --tree-filter“ „rm -f“ filedir / failo pavadinimas „HEAD“

git push-force

įsitikinkite, kad kelias yra teisingas, kitaip jis neveiks

Tikiuosi, kad tai padės

6
02 дек. atsakymas pateikiamas vertigo71 02 gruodis. 2016-12-02 22:19 '16 at 22:19 pm 2016-12-02 22:19

Naudokite filtro šaką :

 git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch *file_path_relative_to_git_repo*' --prune-empty --tag-name-filter cat -- --all git push origin *branch_name* -f 
5
17 сент. Atsakymą pateikė Siv Krishna Jaiswal 17 sep . 2017-09-17 17:33 '17, 17:33 2017-09-17 17:33

Galite naudoti git forget-blob .

Naudojant „ git forget-blob file-to-forget gana lengva. Daugiau informacijos galite rasti čia.

https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/

Jis išnyks iš visų įvykių, susijusių su jūsų istorija, reflogu, žymėmis ir kt.

Kartais susiduriu su ta pačia problema, ir kiekvieną kartą, kai turiu grįžti į šį pranešimą ir kitus, kodėl aš automatizavau šį procesą.

Kreditai „Stack Overflow“ indėlininkams, kurie leido man jį gauti kartu

4
23 янв. Atsakymą pateikė nachoparker, sausio 23 d 2017-01-23 10:41 '17 at 10:41 2017-01-23 10:41

Aš turėjau tai padaryti kelis kartus. Atkreipkite dėmesį, kad tai veikia tik 1 failą vienu metu.

  • Gauti sąrašą visų įsipareigojimų, kurie pakeitė failą. Toliau bus pirmasis:

    git log --pretty=oneline --branches -- pathToFile

  • Jei norite pašalinti failą iš istorijos, naudokite pirmąjį įsipareigojimą sha1 ir failo kelią iš ankstesnės komandos ir užpildykite juos į šią komandą:

    git filter-branch --index-filter 'git rm --cached --ignore-unmatch <path-to-file>' -- <sha1-where-the-file-was-first-added>..

2
21 марта '17 в 21:23 2017-03-21 21:23 atsakymas pateikiamas b01 kovo 21 d. 17 val. 21:23 2017-03-21 21:23

Taigi, tai atrodo taip:

 git rm --cached /config/deploy.rb echo /config/deploy.rb >> .gitignore 

Ištrinkite stebimos rinkmenos talpyklą iš git ir pridėkite šį failą į .gitignore sąrašą .gitignore

2
27 апр. atsakymas pateikiamas przbadu 27 balandžio. 2014-04-27 11:33 '14 at 11:33 2014-04-27 11:33

„Android“ projekte aš turėjau admob_keys.xml kaip atskirą XML failą programoje / src / main / res / értékiai / aplanke. Norėdami ištrinti šį slaptą failą, naudoju žemiau esantį scenarijų ir dirbo gerai.

 git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch app/src/main/res/values/admob_keys.xml' \ --prune-empty --tag-name-filter cat -- --all 
0
01 февр. Atsakymą pateikė Ercan Duman 01 vasaris. 2019-02-01 12:46 '19 , 12:46 pm 2019-02-01 12:46