Gitastrophes: 자신의 a$를 저장합니다. - 첫 번째 부분.

git는 강력한 힘과 커다란 책임을 가져왔다

본문을 읽는 대다수 사람들이git에 익숙한데 이것은 현재 버전이 제어하는 황금 표준이다.내가 처음 프로그래밍git를 시작했을 때, 그것은 내가 가장 배우기 어려운 것 중의 하나였고, 나는 매우 까다로운 상황을 만났기 때문에, 나는 기억할 수 없었다.
비록 당시에 나는 내가 모른다고 생각했지만, Git는 소수의 몇 가지 직업 준비가 충분히 포괄된 것 중의 하나였다. 왜냐하면 많은 소프트웨어 공학이나 컴퓨터 과학 학위가 버전 제어를 포괄하지 않기 때문이다.내 경험에 따르면 많은 사람들이 고통스러운 성장 단계를 가지고 있다는 것을 의미한다.
좋은 면에서 Git의 기능은 강력합니다.단점은 그것의 기능이 강하다는 것이다.

지타스토피스

Git를 사용할 때 최악의 경우 환경 파일의 암호나 기밀과 같은 민감한 데이터가 Github, Gitlab, Bitbucket의 위탁 관리 저장소에 편입된다.
제출을 취소할 수 있는 몇 가지 방법이 있는데, 통상적으로 복원이라고 불리는 과정을 통과한다.지점을 허물고 역사를 압박할 수도 있지만, 저장소에 편입된 민감한 역사를 완전히 제거하는 것은 핵심적인 절차를 취해 파일을 삭제하더라도 도전일 수 있다.
우리가 다음에 소개할 방법은 정상적인 시정 조치가 민감한 문서나 민감한 데이터의 역사를 숨기기에 부족할 때 이런 방법의 한계성을 소개하는 것이다.
주의: 본고는 중급 독자에게 더욱 적합하다.만약 네가 아직git를 이해하지 못한다면, 나는 네가 이런 핵 행동을 취하는 것을 건의하지 않는다.나도 기본 용어는 언급하지 않을 것이다.

설치 프로그램

나는 우선 새로운 저장소, bfg_시범을 만들 것이다.

나는 복제한 후에 cd를 우리의 새로운 환매에 넣고 우리가 사용할 수 있도록 새로운 파일을 만들 것이다.

➜  Desktop git clone https://github.com/jtkaufman737/bfg_demo.git
Cloning into 'bfg_demo'...
➜  Desktop cd bfg_demo
➜  bfg_demo (main) ✗ touch .env .gitignore file.py file.js file.go file.sql
➜  bfg_demo (main) ✗ ls
README.md file.go  file.js  file.py  file.sql

지금 나는 우리의 데이터베이스에 약간의 민감한 데이터를 추가할 것이다.vv 파일, 알다시피, 이것은 일반적으로gitignored 파일로 저장소에 제출하지 않으며, 민감한 데이터를 비밀로 하는 데 사용됩니다.텍스트를 추가하면 우리의.env는 다음과 같습니다.

➜  bfg_demo (main) ✗ cat .env
SECRET=b8ee43a51b6ba41eb873dc83e11dbbcbbb3a2131
SUPER_SECRET=371a648b3dce5636aee0c1425aca8d3d59482ace
NUCLEAR_CODES=359e95931e95032ed8b71534b75c57eb17717d59

지금 우리가 선의적인 사람이라고 가정하면git에서 이 env 파일을 무시하지만, 입력 오류가 있습니다.gitignore.아이고!

➜  bfg_demo (main) ✗ cat .gitignore
.emv

이것이 바로 우리가 재난을 가장하는 충분한 전제 조건이다.기능 지점을 검사해서 업무를 제출하고pull 요청으로 보냅니다.

➜  bfg_demo (main) ✗ git checkout -b "disaster"
Switched to a new branch 'disaster'
➜  bfg_demo (disaster) ✗ git status
On branch disaster

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .env
    .gitignore
    file.go
    file.js
    file.py
    file.sql

nothing added to commit but untracked files present (use "git add" to track)
➜  bfg_demo (disaster) ✗ git add .
➜  bfg_demo (disaster) ✗ git commit -m "First commit. What could go wrong?"
[disaster (root-commit) dffd8b0] First commit. What could go wrong?
 6 files changed, 4 insertions(+)
 create mode 100644 .env
 create mode 100644 .gitignore
 create mode 100644 file.go
 create mode 100644 file.js
 create mode 100644 file.py
 create mode 100644 file.sql
