Git란 무엇인가?

docs.scrimba.com

당신은 아마도 손으로 버전 관리를 해본 적이 있을 것입니다. report.docx, report_final.docx, report_final_v2.docx, report_final_ACTUAL.docx가 들어 있는 폴더는 버전 관리의 최악의 형태입니다. 두 파일 사이에 무엇이 변경되었는지 알 수 없고, 두 사람이 동시에 만든 편집을 병합할 수 없으며, 세 개 앞의 복사본에서 삭제한 좋은 단락을 되찾을 수 없습니다.

Git은 이 문제를 제대로 해결합니다. 프로젝트의 스냅샷을 시간에 따라 기록하는 도구로서, 전체 히스토리가 복사본의 더미 대신 한 곳에 있습니다. 이 도구 자체는 당신의 컴퓨터에서 실행되는 작은 프로그램입니다. git으로 시작하는 명령을 터미널에 입력하면 텍스트로 답변합니다.

Git이 당신을 위해 해주는 것

기본적으로 Git은 프로젝트의 타임라인을 유지합니다. 저장할 가치가 있는 지점에 도달할 때마다 **커밋**을 기록합니다. 이는 모든 파일의 스냅샷과 무엇이 변경되었는지, 그리고 왜 변경되었는지를 설명하는 짧은 메시지입니다. 나중에 그 타임라인을 다시 살펴보면 프로젝트가 어떻게 현재 상태에 도달했는지 정확히 볼 수 있습니다. 다음은 프로젝트의 커밋을 나열하는 git log 명령으로 출력한 실제 타임라인입니다 (--oneline 플래그는 각 커밋을 한 줄로 단축합니다):

$ git log --oneline
a1b2c3d 비밀번호 강도 표시기 추가
9f8e7d6 가입 양식 유효성 검사 수정
5c4b3a2 프로젝트 구조 설정

이는 프로젝트 히스토리의 세 가지 저장된 지점입니다. 최신 항목이 맨 위에 있고, 각각 짧은 ID와 작성자가 작성한 메시지가 있습니다. (이와 같은 모든 예시에서 $로 시작하는 줄은 터미널에 입력한 명령이며 $ 자체는 포함되지 않고, 그 아래의 줄들은 Git의 응답입니다.) 다음 몇 장에서 이 히스토리를 생성하고 읽는 모든 명령을 배우게 됩니다. 지금은 Git이 항상 돌아갈 수 있는 스냅샷 시리즈로 작업을 기록하고 있다는 아이디어를 유지하세요.

프로젝트에 이와 같은 히스토리가 있으면 많은 일이 가능해집니다. 무엇이 변경되었는지, 누가 변경했는지 볼 수 있습니다. 위험한 아이디어를 한쪽에서 시도해볼 수 있으며, 작동하지 않으면 깔끔하게 버릴 수 있습니다. 전체 히스토리를 가진 전체 프로젝트를 다른 사람에게 넘길 수 있습니다. 두 사람이 같은 코드를 편집할 때 Git은 그들의 작업을 결합하고 의견이 다른 지점을 표시하여 사람이 해결할 수 있도록 합니다. 이 네 가지 능력(히스토리, 안전한 실험, 공유, 작업 결합)은 Git이 거의 모든 전문적인 코드베이스에서 실행되는 전체 이유입니다.

실제로는 팀이 그 타임라인에 지속적으로 의존합니다. 적절한 크기의 모든 변경은 자신의 브랜치에서 시작됩니다. 메인 코드를 방해하지 않고 작업할 수 있는 별도의 히스토리 라인입니다. 변경이 준비되면 누군가가 검토하고 메인 브랜치로 다시 병합됩니다. 검토, 브랜칭, 병합은 Git에서 작업하는 일상적인 리듬이며 모두 위의 스냅샷 타임라인에 기반합니다. 이 핸드북의 나머지 부분은 당신이 만나는 순서대로 각 부분을 안내합니다.

나중의 모든 것에 중요한 한 가지 세부 사항이 있습니다. 각 커밋은 추적되는 파일의 완전한 상태, 즉 그 순간의 완전한 스냅샷을 저장합니다. 사람들은 종종 Git이 버전 간의 차이만 저장하는 것으로 생각하지만, 내부적으로는 모든 커밋이 전체 프로젝트를 보유합니다. Git은 각각의 고유한 파일 내용을 한 번만 저장함으로써 이를 저렴하게 유지합니다. 따라서 변경되지 않은 파일을 재사용하는 커밋은 이미 저장된 복사본을 가리키기만 하고, 천 개의 파일이 하나 변경된 스냅샷은 다른 999개를 복제하지 않습니다. 각 커밋은 또한 그 앞에 온 커밋의 ID인 부모를 기록하며, 이것이 Git이 스냅샷을 역방향으로 이동할 수 있는 히스토리에 연결하는 방식입니다. 이 부모 링크는 거의 모든 것의 중추입니다. 브랜치, 병합, 히스토리 탐색은 모두 이 포인터를 따르는 것에 기반합니다. 히스토리 및 브랜치 장에서 전체 객체 모델을 보게 됩니다.

