첫 번째 저장소

docs.scrimba.com

보통 두 가지 경우 중 하나로 여기에 도달합니다. 이미 로컬에서 구축 중인 weather-app 같은 프로젝트 폴더가 있어서 Git이 그 히스토리를 기록하기를 원하거나, 또는 다른 사람이 이미 프로젝트를 만들어서 GitHub에 있고 당신이 자신의 머신에서 작업 사본을 원하는 경우입니다. 둘 다 세 가지 작은 명령으로 시작하며, 이 장이 끝날 때쯤 세 명령 모두를 실제로 사용해 봤을 것입니다. 하지만 먼저 10초 정도 걸리는 확인 작업이 있습니다. 당신의 머신에 Git이 설치되어 있는지 확인하는 것입니다.

Git이 설치되어 있나요?

이 핸드북의 모든 것은 터미널에서 일어나므로, 먼저 터미널을 열어야 합니다. **터미널**은 텍스트로 명령을 입력하고 프로그램이 텍스트로 응답하는 앱입니다. 이미 당신의 컴퓨터에 있습니다:

• macOS: 앱 이름은 Terminal입니다. Cmd+Space를 누르고 "terminal"을 입력한 후 Enter를 누르세요.
• Windows: 지금은 PowerShell을 열어주세요 (시작 메뉴에서 "powershell"을 검색하세요). 아래에서 Git을 설치하면 Git Bash도 추가되는데, 이것은 이 작업을 위해 특별히 만들어진 터미널이며, 둘 다 동일한 Git 명령을 실행합니다.
• Linux: Terminal 또는 Console이라는 이름의 앱을 찾으세요. 많은 배포판에서 Ctrl+Alt+T가 이를 엽니다.

Git 자체는 명령줄 프로그램입니다. 자신의 창이 없으며 git이라는 단어로 시작하는 명령을 입력하고 출력을 읽음으로써 사용합니다. 이 핸드북의 모든 코드 블록도 같은 방식으로 읽습니다. $로 시작하는 줄은 입력하는 명령($ 자체는 제외)이고, 아래의 줄들은 Git의 응답입니다.

확인해 봅시다. 터미널에 다음을 입력하고 Enter를 누르세요:

$ git --version
git version 2.45.1

버전 번호가 반환되면 Git이 설치되어 있고 준비가 완료된 것입니다. 당신의 번호는 이것과 다를 가능성이 높으며, 그것은 괜찮습니다. 대신 "command not found" 또는 "git is not recognized"를 보면 Git이 아직 설치되지 않았으며, 설치는 일회성 작업입니다:

• macOS: git --version을 실행하면 보통 Apple의 Command Line Tools 설치를 제시하는 대화상자가 나타납니다. 수락하면 macOS가 Git을 설치해줍니다.
• Windows: git-scm.com/downloads에서 Git for Windows를 다운로드하고 설치 프로그램을 실행하세요. 기본값은 모두 합리적인 선택이며, Git Bash도 함께 설치됩니다.
• Linux: 배포판의 패키지 관리자로 git 패키지를 설치하세요. 예를 들어 Ubuntu와 Debian에서는 sudo apt install git입니다.

설치가 완료되면 터미널을 닫고 새로운 터미널을 열어서 git --version을 다시 실행하세요. 버전 번호가 나타나면 설정은 완료되었으며, 이 핸드북의 나머지 부분에서는 설치할 것이 없습니다.

버전 번호는 보이는 것보다 조금 더 중요합니다. 이 핸드북은 2019년 Git 2.23에서 나타난 최신 동사 git switch와 git restore를 사용하므로, 매우 오래된 사전 설치된 Git이 있는 머신은 올바른 예제에서 "not a git command"를 만날 수 있습니다. 지난 몇 년의 모든 Git에는 이들이 있으며, 당신의 버전이 2.23보다 오래되었다면 위에 나열된 동일한 장소에서 업데이트하세요.

또한 당신은 그래픽 Git 도구를 만날 것입니다. GitHub Desktop, VS Code의 Git 패널, 대부분의 에디터에 내장된 지원. 이들은 모두 이 동일한 Git 프로그램을 내부에서 실행하는 프런트엔드입니다. 먼저 명령을 배우면 거기서도 좋은 성과를 거두게 됩니다. 왜냐하면 이런 도구의 모든 버튼은 당신이 이미 이해하는 명령에 매핑되기 때문입니다.

