의도한 스냅샷을 준비하고 첫 번째 커밋을 수행합니다.

• GitTree에 처음 두 개의 프로젝트 파일을 생성하고 저장합니다.
• 작업 파일 삭제와 혼동하지 않고 스테이지 및 언스테이징할 수 있습니다.
• 커밋하기 전에 인덱스를 작업 트리와 비교하십시오.
• 유용한 요약을 작성하고 준비된 스냅샷만 커밋하세요.
• 첫 번째 커밋의 파일, ID 및 나머지 작업 변경 사항을 확인합니다.

4과가 끝나는 곳에서 시작하세요. original gittree-features은 커밋, 프로젝트 파일 또는 원격이 없는 아직 태어나지 않은 main의 일반 저장소입니다. 로컬 ID는 GitTree Demo / deco@example.com입니다. 4과의 보충 gittree-features-copy 내부에서 계속하지 마십시오.

GitTree의 검사된 최소값은 Git 2.39.0입니다. 비디오는 Ubuntu 24.04에서 Git 2.52.0 및 GitTree 2.0을 사용하여 녹화되었습니다. 두 파일, 해당 파일의 스테이징 및 첫 번째 커밋이 앱 자체에서 만들어졌으며 터미널 확인은 앱이 생성한 내용이나 A, B 및 C 상태의 프로젝트의 별도 복사본에 대해 실행되었으므로 원본은 재생되지 않았습니다. macOS 또는 Windows에서는 아무것도 실행되지 않았으며 Ubuntu는 기록된 유일한 Linux 시스템입니다. 명령 키와 Windows 코드는 키맵 소스에서 나옵니다.

기본 Git에는 로컬 커밋에 대한 계정이 필요하지 않습니다. GitTree에서 로그인하면 무료 플랜으로 이 강의를 다룹니다. 공급자, Pro/평가판, AI 초안, API 키, CI 실행기 또는 클라우드 환경이 필요하지 않습니다. 로컬 커밋을 수행하기 위해 원격을 추가하지 마세요.

커밋은 "보이는 모든 것을 저장"하는 것이 아닙니다. 이 강의에서 일반 커밋은 선택된 전체 스냅샷인 index을 기록합니다. 루트 커밋을 생성하고 이에 대한 주요 포인트를 만듭니다. 아무데도 밀지 않습니다.

편집기에서 저장하면 working tree이(가) 업데이트됩니다. 스테이징은 선택한 작업 파일에서 인덱스를 업데이트합니다. Unstaging은 인덱스 선택을 변경합니다. 이는 폐기되지 않으며 우리 연습에서 작업 파일을 제거하지 않습니다. 첫 번째 커밋 전에는 복원할 이전 커밋 버전이 없으므로 준비되지 않은 새 파일은 다시 추적되지 않습니다.

준비된 판은 유용한 비유입니다. 판을 준비한 후 작업 초안을 수정한 다음 최신 초안을 포함하지 않고 준비된 판을 로컬로 게시할 수 있습니다. 스테이징은 후속 편집에 대한 실시간 구독이 아닙니다. Git의 추가 참조는 해당 선택을 문서화합니다. 커밋 참조는 일반 인덱스 커밋을 다른 모드와 구별합니다.

우리는 no -a, 명시적 커밋 경로 인수, 수정, 빈 커밋 또는 자동 stage-all을 사용합니다. 색인은 단지 변경된 이름 목록이 아니라 전체 다음 트리 설명입니다.

README-01도 준비되어 커밋되었습니다. D 이후에는 README가 깨끗합니다. index.html은 의도적으로 작업 트리에서만 수정된 상태로 유지됩니다. 상태가 깨끗하지 않은 동안 그래프에 새로운 커밋이 있을 수 있습니다.

UTF-8, LF 및 마지막 개행 문자 하나를 사용하세요. 저장된 파일에 Markdown 펜스를 포함하지 마세요. package.json, CSS, JS 또는 실행 가능한 Node 제품군은 아직 없습니다. 그것들은 6과에 도착합니다.

README.md - README-01

# GitTree Features

A fictional landing page used to learn Git and GitTree.