➜  bfg_demo (disaster) ✔ git push origin disaster 
Counting objects: 5, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (5/5), 458 bytes | 458.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To https://github.com/jtkaufman737/bfg_demo.git
 * [new branch]      disaster -> disaster

의외의 슈퍼 기밀 내용을 포함하여 이 새로운 내용의 합병 요청을 작성하고 받아들일 것입니다.환경

이 점을 받아들이면 우리는 전제가 있다.계속해서 BFG에 대해 토론합시다.

용광로 가스

이 점에서 당신은 이런 상황을 해결할 수 있는 여러 가지 방법이 있다고 생각할 수도 있습니다. 핵 옵션을 사용하지 않고 회복할 수 있다면, 왜 아예 환매를 취소하고 다시 시작하여 문제의 역사에서 벗어나지 않겠습니까?
물론 이 물건들은 책상 위에 있을 것이다.그러나 만약에 이것이 많은 공헌자의 주동적인 환매라면 BFG는 이런 옵션보다 더 좋을 수 있다. 이런 환매에서 문제 제출은 다른 제출에 의해 가려질 수 있고 내용을 회복하거나 제거하면 관건적인git역사를 파괴할 수 있다. 그렇지 않으면 비현실적이다.
그럼 BFG가 뭐예요?
BFG는 세 가지 도구 중 하나입니다. 만약git에서 아주 나쁜 일을 하고 그것을 해결하느라 바쁘다면, 이 세 가지 도구를 반복해서 볼 수 있습니다.
민감한 정보 삭제 git filter-branch 와 git filter-repo 를 처리할 수 있는 다른 도구도 두 개 있다.Git scm docsgit filter branch를 인용합니다. 이 도구가 필요할 때 Gitlab와 Github 문서 간의 혼합 인용에 헷갈려서git filter branch가 더 이상 추천되지 않는다고 했지만 git filter repo를 어떻게 사용하는지에 대한 설명이 적거나 잘 모르겠습니다.
나는 일을 끝내는 것을 좋아하는 사람이다. 그래서 나는 항상 더 좋은 문서가 있는 곳에서 나의 도구를 선택한다. 이 문서들은 나로 하여금 a점에서 B점까지 더 빨리 갈 수 있게 한다.제 예에서 다른 도구 설명의 충돌/희소한 문서와 교란으로 인해 BFG를 사용했습니다.너의 이정수는 다를 수 있지만, 나에게는 이것이 가장 사용하기 쉽다.

입문

설령 이것이 더욱 접근하기 쉬운 선택이라 하더라도 몇 가지 절차가 있다.나는 맥에서 이것을 실행하기 때문에 brew install bfg부터 시작한다.
(아, 귀여워. - BFG는 자바 개발 패키지에 의존한다! 이 점에서 내가 JDK를 마운트 해제할 때마다 내 맥은 반드시 나를 비웃는다. 왜냐하면 나는 여러 가지 이유로 계속 그것을 다시 설치해야 하기 때문이다-)
다음은 BFG 문서에 따라 나체 복제를 하겠습니다.

➜  Desktop git clone --mirror https://github.com/jtkaufman737/bfg_demo.git
Cloning into bare repository 'bfg_demo.git'...
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 11 (delta 1), reused 7 (delta 1), pack-reused 0
Unpacking objects: 100% (11/11), done.

우리가 역사를 다시 쓰기 시작하기 전에, 우리의 문제를 아이가 볼 수 있다는 것을 확인하자.

역사를 개작하다

네, 모든 것이 준비되었습니다. BFG 문서에 대해 자세히 알아보겠습니다.

우리 같은 상황에 대해 첫 번째나 세 번째 예는 무엇이 도움이 될 수 있는지를 대체적으로 설명한다.왜냐하면vv 파일은 정말 Github나 Gitlab 같은 위탁 관리 서비스에 추가해서는 안 됩니다. 공격을 시도할 것입니다.env 파일은 기록에서 왔습니다.
BFG를 사용하여 파일을 삭제하는 공식은 다음과 같습니다.

bfg --delete-files [file name] [<bare cloned repo>.git]

나로서는 다음과 같다.

bfg --delete-files .env bfg_demo.git

좋아, 우리 페달을 메달 위에 놓자.명령을 실행할 때 다음이 표시됩니다.

➜  Desktop bfg --delete-files .env bfg_demo.git

Using repo : /Users/jkaufman/bfg_demo.git