Git은 단일 자체 포함 프로그램이지, 서비스가 아닙니다. 백그라운드에서 실행되는 것이 없고, 폴더를 감시하는 것이 없으며, 로그인할 계정이 없습니다. 모든 명령은 시작되고, 저장소 내의 파일을 읽거나 쓰고, 답변을 출력한 후 종료됩니다. 이것이 모든 것이 오프라인에서 작동하는 이유입니다. which git을 실행하세요 (Windows에서는 where git). 프로그램이 정확히 어디에 있는지 볼 수 있습니다.

알아두면 좋은 한 가지 플랫폼 특이점은 macOS에서 Apple이 Command Line Tools와 함께 자체 Git 빌드를 배포하는데, 보통 git-scm.com의 최신 릴리스보다 한두 버전 뒤쳐져 있다는 것입니다. 이 핸드북의 모든 것과 일상 작업의 거의 모든 것에서 이 격차는 문제가 되지 않습니다.

JunoGit이 설치되어 있나요? Git은 터미널에 명령을 입력해서 대화하는 프로그램이며, git --version은 당신의 머신에 설치되어 있는지 알려줍니다. 버전 번호는 준비가 완료되었다는 의미이고 "command not found"는 git-scm.com이나 시스템 설치 프로그램에서 설치해야 한다는 의미입니다. 이 부분은 한 번만 수행합니다. 설정은 모든 핸드북에서 가장 재미없는 부분이므로, 잘 해냈습니다!

JunoGit이 설치되어 있나요?git --version은 한 줄로 설치 질문을 해결합니다. 합리적으로 최근의 모든 것이 작동하지만, 이 핸드북이 사용하는 switch와 restore 동사는 Git 2.23 이상이 필요하므로, 그보다 뒤처져 있다면 업데이트하세요. GitHub Desktop 같은 GUI 도구는 이 동일한 프로그램을 내부에서 실행하므로, 여기서 배운 모든 것이 무료로 전송됩니다.

JunoGit이 설치되어 있나요? Git은 데몬이 없고 계정도 없는 하나의 로컬 프로그램입니다. 입력하면 실행되고, 저장소의 파일을 건드리고, 종료되므로, 모든 것이 오프라인에서 작동합니다. which git은 바이너리의 위치를 보여줍니다. Apple의 번들 빌드는 최신 릴리스보다 한두 버전 뒤처져 있으며, 14년 동안 이 격차는 저에게 아무것도 비용이 들지 않았습니다.

폴더를 저장소로 변환하기

터미널을 열고 cd를 사용해 프로젝트 폴더로 이동한 후 (cd는 "change directory"의 줄임말), 한 가지 명령 git init을 실행하세요:

$ cd weather-app
$ git init
Initialized empty Git repository in /Users/mara/projects/weather-app/.git/

이 폴더는 이제 **저장소**입니다. Git이 감시하는 프로젝트로, 작업하면서 그 스냅샷을 기록할 준비가 되어 있습니다. git init은 매번 같은 작업을 수행합니다. 숨겨진 .git 폴더를 찾고, 없으면 만들고, 그 시점부터 폴더는 Git의 감시 대상이 됩니다.

새 저장소의 기본 브랜치는 main이라고 합니다. 오래된 튜토리얼, 오래된 저장소, 또는 몇 년 전에 기록된 코스에서 정확히 같은 것에 대해 master를 사용한 것을 볼 수 있습니다. 이것은 오래된 이름으로 같은 첫 브랜치입니다. 이 핸드북은 항상 main을 사용합니다.

브랜치란 무엇인가요?

브랜치는 당신의 커밋이 착륙할 별도의 히스토리 라인이며, main은 모든 새 저장소가 시작하는 것입니다. Branches는 이들을 생성하고 전환하는 것을 다룹니다.

git init은 폴더가 비어 있는지 관계없이 작동합니다. 이미 index.html과 src/ 폴더가 있는 weather-app 내부에서 실행하면 Git은 현재 상태에서 그 프로젝트를 추적하기 시작합니다. 기존 파일은 변경되지 않습니다. 같은 저장소에서 두 번째로 git init을 실행하는 것도 해로움이 없습니다. Git은 .git 폴더가 이미 존재한다는 것을 알고, 이미 가지고 있는 히스토리를 건드리지 않으면서 제자리에서 다시 초기화하므로, 습관에서 다시 실행하는 것은 아무 비용이 들지 않습니다.

