1. git

1. git의 데이터 관리

• 데이터를 파일시스템의 스냅샷의 연속으로 취급
• 파일이 달라지지 않았다면 git은 좋은 성능을 내기 위해 파일을 새로 저장하지 않고 단지 이전 상태의 파일에 대한 링크만 저장

2. git의 체크섬

• git을 데이터를 저장하기 전에 항상 체크섬을 구하고 체크섬으로 데이터를 관리한다
• 체크섬
  - git에서 사용하는 가장 기본적인 데이터 단위이자 git의 기본 철학
  - SHA-1 해시를 사용해 체크섬을 만든다
  • 폴더나 파일을 이름을 이름으로 관리하는 것이 아니라 이런 유니크한 아이디를 가지고 데이터 관리

cf. 해시

• 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 매핑한 값
• 아무리 긴 파일이름이라도 고정된 길이로 매핑했기 때문에 쉽게 관리 가능

3. git의 상태 관리

• modified: 파일을 수정한 상태
• staged: 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태 의미 (스테이지 공간에 올라간 상태)
• committed: .Git 디렉터리에 커밋한 상태

2. github

git으로 프로젝트를 관리하는 원격 저장소 호스팅 서비스
다른 사람의 프로젝트를 보거나 같이 프로젝트를 할 수 있는 공간
다른 사람이나 자신의 깃허브 레파지토리를 자신의 로컬로 가져올 수 있음

git 명령어

1. git add

• 수정/추가/삭제한 파일들의 목록을 스냅햣 찍어 스테이지에 올린다

- git add . : 모든 파일 추가
- git add 파일 경로: 해당 파일만 추가
- git add -p : 코드 조각만 추가

2. git commit

• git add를 통해 스테이지에 올려진 기록을 git 폴더에 알려준다

3. git push origin master

• origin은 git으로 호스팅하는 일종의 공유 사본
• origin의 mater 브랜치에 푸시하는 것을 의미
• origin이나 master라는 브랜치 이름은 프로젝트마다 다를 수 있다

4. git checkout -b 브랜치명

5. git checkout master

• master 브랜치로 이동한다는 명령어

6. git pull origin develop

• origin의 develop 브랜치를 끌고 오는 것
• 다른 사람이 고친 수정본이 origin에 반영되었다면 해당 항목들을 가져와야 자신의 변경사항을 origin에 올릴 수 있다
• git pull = git fetch + git merge

git fetch : 우선 저장소의 내용을 가져온다
git merge : 브랜치를 통합한다( 레파지토리와 로컬의 변경이력을 합친다 )
git rebase: 브랜치의 중심을 옮긴다

7. git status

• git으로 관리하는 폴더의 상태를 알 수 있다
• 커밋되지 않은 변경 상태를 볼 수 있다

8. git branch -d 브랜치명

• 해당 브랜치를 지운다
• 이 브랜치가 master 브랜치에 merged되지 않은 브랜치라면 삭제하지 않는다
• 강제 삭제면 git branch -D 브랜치명

9. git log --pretty=oneline

• git에 대한 로그들을 볼 수 있다
• 한 줄로 git 변경사항을 볼 수 있다

10. git diff

• 수정한 부분을 알려줌

11. git cherrypick

12. git commit amend

3. 커밋과 이슈 만들 때 주의점

1. 커밋 규칙

• 코드 수정의 단위가 되는 커밋은 쪼개져 있는 것이 좋음
• 프로젝트 안에 CONTRIBUTED.md를 만들고 팀원끼리 어떤 규칙에 의해 커밋 메시지를 작성할지 정한다

- 제목과 본문은 한 줄을 띄워 분리하기
- 제목은 50자 이내로 작성하기
- 제목 끝에 . 금하기
- 제목 줄은 "유형:제목" 형식으로 작성하기 
	ex. 기능, 버그, 리팩토링, 테스트, 문서 등
- 제목은 개조식 구문으로 작성하기 
	ex. "기능: 로그 출력 기능 추가'
- 본문은 [어떻게] 보다 [무엇을], [왜]에 맞춰 작성하기
- 본문은 축약하여 쓰지 않고 제 3자가 쉽게 이해할 수 있도록 풀어서 작성하기

ex. doc: use sentence case in issues.md headers

2. 이슈 만들 때 규칙

• 커밋을 하는 것은 보통 이슈를 만들고 그 이슈에 해당하는 해결 결과 및 과정을 적는 것
• 이슈를 만들 때도 커밋과 동일하게 규칙을 정하고 만들어야 한다

- [3D] 등 얼마나 걸릴지 명시하기 (D: day)
- 반드시 라벨링 달기

커밋을 할 때 12번 이슈가 있을 경우 close#12를 달아주면 PR이 merged될 때 해당 이슈가 닫히게 된다

cf. 이슈 : 깃허브에서 처리하는 할 일 같은 것
ex. 버그나 새로운 기능 추가 등 프로젝트의 할 일을 적어놓은 것