it이란 개발자의 코드를 효율적으로 관리하기 위해서 개발된 ‘분산형 버전 관리 시스템',
Git에서 코드를 저장하는 공간을 리포지토리라고 한다. 리포지토리는 자신의 컴퓨터의 작업 공간(local)에 위치한 로컬 Git 리포지토리와, Github 등의 원격(remote) 공간에 위치한 원격 리포지토리로 구분한다.
파일의 변화를 기록하는 절차는 아래와 같습니다.
Git repository
를 생성: git init
work space
의 파일 및 디렉토리를 git의 관리 하에 있는 상태로 올려줄 수 있다. git add
이 영역이 staging area
이다.staging area
의 파일은 commit
이 가능합니다.commit
으로 local Git repository
에 내 코드를 기록할 수 있다. git commit
변경이 감지된 모든 파일을 한 번에 추가하려면 git add . 을 입력합니다. (.은 현재 경로를 의미)
git add index.html
git add style.css
또는
git add .
staging area
로 잘 옮겨졌는지 확인하기 위해서는 git status
명령어를 입력.
아래와 같이 Git 리포지토리의 상태를 확인할 수 있다. 변경이 되었으나 staging area로 옮겨지지 않은 파일은 빨간색 글씨로 표시된다.
변경사항이 staging area에 잘 옮겨졌다면 아래와 같이 파일 명이 초록색으로 표시
만약 Git 레포지토리가 없는 디렉토리에서 git status
명령어를 입력하면 아래 메세지를 출력한다.
박스에 어떤 용도의 물건인지 간단한 코멘트를 적은 라벨링하는 동작이 바로 commit이라고 할 수 있다.
- git add <경로명> : 경로에 있는 파일을 staging area로 넣는 명령어
- staging area: 온전히 저장하고 싶은 코드를 모아놓은 묶음
- commit
- staging area의 코드 묶음을 저장하기로 결심하고 (git commit)
- staging area 코드의 용도를 적어두는 행위 (커밋 메시지 -m "commit message")
commit 하기 전에 내용을 기록하는 장소
늘 commit하기 전에 git status 로 staging area의 상태를 확인하는 것이 좋다.
commit하고자 하는 파일 모두가 staging area에 들어 있을 경우 아래 명령어를 입력합한다 “” 내부에는 라벨링을 하듯, staging area에 모아놓은 변경 사항에 대한 설명을 작성한다.
staging area 가 빈 상태가 되면 commit에 성공한 것이다.
가장 지키기 쉬운 두가지 원칙
commit은 작은 단위로 자주 하는게 좋다. GIt commit 기록이 상세하게 되어있으면 아래와 같은 장점이 있.
- 코드를 잘못 적은 경우에, 이전 기록을 더 쉽게 복원할 수 있다.
- 누가 해당 코드를 수정했는지 쉽게 파악할 수 있다.
- 향후 학습할 merge, rebase등 기능에 날개를 달아주는 기반이 된다.
commit 메시지는 짧고 간결하게 사실적으로 작성한다. Git commit 메시지는 동료 개발자가 참고할 수 있기 때문에 짧고 간결하고 사실적이여야 한다.
Good: 기능(feat) 구현을 확인 가능, 정확한 기술 용어 사용, 짧고 간결함
git commit -m "feat: 인스타 게시글 조회 페이지네이션"
Bad: 커밋 타입 구분 X, 만연체, 사실 여부를 판단하기 어려운 "효율성"에 대한 코멘트
git commit -m "더 효율적인 인스타 게시글 조회 기능 구현함"
Very Bad: 어떻게 나은 형식인지 판단하기 어려움, 어떤 기능인지 확인이 어려움
git commit -m "좀 더 나은 형식"