git init은 한 가지를 수행합니다. 이 장 뒤에서 자세히 설명할 .git 폴더를 만듭니다. 저장소에 대한 모든 것 (히스토리, 설정, refs)은 init이 생성하는 순간부터 그 폴더 내부에 있습니다. 프로젝트에서 보고 편집하는 파일은 추적되는 것의 작업 복사본이며, .git 폴더는 저장소 자체입니다.

Juno폴더를 저장소로 변환하기git init은 모든 폴더를 Git 저장소로 변환하여 Git이 추적을 시작할 준비를 합니다. 프로젝트 폴더 내부에서 한 번 실행하면 설정이 완료되며, 나중에 다시 실행해도 해롭지 않습니다. 새 저장소의 기본 브랜치는 main이라고 하지만, 외부에서 찾은 오래된 것들은 종종 같은 의미로 master라고 불립니다.

Juno폴더를 저장소로 변환하기git init은 빈 폴더에서든 이미 파일로 가득 찬 폴더에서든 작동하며, 이미 설정한 저장소에서 다시 실행해도 손상이 없습니다. 기본 브랜치 이름은 main입니다. 오래된 것들에서는 master를 기대하세요.

Juno폴더를 저장소로 변환하기git init은 .git 폴더만 만들 뿐인데, 이것이 실제 저장소입니다. 당신의 작업 파일은 그것이 추적하는 것의 체크아웃입니다. 당신의 작업 파일과 그들을 추적하는 .git 폴더 사이의 이 분할을 기억하세요.

Git에 당신이 누구인지 알려주기

첫 번째 커밋 전에 Git은 누가 만드는지 알고 싶어합니다. 두 가지 값을 한 번 설정하면 Git은 이 머신에서 만드는 모든 커밋에 대해 이를 기억합니다:

$ git config --global user.name "마라 첸"
$ git config --global user.email "[email protected]"

만드는 모든 커밋에 그 이름과 이메일이 스탬프됩니다. 이 단계를 건너뛰면 Git은 컴퓨터의 사용자 이름과 호스트 이름에서 추측한 것으로 대체되므로, 당신의 커밋은 당신이 선택하지 않은 신원을 갖습니다.

첫 번째 커밋 전에 이름과 이메일을 설정하세요. 먼저 커밋하고 나중에 설정하면, 실수가 그 커밋의 히스토리에 구워집니다. 더 나쁜 것은 GitHub를 포함한 일부 호스트가 이메일로 커밋을 당신의 계정과 일치시키므로, 잘못된 주소나 추측된 주소로 만든 커밋이 당신의 것이 아니라 익명의 낯선 사람의 작업으로 표시된다는 것입니다.

--global 플래그는 **구성 범위**를 설정합니다. --global은 머신의 모든 곳에 적용되는 반면 --local은 실행하는 저장소에만 적용됩니다. 이를 통해 설정을 계층화할 수 있습니다. 전역 이메일은 기본적으로 모든 저장소를 다루고, 특정 저장소의 --local 오버라이드는 거기서만 우선적으로 적용되며, 다른 곳에서는 적용되지 않습니다. 이는 업무 프로젝트가 개인 프로젝트와 다른 주소를 필요로 할 때 유용합니다:

$ cd weather-app
$ git config --local user.email "[email protected]"
$ git config user.email
[email protected]

범위 플래그 없이 git config user.email을 실행하면 여기에 실제로 적용되는 값을 읽습니다. 설정한 로컬 값이 있으면 그것이고, 없으면 전역 값입니다.

두 범위 모두 Git이 고정된 순서로 읽는 텍스트 파일입니다. 전역 파일은 홈 폴더의 ~/.gitconfig에 있으며, 로컬 파일은 저장소 자체의 .git 폴더 내, .git/config에 있습니다. Git은 로컬 설정을 먼저 읽고 전역 설정을 오버라이드하도록 하는데, 이것이 전체 계층화 메커니즘으로, 당신이 직접 열어서 읽을 수 있는 텍스트 파일에 공개되어 있습니다.