All people and addresses in this repository are fictional.
No form submits information to a server.

index.html — HTML-01, 스테이징 전

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">A clear view of Git history.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

index.html — HTML-01-WORKING, 스테이징 이후에만

저장된 작업 파일을 이전 버전이 색인에 입력한 이 전체 본문 after으로 바꾸세요.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

단일 의도된 교체는 Hero-Copy 지원 라인입니다. 기본 제목이나 다른 바이트를 변경하지 마십시오.

1. 두 개의 초기 파일을 생성하고 저장합니다.

1. 원본 저장소의 이름과 기본 컨텍스트를 확인하세요. Command Palette…, Command+Shift+P / Ctrl+Shift+P를 열고 New File…를 입력한 후 정확한 명령(files.newFile)을 선택합니다. 폴더 인수가 없으면 프로젝트 루트에서 시작됩니다.
2. New File에서 Path from the project folder를 README.md로 설정한 다음 Create을 선택합니다. 파일 작업 공간에서 새 작업 파일이 열릴 것으로 예상합니다. 생성은 기존 경로를 덮어쓰는 대신 기존 경로를 거부합니다.
3. 편집 가능한 콘텐츠 영역에 초점을 맞추고 전체 README-01 본문을 붙여넣은 다음 Save을(를) 선택합니다. 대안: 작업 중인 편집기에 포커스가 있는 동안 Command+S / Ctrl+S. 실제 저장이 성공한 후에는 Unsaved changes 표시가 지워질 것으로 예상됩니다.
4. New File… → 경로 index.html → Create를 반복합니다. 나중에 작동하는 변형이 아닌 전체 HTML-01를 붙여넣습니다. 저장하고 저장되지 않은 표시가 사라질 때까지 기다립니다.
5. 파일 도구 모음에서 Back to Graph를 선택하거나 팔레트 명령 Back to Graph(view.returnToGraph)을 선택합니다. 그런 다음 팔레트 Show Working Changes (wip.show)를 사용하세요. Unstaged Files 아래에 README.md 및 index.html이 있고 Staged Files 아래에는 아무것도 없습니다.
6. 아무것도 준비되지 않은 동안 기본 작성기 버튼인 경우 Stage Changes to Commit에 주목하세요. 소스 정의 작업 단계 all 작업 변경; 이미 성공적인 커밋을 의미하는 것은 아닙니다. 대신 의도적인 파일별 스테이징을 사용합니다.

편집기 버퍼를 저장하는 것은 준비가 아닙니다. 탭에 있는 파일이 최신 버퍼가 디스크에 도달했다는 증거는 아닙니다.

2. 안전하게 스테이지하고 언스테이징한 다음 두 파일을 모두 준비합니다.

1. Unstaged Files 아래의 README.md의 경우 해당 Stage File 행 작업을 사용하세요. 키보드 대안: 해당 행만 선택하고 스테이지되지 않은 목록에 초점을 유지한 다음 S을 누르십시오. 팔레트 명령은 Stage (wip.stageSelected)입니다. Staged Files 아래에 README.md가 있어야 합니다.
2. Staged Files 아래의 README 행에서 Unstage File을 선택합니다. 키보드 대안: 키보드만 선택하고 준비된 목록에 초점을 맞춘 다음 U를 누르세요. 팔레트 명령 Unstage (wip.unstageSelected). README.md가 Unstaged Files로 돌아갈 것으로 예상합니다. 작업 내용은 그대로 유지됩니다.
3. README.md를 다시 스테이지한 다음 Stage File 작업을 사용하여 index.html을 스테이지합니다. 정확히 two 단계의 파일 경로가 필요합니다.
4. 각 단계의 행을 클릭하여 전체 추가 내용을 검사하세요. index.html에는 여전히 A clear view of Git history.이(가) 포함되어야 합니다. 파일 개수만으로 내용을 추론하지 마세요.

단일 문자 단축키는 편집기나 요약에 S/U를 입력하라는 요청이 아니라 해당 목록으로 범위가 지정됩니다. 드래그 앤 드롭 스테이징 동작은 가정되지 않습니다.