Found 5 objects to protect
Found 4 commit-pointing refs : HEAD, refs/heads/disaster, refs/heads/main, refs/pull/1/head

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit 34522682 (protected by 'HEAD') - contains 1 dirty file : 
    - .env (157 B)

WARNING: The dirty content above may be removed from other commits, but as
the *protected* commits still use it, it will STILL exist in your repository.

Details of protected dirty content have been recorded here :

/Users/jkaufman/bfg_demo.git.bfg-report/2020-10-16/10-05-46/protected-dirt/

If you *really* want this content gone, make a manual commit that removes it,
and then run the BFG on a fresh copy of your repo.


Cleaning
--------

Found 3 commits
Cleaning commits:       100% (3/3)
Cleaning commits completed in 24 ms.

BFG aborting: No refs to update - no dirty commits found??

사격여기에서 무슨 일이 일어났는지 행간에서 알 수 있을 것 같지만 TL:DR은:

BFG는 "더러운"제출을 찾았고 우리의 제출을 인용했다.삭제를 시도하는 env 파일

BFG는 ref 또는 이 파일의 기록에 대한 내부 인용 표지를 보호합니다. 왜냐하면 이것은 현재 우리의 주 지점

의pull 요청을 통해 받아들여지기 때문입니다.

따라서 BFG는 우리의 역사를 다시 쓰는 것을 넘어섰다

보시다시피, 문제 파일을 삭제하고 명령을 다시 실행하는 새로운 방법을 제공합니다.새로운 단말기 옵션 카드에서, 나는 나의 비누드 환매로 돌아가서main 아래에서 삭제할 것이다.환경

➜  bfg_demo (main) ✔ git pull origin main
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From https://github.com/jtkaufman737/bfg_demo
 * branch            main       -> FETCH_HEAD
   07692d9..3452268  main       -> origin/main
Updating 07692d9..3452268
Fast-forward
 .env       | 3 +++
 .gitignore | 1 +
 file.go    | 0
 file.js    | 0
 file.py    | 0
 file.sql   | 0
 6 files changed, 4 insertions(+)
 create mode 100644 .env
 create mode 100644 .gitignore
 create mode 100644 file.go
 create mode 100644 file.js
 create mode 100644 file.py
 create mode 100644 file.sql
➜  bfg_demo (main) ✔ rm .env
➜  bfg_demo (main) ✗ ls -a
.          ..         .git       .gitignore README.md  file.go    file.js    file.py    file.sql
➜  bfg_demo (main) ✗ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    .env

no changes added to commit (use "git add" and/or "git commit -a")
➜  bfg_demo (main) ✗ git add .env
➜  bfg_demo (main) ✗ git commit -m "Remove env"
[main e88aea6] Remove env
 1 file changed, 3 deletions(-)
 delete mode 100644 .env
➜  bfg_demo (main) ✔ git push origin main
Counting objects: 2, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 229 bytes | 229.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/jtkaufman737/bfg_demo.git
   3452268..e88aea6  main -> main

이제 클론 단계를 다시 미러링해 보겠습니다.

➜  Desktop rm -rf bfg_demo.git 
➜  Desktop git clone --mirror https://github.com/jtkaufman737/bfg_demo.git
Cloning into bare repository 'bfg_demo.git'...
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 11 (delta 1), reused 7 (delta 1), pack-reused 0
Unpacking objects: 100% (11/11), done.

네, 결정적인 순간입니다.BFG 명령을 다시 실행합니다.

➜  Desktop bfg --delete-files .env bfg_demo.git

Using repo : /Users/jkaufman/Desktop/bfg_demo.git

Found 4 objects to protect
Found 4 commit-pointing refs : HEAD, refs/heads/disaster, refs/heads/main, refs/pull/1/head

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit e88aea6c (protected by 'HEAD')

Cleaning
--------

Found 4 commits
Cleaning commits:       100% (4/4)
Cleaning commits completed in 39 ms.

Updating 3 Refs
---------------

    Ref                   Before     After   
    -----------------------------------------
    refs/heads/disaster | 69c88c7f | 32084753
    refs/heads/main     | e88aea6c | b8a8c5df
    refs/pull/1/head    | 69c88c7f | 32084753

Updating references:    100% (3/3)
...Ref update completed in 16 ms.

Commit Tree-Dirt History
------------------------

    Earliest      Latest
    |                  |
      .    D    D    m  

    D = dirty commits (file tree fixed)
    m = modified commits (commit message or parents changed)
    . = clean commits (no changes to file tree)

                            Before     After   
    -------------------------------------------
    First modified commit | 69c88c7f | 32084753
    Last dirty commit     | 34522682 | ac89d326