JunoGit에 당신이 누구인지 알려주기git config --global user.name과 git config --global user.email은 Git이 당신이 만드는 모든 커밋에 스탬프하는 이름과 이메일을 설정합니다. 첫 번째 커밋 전에 설정하세요. 이메일을 설정하기 전에 만든 커밋은 추측된 신원으로 귀속되며, GitHub 같은 호스트가 이를 당신의 계정에 연결할 수 없을 수도 있습니다. 한 번 수행하면 머신의 모든 저장소가 이를 기억합니다.

JunoGit에 당신이 누구인지 알려주기--global은 머신의 모든 저장소에 적용되고, --local은 현재 저장소에만 오버라이드하므로, 개인 이메일과 업무 이메일을 분리할 때 유용합니다. 둘 다 설정되어 있으면 로컬이 우선이며, git config user.email은 주어진 저장소에서 실제로 활성화된 값을 알려줍니다.

JunoGit에 당신이 누구인지 알려주기 구성 범위는 계층화된 텍스트 파일입니다. 전역은 ~/.gitconfig에 있고, 로컬은 저장소 내 .git/config에 있으며, 둘 다 값을 설정하면 로컬이 우선합니다. 이메일 설정을 건너뛰면 Git은 사용자 이름과 머신 이름에서 구축된 추측된 신원으로 대체되므로, 낯선 이름으로 떠도는 커밋은 거의 항상 누락된 user.email로 추적됩니다.

git clone으로 기존 프로젝트 복사하기

때때로 프로젝트가 이미 다른 곳에 존재하고, 당신이 머신에서 작업 복사본을 원합니다. git clone이 한 명령으로 이를 수행합니다:

$ git clone https://github.com/octocat/Hello-World.git
Cloning into 'Hello-World'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
Receiving objects: 100% (13/13), done.

Git은 Hello-World라는 이름의 새 폴더를 만들고, 프로젝트의 전체 히스토리를 다운로드하고, 폴더에 파일을 배치하여 즉시 읽거나 편집을 시작할 수 있습니다. 별도의 git init 단계는 필요하지 않습니다. 복제는 다운로드의 일부로 저장소를 설정해줍니다.

프로젝트가 이미 존재하고 연결된 복사본을 원할 때 git clone을 사용하세요. 아직 어디에도 존재하지 않는 새로운 것을 시작할 때 git init을 사용하세요. 복제는 또한 origin이라는 이름으로 복제 위치로의 연결을 연결하는데, 이는 init 단독으로는 절대 수행하지 않습니다. 이 연결은 나중 장에서 커밋을 보내고 받는 데 사용합니다.

복제는 프로젝트의 전체 히스토리 (이전에 가진 모든 커밋)를 가져오고 머신의 전체 .git 폴더를 채우는데, git init은 이를 비어두게 남깁니다. 오래된 히스토리가 있는 프로젝트의 복제는 정확히 이 이유로 순간이 걸릴 수 있지만, 나중에 보이는 것은 최신 파일의 스냅샷처럼 보입니다.

Junogit clone으로 기존 프로젝트 복사하기git clone <url>은 누군가의 저장소를 전체 히스토리 포함해 프로젝트의 이름을 따서 만든 새 폴더로 다운로드합니다. 프로젝트가 이미 어디에나 존재할 때 이를 사용하세요. 처음부터 하나를 시작할 때 git init을 사용하세요. 복제가 완료되면 전체 작업 복사본이 있어서 살펴보거나 추가하기 위해 준비가 됩니다.

Junogit clone으로 기존 프로젝트 복사하기 프로젝트가 이미 어디에나 있고 연결된 복사본을 원할 때 복제하세요. 아무 것도 없을 때 초기화하세요. 복제는 origin이라는 이름으로 복제 위치로의 연결을 자동으로 연결하는데, init 단독으로는 이를 설정하지 않습니다.

Junogit clone으로 기존 프로젝트 복사하기 복제는 프로젝트가 전에 가진 모든 커밋으로 전체 .git 폴더를 재생성합니다. 여기에는 전체 히스토리가 포함되어 있어서 오래된 프로젝트가 복제하는 데 순간이 걸릴 수 있습니다. 그러나 나중에 현재 파일만 보이더라도 그렇습니다.

숨겨진 .git 폴더 내부는 무엇인가요