3. 준비하지 않고 나중에 편집한 내용을 저장합니다.

1. Show Files (files.focus), Command+Shift+E / Ctrl+Shift+E을(를) 엽니다. 파일 트리에서 index.html에 초점을 맞추고 Enter를 눌러 작업 복사본을 엽니다. 대안: 기존에 저장된 작업 파일 탭을 클릭합니다. 기록 blob이나 단계적 diff가 아닌 편집 가능한 File 보기에서 작업하세요.
2. 전체 콘텐츠를 위의 HTML-01-WORKING로 바꾸세요. Save 또는 Command/Ctrl+S를 통해 저장하세요. 실제 디스크 저장이 성공할 때까지 기다립니다.
3. Back to Graph을(를) 통해 돌아온 후 Show Working Changes을(를) 통해 돌아옵니다. index.html이 이제 both 목록에 나타납니다. Unstaged Files 행을 클릭하세요. diff에는 나중에 지원 라인 교체가 표시됩니다.
4. Staged Files 행을 클릭합니다. 첫 번째 커밋 추가에는 여전히 이전 지원 라인이 포함됩니다. 최신 작업 편집을 위해 not 스테이지 파일을 선택하거나 지금 Stage All Changes을 선택하세요. 그러면 준비 중인 커밋이 변경됩니다.

4. 메시지 작성 및 인덱스 커밋

1. 작성기 Summary 필드(자리 표시자 Commit summary)에 정확히 feat: add the GitTree Features hero을(를) 입력합니다. Description은(는) 비워 두세요. 이 요약에는 변경된 내용이 나와 있습니다. 완성된 사이트나 테스트 스위트 통과를 약속하지 않습니다.
2. Amend Previous Commit을(를) 꺼두세요. Commit Options을 확장하고 Skip Hooks (--no-verify), Add Signed-off-by, Different Author, Push After Commit 및 Allow Empty Commit이 모두 꺼져 있는지 확인합니다. 공동저자를 추가하거나 AI 제도를 호출하지 마세요.
3. 두 가지 단계적 경로와 앞서 준비한 영웅 라인을 마지막으로 한 번 검토해 보세요. Commit Changes to 2 Files을(를) 선택하세요. 키보드 대체: Command+Enter / Ctrl+Enter, 활성 저장소 및 보류 상태를 확인한 후에만 팔레트 명령 Commit(commit.submit)을 통해 라우팅됩니다.
4. Git의 실제 결과를 기다립니다. 성공적인 결과는 측정된 SHA를 참조합니다. 다이어그램에서 조작된 SHA를 복사하지 마십시오. 메인에서 첫 번째 그래프 커밋을 기대합니다. 이 변경되지 않은 제출의 경우 성공 후 메시지 초안이 지워집니다.
5. 커밋 후 목록을 검사합니다. 아직 준비된 것이 없습니다. index.html은 이후 줄의 Unstaged Files 아래에 남아 있습니다. 이 의도적인 결과를 "완료"하려면 not 단계 변경을 클릭하여 커밋하세요.

표시된 파일 수는 두 목록의 세 행이 아닌 두 개의 단계적 경로입니다. Push After Commit은 별도의 후속 선택입니다. 꺼져 있고 리모컨이 없습니다.

<course-parent>/gittree-features에서 실행하여 자리 표시자를 예약된 실제 상위 항목으로 바꿉니다. 이미 앱 변형을 수행한 경우, inspect its resulting state; 동등한 돌연변이를 재생하지 말고 실수로 체크포인트를 넘어 진행하지 마십시오.

스테이징 전 저장된 파일

git status --short

관찰됨:

?? README.md
?? index.html

단계적 콘텐츠 없이 의도적으로 일반 커밋을 시도합니다.

git commit --quiet -m "feat: add the GitTree Features hero"

종료 1가 있는 stdout이 관찰되었으며 stderr은 없습니다.

On branch main

Initial commit

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

nothing added to commit but untracked files present (use "git add" to track)

커밋이 생성되지 않았습니다. 이 부정적인 사례는 파일 선택이 중요한 이유를 설명합니다. 이를 우회하기 위해 빈 커밋을 사용하지 마십시오.

