[TIL][230125] 깃, 깃허브 정리

깃, 깃허브 정리

왜 깃을 사용할까

1. 어떤 부분이 변경되었는지 쉽게 확인하기 위해
2. 개발하다가 전 단계로 다시 돌아가기 위해
3. 협업을 위해 

작업 디렉터리(working directory)-스테이지(stage)-저장소(repository) 

- 작업 디렉터리: .git 숨김 폴더가 위치한 곳. 즉, 버전을 관리할 파일들이 위치한 곳. 
- 스테이지: 수정된 파일 중 다음 버전으로 만들 파일들이 위치한 곳. 명시적으로 보이지 않음. 
- 저장소: 버전을 만들어 관리하는 곳. 명시적으로 보이지 않음. 
- 저장소에 새로운 버전이 만들어지면 스테이지는 비워진다. 
- 작업 디렉터리=>스테이지: add, staged
- 스테이지=>저장소: commit 

- tracked 파일: 스테이지에 올라온 적이 있는 파일(커밋된 적이 있는 파일)
- untracked 파일: 기존에 깃이 관리하지 않았던 새롭게 생성된 파일 

- .gitignore: 버전에 올리지 않을 파일이나 폴더의 목록을 적어두면 git이 변경사항을 반영하지 않는다. 

- 각 커밋에는 커밋 해시라는 고유한 문자열이 있는데 되게 복잡하다. 그래서 release 하는 특정 커밋들을 쉽게 구분 짓기 위해 태그를 달아준다. 태그에는 버전은 적어주는데 보통 <연도.월.일>이나 <숫자.숫자.숫자>의 형태로 표기한다. 
- 보통은 vX.Y.Z의 형태로 표기하는데 X는 주(major)버전으로 기존에 있던 버전과 호환이 안될 정도로 큰 변화가 있으면 증가한다. Y는 부(minor)버전으로 새로운 기능을 추가하면 증가한다. Z는 수(patch)버전으로 버그 수정 정도의 작은 변화가 있으면 증가한다. 

- revert: 기존의 버전은 삭제하지 않고 이전 버전으로 되돌아가 그 버전으로 새로운 커밋을 만드는 것.

- reset: 이전 버전으로 되돌아가는데 되돌아간 버전 이후 버전들은 삭제되는 것. 

리셋에는 종류가 3개가 있다. 
- soft reset: 작업 디렉터리와 스테이지의 변경사항은 유지하고 커밋은 되돌리는 것. 
- mixed reset: 작업 디렉터리의 변경사항은 유지하고 스테이지와 커밋을 되돌리는 것. 
- hard reset: 작업 디렉터리, 스테이지, 커밋 모두 되돌리는 것. 

- 스태시(stash): 임시 저장 기능
- 작업 디렉터리의 변경 사항은 모두 임시 저장된 후에 변경 사항이 생기기 전의 상태로 돌아간다. 
- Untracked 파일에는 스태시를 사용할 수 없다. 

- 브랜치(branch): 버전을 분기별로 나눠서 관리할 수 있는 기능
- HEAD: 현재 작업하고 있는 브랜치의 최신 커밋을 나타낸다. 
- 체크아웃: 다른 브랜치로 이동하는 것. HEAD도 바뀌고 작업 디렉터리도 체크아웃한 브랜치로 바뀐다. 
- 브랜치 이름: 새로운 기능을 위한 것. feature/<기능>, 릴리스를 위한 것. release/<릴리스 번호>, 급하게 수정하기 위한 것. hotfix/<수정 내용>
- 브랜치 병합 과정에서 충돌이 발생하면 직접 충돌을 해결해서 커밋해야 브랜치가 병합된다. 
- rebase: 브랜치를 재배치하는 것. (Ex. 첫 번째 커밋에서 뻗어 나오는 브랜치를 세 번째 커밋에서 뻗어 나오도록 기준점을 변경하는 것.)

깃은 로컬 저장소, 깃허브는 원격 저장소
- 깃허브: 백업과 협업을 위해 사용 

- clone: 원격 저장소를 로컬에 복제
- push: 원격 저장소에 저장
- fetch: 원격 저장소 가져오기
- pull: 원격 저장소 가져와서 합치기 

- Collaborator로 권한을 받지 않으면 원격 저장소에 푸시할 수 없다. 권한이 없는데 푸시하고 싶다면 pull request를 이용하면 된다. 
- 기여할 저장소를 포크하여 클론한다. 브랜치를 만들어서 변경사항을 푸시한 후 풀 리퀘스트를 보낸다.