Deleted files
-------------

    Filename   Git id          
    ---------------------------
    .env     | a23857e3 (157 B)


In total, 4 object ids were changed. Full details are logged here:

    /Users/jkaufman/Desktop/bfg_demo.git.bfg-report/2020-10-16/10-20-44

BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive

BFG는 다음 단계를 설명합니다.

우리는 여기에서 두 개의git 명령을 사용할 것입니다. 이것은 모두repo정리에 사용됩니다:git-gc와git-prune. here와here에 대한 내용을 더 읽을 수 있습니다.

➜  bfg_demo.git (main) ✔ git reflog expire --expire=now --all && git gc --prune=now --aggressive
Counting objects: 9, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (9/9), done.
Total 9 (delta 1), reused 0 (delta 0)

경고

혼란스러운 역사에서 벗어나 새로운 역사를 추진하는 것을 축하하는 재미있는 일이 일어났다.우리가 네가 그것을 발견했는지 아닌지를 좀 봅시다.

➜  bfg_demo.git (main) ✔ git push 
Counting objects: 9, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (9/9), 1.25 KiB | 1.25 MiB/s, done.
Total 9 (delta 1), reused 9 (delta 1)
remote: Resolving deltas: 100% (1/1), done.
To https://github.com/jtkaufman737/bfg_demo.git
 + 69c88c7...3208475 disaster -> disaster (forced update)
 + e88aea6...b8a8c5d main -> main (forced update)
 ! [remote rejected] refs/pull/1/head -> refs/pull/1/head (deny updating a hidden ref)
error: failed to push some refs to 'https://github.com/jtkaufman737/bfg_demo.git'

나는 궁금증을 깨뜨리고 너에게 이 줄을 알려줄 것이다. ! [remote rejected] refs/pull/1/head -> refs/pull/1/head (deny updating a hidden ref)
우리가 요청에서 정보를 삭제할 수 없다는 것을 보여 주는 것 같다...심지어 gitpush에서 --force 로고를 사용하여 빠르고 느슨하게 놀아요. no go:

➜  bfg_demo.git (main) ✔ git push --force
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/jtkaufman737/bfg_demo.git
 ! [remote rejected] refs/pull/1/head -> refs/pull/1/head (deny updating a hidden ref)
error: failed to push some refs to 'https://github.com/jtkaufman737/bfg_demo.git'

이것이 무엇을 의미하는지 보고 우리의 환매로 돌아가자.

우선, 나는 우리가 만든 특성 지점에서 나의'첫 제출 오류 가능성'제출을 검사할 것이다.환경

너무 신기하다아니오환경 파일.이거 대박이다.지금,main의 최근 제출을 봅시다. 거기서 삭제했습니다.diff에 기밀 정보가 표시되지 않았는지 확인하기 위해 env 파일입니다.

거짓말하지 마라, 우리의 상태는 이미 이전보다 좋아졌다.우리의 약속은 결백하다.하지만 흔들리지 않는 문제가 있습니다. 요청된 보호된 인용을 당기면 BFG가 호출해서 삭제할 수 없다고 말하는 것을 기억할 것입니다.

고통스러운 결말

나는 유일하게 이런 상황을 만난 사람이 아니다.as you'll see in this question to the creator of BFG.그들이 설명한 바와 같이 우리의 상황에서 마지막 문제를 바꾸는 것은 기본적으로 그들의 능력을 초과한다.물론,pull requests>closed 창으로 돌아가서 PR을 보면 diff에서 볼 수 있습니다.

여기서 우리는 벽을 만났다. 만약 당신이 이것 stack overflow q 을 본다면, 우리는 Github 고객 서비스에 연락하는 것 외에 다른 희망이 없는 것 같다.(겸사겸사 한마디 하자면, 그들은 대단하다. 나는 일요일에 한 시간 정도 자질구레한 일에 대해 나에게 대답하라고 했다.)
따라서 이것은 내가 바라는 만족스러운 결론은 아니지만, Github에게 보낸 이메일을 통해 우리는 이 난감한 오류의 마지막 흔적을 지우고 우리의 저장소 역사와 새로운 제출 기록을 보존할 수 있어야 한다.
* BFG 기능은 여기까지지만 실제로는 git filter repo를 사용하여 더 멀리 갈 수 있습니다.git filter repo를 사용하여 전체 지우는 방법 보기