기본 스테이지/언스테이지 등가물

동일한 저장된 파일 상태를 별도로 재생하는 경우:

git add -- README.md
git rm --cached --quiet -- README.md

두 명령 모두 자동으로 성공했습니다. --cached는 필수입니다. 색인 not the working file에서 새 항목을 제거합니다. 확인된 README 바이트는 변경되지 않은 상태로 유지되었으며 짧은 상태에서는 추적되지 않은 두 개의 파일이 다시 표시되었습니다. 이는 특히 커밋되지 않은 새 파일의 예입니다. 추적된 프로젝트 파일을 삭제하는 것으로 일반화하지 마십시오.

다음 두 가지를 모두 준비하세요.

git add -- README.md index.html
git status --short
git diff --cached --stat

관찰된 상태:

A  README.md
A  index.html

관찰된 요약:

 README.md  |  6 ++++++
 index.html | 21 +++++++++++++++++++++
 2 files changed, 27 insertions(+)

통계 요약은 정확성이 아닌 행 수를 계산합니다. 커밋하기 전에 실제 준비된 콘텐츠를 검토하세요.

나중에 작업한 편집 내용을 저장한 후

git status --short
git diff -- index.html

관찰된 상태:

A  README.md
AM index.html

관찰된 작업 차이:

diff --git a/index.html b/index.html
index 5470374..27f8718 100644
--- a/index.html
+++ b/index.html
@@ -13,7 +13,7 @@
     <section class="hero" aria-labelledby="hero-title">
       <p class="eyebrow">GitTree Learn demo project</p>
       <h1 id="hero-title">Understand every change.</h1>
-      <p id="hero-copy">A clear view of Git history.</p>
+      <p id="hero-copy">Choose one change, then check what Git saved.</p>
     </section>
   </main>
   <footer><p>Built by a fictional team for GitTree Learn.</p></footer>

이는 허구의 커밋 SHA가 아닌 정확한 LF 콘텐츠에서 측정된 파일 blob 약어입니다. 짧은 상태의 간격과 약어 길이는 형식 구성에 따라 달라질 수 있습니다. 두 비교는 동일하게 유지되어야 합니다.

정확하게 준비된 파일을 읽으십시오.

git show :index.html

관찰된 전체 출력:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">A clear view of Git history.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

커밋 및 확인

기본 재생에서만, 이후 편집을 다시 준비하지 않고:

git commit --quiet -m "feat: add the GitTree Features hero"

관찰됨: 출력이 없습니다. 0을(를) 종료합니다. 이 고정물에는 활성 후크/서명이 없고 가상의 로컬 ID만 있습니다. 튜토리얼 성공을 강제하기 위해 실제 프로젝트의 후크/서명을 비활성화하지 마십시오.

기본 또는 실제 앱 결과를 검사합니다.

git log -1 --format="%s%n%an <%ae>%n%cn <%ce>"
git rev-list --count HEAD
git ls-tree --name-only HEAD
git status --short
git diff --cached
git remote

처음 4개의 명령에 대해 관찰된 출력은 다음과 같습니다.

feat: add the GitTree Features hero
GitTree Demo <demo@example.com>
GitTree Demo <demo@example.com>
1
README.md
index.html
 M index.html

마지막 두 명령은 각각 no output and exited 0을(를) 생성했습니다. 작업 편집 내용은 그대로 유지됩니다. 리모컨이 없습니다. 이는 업로드가 아닌 로컬 첫 번째 커밋입니다.

독립적인 콘텐츠 확인을 위해 git show HEAD:index.html는 위에 표시된 전체 HTML-01 본문을 준비된 출력으로 반환했습니다. git diff -- index.html은(는) 여전히 정확한 지원 라인 교체를 보여주었습니다. 인덱스는 두 경로 모두에 대해 HEAD와 일치했습니다. 최신 파일은 손실되지 않았습니다.

