[git] 기본 정리

git을 단지 취업을 위해 관리하는 용도가 아닌 실제 용도에 맞게 공부하기 위해서 정리해 놓은 글입니다. 

보여주기 위한 git이 아니라 내가 팀에 도움이 될 수 있도록 하기위한 git을 공부 중입니다.

Git 

Git을 모르고 이 글을 읽기 시작했을리는 없을것이라 자세한 설명을 하진 않겠지만, 

짧게 git을 정의하자면 개발에서의 버전관리, 협업을 위한 용도로 사용되는 것. 

VCS (Version Control System, 버전 관리 시스템) 

버전관리에 필요한 요소 

• Snapshot : 특정 시점에서 파일의 상태 (현재 상태의 모든 정보)
• Delta : 파일의 이전 상태와 비교한 변경사항 

DVCS (분산 버전관리)

출처: 권준혁님의 블로그 (https://velog.io/@kwonh)

중앙 서버에 있는 코드를 각각 개발자 로컬 컴퓨터에 복사한 후, 복사된 프로젝트를 가지고 작업하면서 서버에 업로드할 수 있는 관리 체계

장점은? 

1. 서버 저장소  '전부'를 복제하는 방법 (와이파이 없어도 내 노트북으로 가져와서 작업할 수 있다.)
2. 서버에 문제가 발생하면 복제된 클라이언트로 서버를 복원 가능.
3. 리모트 저장소가 존재하여, 다수의 개발자들 or 팀이 다양한 방법으로 협업 가능

1. 선언과 저장소 (init)

주로 Repo라고 이야기하는 곳 - 레포지토리 사용자가 변경한 모든 내용을 추적하는 공간 (하나의 디렉토리로 볼 수 있음) 현재 상태, 변경 시점, 변경한 사용자, 설명 텍스트 등을 저장.

+ git은 파일을 추적하지 않는다, 각 문자와 줄을 추적한다. 

2. 파일상태 

딱히 파일 상태를 기록하지 않는다. - untrack 

추적한다. - track 

 

git 이 추적하는 파일의 상태 

1. Unmodified : 말그대로 수정된 부분이 없는 상태 
2. Modified : 이전에 버전과 비교하여 수정된 부분이 있는 상태 
3. Staged : 저장(커밋)을 위한 준비된 상태 (스테이징, Staging) 

여기서는 두가지만 기억하면된다.

스테이징 (Staging) / 커밋 (Commit)

스테이징 : 커밋하고 싶은 파일을 선택하여 (1)

커밋 : 파일을 서버에 업로드 (2)

 

git repo로 업로드를 하기위해서는 위의 두가지 작업이 필요하다.

why? 굳이 왜 두번으로 나누어 작업을 수행할까? 

 

# 여러 작업 중, 일부분만 업로드해야 하는 경우 

# 즉, 커밋 전 상태를 수정 또는 체크할 때 업로드하고 싶은 파일과 하고싶지 않은 파일을 걸러내주는 역할을 하는 공간이 stage. 

3. git 은 파일내용을 추적한다. 

출처: tacademy의 Git & GitHub Page 학습자료

커밋을 하게되면 해당 내용을 '주소'로 기억하기 위해 해쉬값을 생성. 

만약 그 버전(해쉬값으로 기억해둔 내용)으로 이동하고 싶다면, 체크아웃(Checkout) 수행하여 이동. 

 

 

 

git 구조 정리

출처: https://sabarada.tistory.com/75