git init 또는 git clone으로 도달했는지 여부에 관계없이 모든 저장소에는 루트에 .git이라는 숨겨진 폴더가 있습니다. 기본적으로 숨겨져 있으므로 터미널에 ls -a를 입력하여 전체 목록을 요청하세요 (ls는 폴더의 내용을 나열하고, -a는 숨겨진 항목을 포함합니다). 일반 프로젝트 파일과 함께 있을 수 있습니다:

$ ls -a
.  ..  .git  README.md  src

그 폴더가 실제 저장소입니다. 이는 만든 모든 커밋, 브랜치, 위 섹션의 구성 설정을 유지합니다. .git 폴더를 삭제하면 프로젝트는 전체 히스토리를 잃습니다. 이것은 Git이 더 이상 추적하지 않는 일반 폴더로 되돌아갑니다. 프로젝트의 다른 모든 것은 .git이 유지하는 것의 작업 복사본입니다.

내부를 보면 몇 가지 인식할 수 있는 조각을 찾을 수 있습니다. config 파일 (위의 섹션의 로컬 설정), HEAD 파일, objects와 refs라는 폴더. 손으로 이들을 열거나 편집할 필요는 없지만, 이름을 인식하면 오류 메시지나 검색 결과에서 나타날 때 도움이 됩니다.

이들 이름 중 일부는 제대로 알 가치가 있습니다. objects 폴더는 저장소의 **객체 데이터베이스**입니다. 파일 이름이 아니라 내용 자체로 주소가 지정된 모든 파일의 모든 버전과 만든 모든 커밋, 압축 및 저장됩니다. refs 폴더는 브랜치를 유지하는데, 각각은 커밋 id를 가리키는 작은 파일입니다. HEAD는 현재 체크아웃한 브랜치를 기록하는 단일 파일입니다. config는 위에서 다룬 로컬 설정 파일입니다.

이 중 어느 것도 일상적으로 손으로 편집하는 것은 아닙니다. 전체 히스토리가 일반 텍스트 파일로 어딘가의 서버에 숨겨져 있지 않고 디스크에 있는 것을 보면, 복제가 최신 파일만이 아니라 전체 히스토리를 제공하는 이유와, .git을 삭제하면 정리되지 않고 모든 커밋을 지우는 이유를 설명합니다.

Juno숨겨진 .git 폴더 내부는 무엇인가요 모든 저장소에는 루트에 숨겨진 .git 폴더가 있으며, 그 폴더가 실제 저장소입니다. 전체 히스토리와 설정이 거기에 있습니다. 기본적으로 숨겨져 있으므로 프로젝트 내부에서 ls -a를 실행하여 보세요. 프로젝트의 전체 히스토리를 삭제하고 싶지 않으면 절대 삭제하지 마세요. 삭제하면 폴더가 Git이 더 이상 추적하지 않는 평범한 폴더로 변환됩니다.

Juno숨겨진 .git 폴더 내부는 무엇인가요.git 내부에서 config 파일 (로컬 설정), HEAD 파일, objects와 refs 폴더를 인식할 것입니다. 일상적으로 손으로 이들을 건드리지 않지만, 이름은 오류 메시지와 Git 문서에서 나타납니다. 복제는 이 전체 폴더를 복사하므로, 복제는 최신 파일만이 아니라 전체 히스토리를 사용해 도달합니다.

Juno숨겨진 .git 폴더 내부는 무엇인가요objects는 저장소의 객체 데이터베이스로, 모든 파일의 모든 버전과 커밋을 내용보다는 파일 이름으로 주소가 지정된 것으로 유지합니다. refs는 커밋 id를 가리키는 평문 파일로 브랜치를 유지하며, HEAD는 체크아웃한 것을 기록합니다. 거기에 아무 것도 손으로 편집할 필요가 없지만, 평문 파일로 디스크에 있는 것을 보면 복제가 전체 오프라인 히스토리를 제공하는 이유와 .git 삭제가 정리가 아니라 모든 것을 지우는 이유를 설명합니다.

저장소와 커밋 용어가 여전히 모호하다면, Git이란 무엇입니까는 이 명령이 구축하는 정신 모델을 다루며, 용어집은 이 장의 모든 어휘 조각에 대한 짧은 정의를 제공합니다. 당신의 신원이 설정되고 작업할 저장소가 있으면, 커밋 루프는 당신이 이제부터 지속적으로 사용할 편집, 스테이징, 커밋의 일상 주기를 다룹니다.