이 강의가 끝나면 선언된 요약과 가상의 작성자/커미터가 포함된 정확히 하나의 커밋을 가리킵니다. HEAD 및 색인에는 README-01 및 HTML-01이 포함되어 있습니다. 작업 index.html에는 HTML-01-WORKING이 포함되어 있습니다. Status에는 index.html의 앞에 공백이 있고 M이 있습니다. 리모콘이 없습니다.

이 체크포인트를 6단원에 전달하기 전에 의도적인 편집을 "정리"하거나, 두 번째 커밋을 하거나, 루트를 수정하거나 선택적 연습 노트북을 추가하지 마십시오. 이후의 모든 정리 연속 노트북은 이 두 파일의 첫 번째 커밋이 아닌 별도로 보존되는 변형에 속합니다.

• Saving without staging: 디스크 바이트와 선택한 커밋 바이트가 다릅니다.
• Staging again after the deliberate edit: 유효한 Git 동작이지만 최신 줄이 커밋을 입력하여 이 강의 결과가 변경됩니다.
• Counting all visible rows as staged files: 하나의 경로에는 단계적 비교와 비단계적 비교가 있을 수 있습니다.
• Using Stage All Changes as a final cleanup: 의도적으로 제외된 편집 내용을 선택합니다.
• Enabling amend or automatic push: 이는 범위가 다른 다른 작업입니다.
• Calling unstage Discard: unstage는 인덱스 선택을 편집합니다. 폐기하면 작업 중인 콘텐츠를 제거할 수 있습니다.

새 파일이 기존 경로를 거부하는 경우 해당 경로를 취소하고 검사하세요. 알 수 없는 콘텐츠를 덮어쓰지 마세요. 편집자가 디스크가 변경되었다고 보고하면 두 버전을 모두 보존하고 실제 상태에 따라 Review Changes, Reload from Disk 또는 Keep Editing 컨트롤을 사용합니다. 맹목적으로 Overwrite with My Edits을(를) 선택하지 마세요.

아무 것도 준비되지 않아 커밋이 차단된 경우 원하는 파일을 선택하고 검토하세요. ID가 누락된 경우 4과의 로컬 설정을 검사하세요. 실패한 시도는 명시적인 저장소 대상과 함께 Set up your Git identity을(를) 제공할 수 있습니다. 전역 ID 쓰기를 정당화하지 않으며 ID를 저장한다고 해서 커밋이 자동으로 성공했다는 의미는 아닙니다.

Git이 커밋을 거부하거나 후크가 실패하는 경우 가능한 경우 Hook Output을(를) 읽어보세요. 소스 정의 거부 텍스트는 The commit was not created. Your message and staged changes are unchanged.입니다. 명시된 원인을 수정하고 다시 시도하기 전에 색인을 다시 확인하십시오. 단순히 그린 테이크를 제작하기 위해 후크 건너뛰기를 선택하지 마십시오. 불확실한 결과가 발생한 경우 다시 제출하기 전에 실제 HEAD를 다시 확인하세요.

예상치 못한 내용으로 커밋이 생성된 경우 실제 SHA, 작업/인덱스 상태 및 메시지를 중지하고 기록합니다. 즉시 수정하거나 재설정하거나 취소를 클릭하지 마세요. 지금 구성을 변경해도 해당 커밋에 이미 저장된 메타데이터는 변경되지 않습니다.

각 질문에 답한 후 그 이유를 읽어보세요. '필수'라고 표시된 질문은 수업 완료에 반영됩니다.

1. 질문 1/6

   질문 1/6

   index.html을 생성하고 스테이징하지 않고 편집기에서 저장을 완료합니다. 저축은 무엇을 확립했는가?

   답을 하나 선택하세요.

   버퍼가 작업 파일에 도달했습니다.

   커밋이 메인에 존재합니다.

   Git은 이후의 모든 편집 내용을 선택했습니다.

   답변 확인
2. 질문 2/6

   질문 2/6

   새 README를 스테이징한 다음 첫 번째 커밋 전에 언스테이징합니다. 어떤 진술이 맞나요?

   해당하는 답을 모두 선택하세요.

   --cached 없는 git rm은 안전한 것으로 입증된 것과 같습니다.

   Unstage File과 Discard는 동의어입니다.

   저장된 텍스트는 디스크에 남아 있습니다.

   README는 이 픽스처에서 untracked로 돌아갑니다.

   답변 확인
