기릿을 위한 기릿의 재발명.

이 글은 P&D 부가 달력의 6일째다.
여러분은 바퀴의 재발명에 대해 어떤 의견을 가지고 있습니까?
이 단어는 좋은 인상은 없지만 실제로는 일부 사람들이 적극적으로 진행하고 있다.
여기서 나는 바퀴가 아닌'git의 재발명'에 관한 글을 쓰고 싶다.
제목에서 보듯이 이번에 재발명된git는git가 관리하는 것으로 GitHub부터 볼 수 있다.
이 글에서git를 실시하는 과정에서 흥미로운 실장 부분을 다루겠습니다.

주의

  • 일부 지역과 본가의 git 행위가 일치하지 않을 수 있습니다.
  • 이후git는 본가의 물건을 가리키고, eat(easy-git)는 이번에 재발명한git를 가리킨다.
  • 컨디션


    OS: macOS(10.13.1)
    언어: C++
    편집기:Xcode
    컴파일러:Mac 표준
    테스트 환경: zsh(iTerm2)
    기본 터미널의 로그 표시는 다를 수 있습니다.

    첫번째 과제


    평소에 다들 무심코
    $ git add .
    $ git commit -m "example commit"
    
    기다리다
    $ git commit -am "fix many-many bugs"
    
    당신은dd의 행동을 의식하고 있습니까?
    이 때 이른바 디버깅 처리를 실행하고 있습니다.
    제본 과정에서dd 파일의 정보를 창고에 복사합니다. (여기서는 복사만 합니다.)그리고commiit를 진행하면 복사된 정보를 제출 트리라고 불리는 트리 구조에 추가합니다.

    즉, 한 단계를 거친 후 변경을 보존(반영)했기 때문에dd 이후 프로그램 내에서 제작된 나무 구조인commiit까지 보존하고 복원해야 한다.이git의 처리를 재현하려면 엄숙화와 분류화라는 단어가 떠오르지만 버전 관리 시스템은 어떠한 환경에서도 작업을 해야 한다.환경 의존의 실시가 좋지 않을 수도 있다.C++ 시행 과정에서 분할할 수 없는 문제가 발생하지는 않을지는 불확실하지만 확실한 방법을 강구해야 한다.최종적으로 형식을 결정하고 파일에 썼다.
    작성한 제본 내용은 다음과 같다.
    ./dir 8fd2094070b515a8475b5b1a7e5fad3a7243cc8d
    ./dir/file3 b9370c78bb825938731c633e6ae19d0a878486d4
    ./file1 9e293468bd5adcfbce75a929c0b2e994aab994c4
    ./file2 f80275f25936f6b39b3c1a1457e16370ed045ff6
    
    형식은 <相対パス> <ハッシュ値>(해시 값에 대해서는 다음 주제와 이름의 유일성을 참조하십시오.)
    이 데이터에 대응하는 구역을 만들고 제출 트리를 복구했습니다.
    이것은 git를 재발명하는 첫 번째 과제다.

    이름의 유일성


    프로젝트에서 initial.txt라는 파일을 제출한 상태에서 initial입니다.txt가 변경되었습니다.
    창고에 보관하고 싶은데 이름이 똑같아요.txt로 저장하면 과거의 데이터가 사라집니다. (버전을 관리할 수 없는 시스템)
    그렇다면 인티리얼.txt_2와 색인을 추가해 보았습니다.개발이 진행됨에 따라 인티리얼은 변하지 않았다.여러 번 제출했습니다.제출할 때마다 색인이 있는 파일을 저장합니다. 이렇게 하면 완전히 같지만 이름이 다른 많은 파일이 생성됩니다.이렇게 되면 프로젝트를 압축 파일로 잘 보관하는 것과 같다.이 문제를 해결하는 방법은 산열을 이용하는 것이다.산열은 다음과 같은 특성을 가지고 있다.
  • 동일한 입력에 대해 동일한 출력
  • 을 반환해야 합니다.
  • 출력된 문자열은 유일무이하다
  • 출력된 문자열의 길이 고정
  • 입력한 문자열이 1글자라도 바뀌면 출력된 문자열도 바뀐다
  • 반변환 불가
  • 이번에 특히 주의해야 할 것은 위의 두 가지 특징이다.eat에서 파일의 내용이 완전히 바뀌지 않으면 항상 같은 문자열 (파일 이름) 을 되돌려 주는 명명기로 사용할 수 있습니다.(실제로git는 이름을 붙일 때도 산열을 사용한다.)
    Mac는 다음과 같은 산열을 시도할 수 있습니다.

    해싱 사용

    $ md5 file #=> MD5ハッシュ
    $ openssl sha1 file #=> SHA1ハッシュ
    

    흩어진 특징을 체험하다

    $ echo "test is here" >> file
    $ md5 file #=> ba1d4a40ee18411302b7edc96217f69d #長さ32の文字列
    $ echo "insert changes" >> file
    $ md5 file #=> a28747665faa34a4e1db51ca9317132c #変更によって違うハッシュ値が得られたが、長さは32のまま
    
    (문자를 수정한 다음 해시 값을 볼 수 있습니다. 완전히 다른 문자열을 얻을 수 있습니다.)
    산열을 사용하면 변경된 파일만 복사하고 명명할 수 있기 때문에 (파일이 변경되면 산열이 다르고 변경을 감지할 수 있기 때문에) 최소한의 복사만 하면 된다.
    이번에는 주제 밖의 말로 산열의 가장 큰 특징은 다섯 번째 불가역성이라고 할 수 있다.산열되면 원래 뭔지 모르기 때문에 비밀번호를 보호하는 데 쓸 수 있다.1의 결정 요소(사용자 id 등)와 암호를 연결한 문자열의 산열 값, 그리고 id 자체를 그룹으로 삼아 암호의 일치 여부(id와 산열 값의 조합이 동일한지)를 확인하는 것이 안전 대책이 된다.
    그러나 위에서 사용한 MD5, SHA1 해시에서 SHA1은 Google에 의해 깨졌기 때문에 보안에 사용할 수 없습니다.SHA256을 사용합니다.

    이분목의 가능한 나무의 실현


    그러면 트리가 구성되었고git/eat는 디렉터리의 상태를 관리합니다.프로젝트 루트 디렉토리에서 환경을 정의하는 파일(Gemfile, Carrtfile, etc...)또는, 모든 디렉터리에는 여러 개의 원본 코드가 있어야 한다.디렉터리 아래에 여러 개의 파일과 디렉터리가 있을 것입니다. 전체 항목은 트리일 수도 있습니다.

    이런 것들을 어떻게 탐색하고, 어떻게 보관하는지 고려해야 한다.
    검색하기 편리하도록 파일을 blocb로 표시하고 디렉터리를tree로 표시합니다. (이것은 본가의 이름을 따릅니다.)
    맨 위의 아버지부터 스캔, 파일부터 다음 자식, 디렉터리부터 손자까지...되풀이컴백을 알았다면 그리 어려운 일은 아니었다.아이를 명단으로 가져오면 괜찮을 텐데 이번에는 조금 어색해 이분목으로 이 나무를 재현해 봤다.

    이분목의 레프트와 라이트는 아이와 형제에 대응한다.그리고 트리만 아이가 있을 수도 있어요.이렇게 하면 이분수라도 나무를 표현할 수 있다.
    여기. 참고할 수 있습니다.
    실장하지 않은 사람에게는 상관없지만 깊이 있는 우선 탐색이 아니라면 스마트하게 실현할 수 없다.생각해보니까 재밌을 것 같애.

    Usage


    너무 한가해서 어쩔 수 없이 그냥 놀았어요.사용하는 기능이 완전하지 않기 때문에 실제 개발에서는 사용하지 않는 것이 좋으나 놀면 괜찮을 것 같다.
    $ brew tap arabian9ts/easy-git
    $ brew install arabian9ts/easy-git/eat
    

    술수를 부리다

    $ eat init
    $ touch file
    $ eat add .
    $ eat commit
    $ eat branch qiita
    $ eat checkout qiita
    $ eat reset
    
    이만한 일을 하다니.장난감으로 주세요.

    최후


    여기에는 재발명에서 습득한 기술과 지식의 단편이 적혀 있는데, 하나하나가 모두 자신에게 자극적이고 즐겁다.
    평소 고릴라 회귀작문, 데이터 구조와 알고리즘을 의식하는 사람은 드물기 때문에 바퀴를 재발명해 봐야 한다고 생각한다.
    기초 기술에 눈을 돌리고 이를 재현하면 서로 다른 문제를 볼 수 있다.
    다각도로 문제를 보는 것이기 때문에 생각보다 많은 것을 배울 수 있는 좋은 기회다.
    그리고 무엇보다 화제가 돼 웃음

    좋은 웹페이지 즐겨찾기