JunoGit이 당신을 위해 해주는 것 Git은 프로젝트를 커밋이라는 스냅샷 시리즈로 기록하며, 각각 무엇이 변경되었는지 말하는 메시지가 있습니다. 그 히스토리가 존재하면 그것을 되돌아보고, 안전하게 실험하고, 공유하고, 다른 사람과 작업을 결합할 수 있습니다. final_v2_ACTUAL 복사본의 더미는 Git이 끝내도록 만들어진 문제이며, 처음으로 하나를 삭제할 때 정말 좋은 기분이 든다고 약속합니다.

JunoGit이 당신을 위해 해주는 것 커밋은 스냅샷과 메시지이며, 히스토리는 그들의 타임라인입니다. 날마다 타임라인에서 분기하여 변경을 만들고, 검토받으며, 다시 병합합니다. 스냅샷의 성장하는 타임라인의 정신 모델을 머리에 유지하세요. 배우는 모든 명령은 그것에 추가하거나 그것에서 읽는 것 중 하나입니다.

JunoGit이 당신을 위해 해주는 것 각 커밋은 전체 프로젝트 상태를 저장하고 Git이 히스토리를 이동하는 방식인 부모를 가리킵니다. 동일한 파일 내용은 한 번 저장되고 커밋 간에 공유되므로 스냅샷은 저렴합니다. 부모-포인터 아이디어를 유지하세요. 브랜치와 병합은 다른 모자를 쓴 같은 아이디어입니다.

Git과 GitHub는 다른 것입니다

이것은 처음에 거의 모두를 혼동시키므로 여기 있습니다. Git은 버전 관리 도구입니다. 당신의 컴퓨터에서 실행되고, 커밋을 기록하며, 작동하기 위해 인터넷 연결이나 계정이 필요하지 않습니다. **GitHub**은 Git 저장소를 온라인으로 저장하고 그 주변에 것들을 추가하는 웹사이트입니다. 코드를 공유하고, 서로의 변경을 검토하고, 문제를 보고하고, 협업할 수 있는 장소입니다.

차이를 가장 명확하게 느끼려면: GitHub 계정을 만들지 않고도 매일 Git을 사용할 수 있습니다. 저장소를 공유하는 곳에 두어 다른 사람이나 다른 기계가 접근할 수 있도록 하려면 GitHub만 필요합니다. Git은 엔진입니다. GitHub는 그것이 생성하는 것을 호스팅할 수 있는 한 곳입니다. GitLab과 Bitbucket과 같은 다른 곳도 있으며, 모두 내부에 동일한 Git 저장소를 호스팅합니다.

두 가지가 함께 뭉쳐지는 이유는 대부분의 사람들이 첫 날에 GitHub에서 프로젝트를 복제하면서 Git과 GitHub를 동시에 만나기 때문입니다. 많은 사람들은 git push가 "GitHub로 보내기"를 의미한다고 생각하는데, 실제로는 "설정한 어떤 원격으로든 보내기"를 의미하며, 그 원격이 대부분의 경우 GitHub입니다. 두 가지를 머리에서 분리해두는 것은 Git을 다른 호스트와 함께 사용하거나 호스트 없이 사용하는 첫 번째 시간에 보상받습니다.

JunoGit과 GitHub는 다른 것입니다 Git은 커밋을 기록하는 당신의 컴퓨터의 도구입니다. GitHub는 사람들이 공유하고 검토할 수 있도록 Git 프로젝트를 온라인으로 저장하는 웹사이트입니다. GitHub 계정 없이도 Git을 사용할 수 있습니다. 이 페이지에서 한 가지만 기억한다면 이것이 되어야 합니다. 이들을 섞는 것은 초기 혼동을 많이 초래하기 때문입니다.

JunoGit과 GitHub는 다른 것입니다 Git은 당신 기계의 버전 관리 엔진입니다. GitHub는 GitLab과 Bitbucket과 함께 그것이 생성하는 것을 호스팅할 수 있는 인기 있는 한 곳입니다. git push는 설정한 어떤 원격으로든 보내며, 보통 습관상 GitHub입니다. 분할을 유지하면 프로젝트가 다른 곳에 있을 때 혼동되지 않습니다.

JunoGit과 GitHub는 다른 것입니다 Git은 커밋, 브랜치, 레프를 알고 있습니다. GitHub는 호스팅된 복사본 위에 풀 요청, 문제, 병합 버튼을 계층화합니다. GitHub가 추가하는 것은 Git 명령이 아니므로 웹사이트에서 풀 요청을 열고 git으로는 절대 열지 않습니다. 머리에서 두 가지를 분리해두면 GitHub 마법처럼 보이는 대부분의 것이 일반적인 레프로 돌아갑니다.

Git의 유래