3. 질문 3/6

   질문 3/6필수

   두 파일 모두 스테이징된 후 다시 스테이징되지 않고 HTML-01-WORKING이 저장됩니다. 일반적인 커밋 후에 어떤 결과가 맞나요?

   답을 하나 선택하세요.

   파일당 하나씩 두 개의 커밋이 생성됩니다.

   최신 편집기 버전은 항상 커밋됩니다.

   하나의 커밋에는 README-01과 HTML-01이 있습니다. 작업 편집이 남아 있습니다

   이제 리모컨에 영웅이 포함되어 있습니다.

   답변 확인
4. 질문 4/6

   질문 4/6필수

   별도의 재생에서 최신 버전을 저장한 후 index.html을 다시 준비한 다음 두 파일을 모두 커밋합니다. 당신은 무엇을 예측합니까?

   답을 하나 선택하세요.

   깨끗한 상태의 커밋의 최신 지원 라인

   HTML이 두 번 나타나기 때문에 세 개의 커밋된 파일

   스테이징에서는 파일만 계산하므로 이전 지원 라인

   글로벌 정체성 변화

   답변 확인
5. 질문 5/6

   질문 5/6

   두 개의 파일이 준비되지 않았으며 아무것도 준비되지 않았습니다. 버튼에는 커밋을 위한 단계 변경이라고 표시되어 있습니다. 그것은 무엇을 합니까?

   답을 하나 선택하세요.

   현재 작업 중인 모든 변경 사항을 먼저 단계화합니다.

   검토 없이 즉시 파일을 커밋합니다.

   인덱스가 정리될 때까지 파일을 삭제합니다.

   답변 확인
6. 질문 6/6

   질문 6/6필수

   명명된 기본 명령을 사용하여 완성된 원본을 검사하거나 도구를 사용할 수 없는 경우 전체 실제 사본을 읽어보세요. 어떤 관찰이 결과를 공동으로 입증합니까?

   해당하는 답을 모두 선택하세요.

   비어 있는 캐시된 diff, index.html에 대한 space-M 상태, 원격 없음

   HEAD와 인덱스에는 이전 HTML이 포함되어 있습니다. 작업 파일이 최신입니다.

   1번, 정확한 주제, 허구의 작가/커미터

   통과하는 CI 실행

   완전히 깨끗한 상태가 필요합니다.

   답변 확인

완성된 원본에 대해 기사의 상태/콘텐츠 쿼리를 사용하세요. 정확히 하나의 커밋과 나머지 작업 수정이 모두 올바른 이유를 설명하세요. 준비된 파일을 읽기 전에 예측을 기록하세요.

separate disposable replay only의 경우 커밋하기 전에 나중에 편집한 index.html을 준비하세요. 새로운 라인이 기록되고 상태가 깨끗해질 것을 예측합니다. 이 대안을 수행하기 위해 원본을 변경하지 마십시오. 아직 브라우저 연습이 없으면 두 개의 기록을 사용하고 다른 결과를 설명하십시오.

• 저장하면 작업 파일이 변경됩니다. 스테이징은 다음 일반 커밋의 내용을 선택합니다.
• 첫 번째 커밋은 인덱스를 기록하고 푸시하지 않고 로컬 메인을 진행합니다.
• 내용, 신원, 잔여 저작물을 별도로 검증합니다. 더러운 결과는 의도적일 수 있습니다.

• 다음 커밋에 포함될 내용 예측(강의 3)
• 강의 저장소를 생성한 후 복제와 열기 구별(강의 4)
• GitTree 다운로드

무대 - 태그; 언스테이지 — إلبان التجهيت; 커밋 — إيداع; 색인 — البهرس; 작업 트리 — مجلد العمل; 추적되지 않음 — بُتبَّع; 저자 — المؤلب; 커미터 — المُودِع. 폐기는 التهالّص من التجييرات를 의미하며 무대 해제와 동일하지 않습니다.