[Git] Git 파일 버전 관리 원리

• add : 하나의 버전을 만들기 위해 변경사항을 선택하는 과정
• commit : 선택한 변경사항을 하나로 묶어 버전으로 만든 것
  • 변경사항만 부분적으로 저장하는 것이 아닌 변경된 파일 전체를 저장 → Snapshot

 

---

Snapshot vs Delta

• Delta : 바뀐 내용만을 저장
  • SVN(SubVersion)에서 사용하던 방식
    

    

    SVN이 사용한 방식

• Snapshot : 바뀐 내용뿐만 아니라 전체 코드 저장

 

---

Git이 대중화된 이유 → 더 빠르기 때문

• why? 버전을 보여줄 때의 차이점 때문
  • Delta 방식
    • 파일이 만들어졌던 맨 처음까지 거슬러 올라가며 바뀐 점을 모두 반영하는 계산을 해야 함
      
      
  • SnapShot 방식
    • 이미 전체 파일이 저장되어 있기 때문에 앞 커밋과 비교하는 연산 한 번만 하면 됨

 

---

Git으로 관리하는 파일의 4가지 상태

• 총 4가지 상태로 나뉨

파일 관리 4가지 상태

 

---

1. 초기화 단계

Git 전체적인 그림

• 프로젝트 폴더에 처음 Git을 초기화하고 README.md와 App.js 생성
• 둘 다 한 번도 커밋되지 않았기 때문에 파일상태 : 추적 안됨(Untracked)

 

---

2. Add

로컬 저장소로 add

• add 명령어를 통해 로컬저장소 안에 스테이지로 올림
• 파일 상태가 추적 안됨 → 스테이지 됨으로 바뀜

 

---

3. Commit

commit

• 스테이지에 있는 파일 전체를 commit으로 하나의 스냅숏, 즉 버전으로 만듦
• 파일 상태 : 스테이지 됨 → 수정 없음

 

---

4. Push

Push

• push를 통해 로컬저장소에만 있던 것을 원격저장소에도 저장

 

---

5. App.js 수정 / test.txt 추가

• App.js가 수정됐기 때문에 파일 상태 : 수정 없음 → 수정함으로 변경
• test.txt는 새로 생성됐기 때문에 추적 안됨 상태

 

---

6. add

add

• README.md는 파일상태가 ‘수정 없음’ 이기 때문에 스테이지에 올릴 수 없음
• 스테이지에 App.js 수정본, test.txt라는 새 파일이 올라옴

---

7. Commit

Commit

• 이 커밋은 앞서 만든 커밋인 ‘프로젝트 초기화’에 연결됨
  → app.js가 수정되었고 test.txt가 추가됐다는 것을 Git이 계산을 통해 알아냄

 

8. Push

push

• 새로 만든 커밋 또한 원격 저장소에 올라오게 됨 → 버전 관리 완료