Git의 역사는 왜 그런 식으로 작동하는지 많이 설명합니다. 2005년 Linux를 시작한 같은 사람인 Linus Torvalds가 작성했습니다. Linux 커널은 전 세계에 흩어져 있는 수천 명의 자원봉사자에 의해 만들어지며, 몇 년 동안 그들은 BitKeeper라는 상용 도구를 사용하여 그 모든 작업을 조정했고, 그 뒤에 있는 회사는 오픈소스 프로젝트가 무료로 사용하도록 허용했습니다.

2005년 그 무료 배치가 무너졌고, 커널 커뮤니티는 갑자기 거대하고 빠르게 움직이는 코드베이스를 관리할 도구가 없었습니다. 당시 이용 가능한 다른 것은 그 규모를 따라잡을 수 없었습니다. 그래서 Torvalds는 커널 작업에서 2주일을 물러났고 자신의 버전 관리 도구를 작성했으며, 정확히 그 문제로 형성된 몇 가지 확고한 목표가 있었습니다.

그는 그것이 분산되기를 원했으므로, 모든 기여자가 자신의 기계에 전체 프로젝트 히스토리를 가지고 있을 것이고 중앙 서버와 확인하지 않고 작업할 수 있을 것입니다. 그는 그것이 빠르기를 원했으며, 중앙 서버 없이는 사람들이 기다리지 않도록 충분히 빠릅니다. 그리고 그는 무결성을 보장하기를 원했으므로 아무도 조용히 히스토리를 변경할 수 없고 디스크 오류가 프로젝트를 손상시킬 수 없습니다.

이 목표들이 Git이 오늘날 작동하는 방식입니다. 프로젝트를 clone할 때 작업할 전체 히스토리를 얻으며, 이는 분산 목표입니다. 와이파이가 없는 비행기에서 커밋, 브랜치, 히스토리를 탐색할 수 있습니다. 그리고 모든 커밋은 정확한 내용에서 계산된 지문으로 표시되므로, 단 하나의 바이트가 변경되면 지문이 일치하지 않고 Git이 알아챕니다. Torvalds가 서둘러 2005년에 만든 설계 결정은 지금 Git을 사용할 때마다 의존하는 결정입니다.

무결성 보증이 전체 설계를 주도합니다. 모든 커밋은 해시, 커밋의 전체 내용(부모의 ID 포함)에서 계산된 고정 길이 지문으로 식별됩니다. 부모의 ID가 자녀의 해시에 들어가므로, 해시는 체인을 형성합니다. 오래된 커밋의 아무것이나 변경하면 그 해시가 변경되고, 그 뒤의 모든 커밋의 해시가 변경됩니다. 이것이 Git 히스토리를 변조 방지로 만드는 것입니다. 또한 커밋의 ID가 정확한 내용의 지문이라는 것을 의미하며, 이것이 a1b2c3d 같은 16진수 문자열이 보이는 이유이며, 깔끔한 커밋 번호 42 대신입니다.

JunoGit의 유래 Linus Torvalds는 2005년에 Linux 커널을 위해 Git을 작성했습니다. 프로젝트가 사용했던 도구가 무료가 되는 것을 멈추었을 때입니다. 그는 그것을 분산되고, 빠르고, 손상으로부터 안전하도록 만들었습니다. 이것이 clone이 오프라인으로 작업할 전체 히스토리를 제공하는 이유이고, 모든 커밋이 지문을 얻는 이유입니다. 수년간 사용할 도구에 대한 편리한 배경입니다.

JunoGit의 유래 Git은 2005년 Linux 커널에서 나왔으며, 중앙 서버가 없는 수천 명의 기여자를 위해 만들어졌습니다. 이것이 전체 모델이 분산되는 이유입니다. 모든 복제는 전체 히스토리를 휴대하므로, 로컬로 브랜치하고 커밋하고 선택할 때 동기화합니다. Git 기본값이 이상해 보일 때 "커널을 위해 설계되었습니다"는 보통 그것을 설명합니다.

JunoGit의 유래 Git은 2005년 Torvalds의 2주 스프린트에서 나왔습니다. 커널이 BitKeeper에 대한 액세스를 잃었을 때, 3가지 목표가 있었습니다. 분산, 빠름, 무결성 확인. 각 커밋의 해시는 그 내용과 부모의 해시에서 계산되므로, ID는 변조 방지 체인을 형성합니다. Git이 어떤 선택을 만든 이유를 궁금해하면 "Linux 커널용으로 만들어졌습니다"가 보통 답변입니다.

이 핸드북이 다음으로 가는 곳

정신 모델이 준비되면, 트랙의 나머지는 작업을 수행하는 것입니다. 당신의 첫 번째 저장소는 0에서 시작합니다. 터미널을 열고, Git이 설치되어 있지 않으면 설치하고, 폴더를 커밋할 수 있는 저장소로 변환합니다. 거기에서 변경을 저장하는 일상적인 루프, 브랜칭, 병합, GitHub에서의 협업 흐름을 배우게 됩니다. 용어가 항상 당신을 혼동시키면, 용어집에는 이 문서의 모든 Git 어휘에 대한 짧은 정의가 있습니다.