프로젝트에 Git 설치하기: git init
터미널을 켜서 프로젝트를 관리할 위치로 이동한다. 이동에는 cd
명령어를 사용하고, 디렉토리를 터미널로 드래그해서 넣으면 절대 경로가 생성된다. 해당 방식으로 쉽게 원하는 디렉토리로 이동이 가능하다.
cd {절대 경로}
처음 디렉토리에 위치하면 아직 Git이 설치되지 않은 상태이다. Git은 로컬에서 동작하는 설치 프로그램으로, 터미널에 git init
명령어를 치면 쉽게 설치할 수 있다. Git을 설치하면 .git
폴더가 숨김 처리되어 생성되고, 해당 폴더에서 다양한 버전 히스토리가 관리된다.
Git 상태 확인하기: git status
Git에는 크게 세 가지 상태(영역)가 있다(현재 디렉토리의 깃 상태를 확인하기 위해선 git status
명령어를 사용하면 된다).
- Working Directory: 코드 작업을 수행하는 디렉토리를 의미함.
- Staging Area: Git에 버전 정보를 등록하기 위한 파일들을 등록.
- Git Directory(Repository): 변경 된 이력을 Git 디렉토리에서 체크 포인트로 관리.
작성한 코드 파일은 최초엔 Working Directory에 있는 상태이다. 이후에 해당 파일을 Git에 등록하기 위한 중간 단계로 Staging Area에 변경이 있는 파일들이 등록된다. 등록이 완료되면 수정이 있는 파일들을 Git Driectory로 추가한다. 그리고, 추가한 시점에 맞게 하나의 체크 포인트가 생성된다. 각 단계를 수행하는 데 add
와 commit
명령어가 사용된다.
스테이징 하기: git add
Working Directory에서 최초로 어떠한 파일을 만들어서 작업을 수행했다고 해보자. 해당 상태에서 git status
명령어를 실행하면 아래와 같은 화면이 확인된다.
example.js라는 파일이 '추적되지 않는 파일'이라고 되어있다. 여기서 '추적'이란, Git이 버전을 관리할 때 이전 버전과 현재 버전의 차이를 확인하기 위해 파일들의 '수정 사항'을 지속적으로 체크해야 하는데, 해당 과정을 의미한다. Git은 이전에 A라는 파일이 작성된 코드를 기억하고 있다가. 다음 체크 포인트를 만들 때 해당 파일이 기존 대비 수정되었다는 것을 감지했을 때 다음 버전에 해당 수정 사항을 기억해둔다. 이렇게 특정 파일이 수정되었는지를 Git이 추적하기 위해선 파일에 대해 최소 한 번은 체크 포인트가 만들어져야 한다. 위의 예시에선 아직 체크 포인트 생성이 한번도 없었기 때문에 '추적하지 않는 파일'이라고 확인된다.
해당 상황에서 새롭게 만들어진 example.js
파일을 스테이징 해보겠다. 스테이징에는 git add
명령어가 사용된다.
스테이지에 example.js
파일을 add
해보니 '커밋할 변경 사항'으로 파일을 관리하는 게 확인된다. 스테이지에 올라간 파일은 이제 체크 포인트를 만들 때 반영될 준비가 된 셈이다.
해당 상황에서 만약에 파일 하나를 추가로 만들어서 함께 스테이징하고 싶다면 동일하게 git add
명령어를 사용하면 된다.
추가 파일도 잘 스테이징됐다.
커밋하기: git comit
해당 상태에서 체크 포인트를 만들기 위해선 git commit
이라는 명령어를 사용해야 한다. 지금까지 얘기해오던 '체크 포인트'의 정체가 사실은 '커밋'이다. Git은 commit
이라는 명령을 통해 해당 시점의 체크 포인트를 생성한다.
참고로, 파일을 커밋할 땐 커밋의 git commit -m "커밋 메시지"
형태로 커멧 메시지를 작성할 수 있다. 미래 시점에서 특정 커밋으로 롤백을 해야한다고 가정했을 때, 해당 커밋이 어떤 수정 사항들을 반영하고 있는지를 파악하는 것은 중요하다. 그래야 적절한 시점으로 프로젝트를 되돌릴 수 있기 때문이다(의도치 않게 너무 앞이나 너무 뒤로 되돌리면 작업 생산성이 떨어지고 한 마디로 귀찮아진다). 그런 맥락에서, 적절한 커밋 메시지를 작성하는 것은 매우 중요하다(이 부분에 대한 여러 방법론이 존재하며, 이후에 좀 더 공부해본 후 포스팅할 예정이다).
커밋을 하고 나면 Git의 상태가 '커밋할 사항 없음, 작업 폴더 깨끗함'이라고 나온다. 해당 시점에서 하나의 체크 포인트가 정상적으로 잘 생성된 것이다.
이제, 커밋한 example.js
파일에 코드를 수정하고 스테이징 한 다음 상태를 살펴보면 아래와 같이 '수저함'이라는 안내가 나온다. 한번 커밋한 파일이기 때문에 Git이 파일의 변화 여부를 지속 추적하고 있으며, 기존 커밋(체크 포인트)과 다른 코드가 작성된 게 확인되기 때문에 '수정함'이라고 인지하는 것이다.
해당 상태에서 다시 커밋을 하면 두 번째 체크 포인트가 생성된다. 이제 필요에 따라 두 개의 커밋 중 원하는 시점으로 코드를 되돌리는 것이 가능해졌다.
커밋 기록 확인하기: git log
git log
명령어를 사용하면 그동안 해온 커밋 이력을 확인할 수 있다. 위에선 총 두 번의 커밋을 했었기 때문에 git log
에는 두 개의 커밋 이력이 확인된다.
커밋 이력을 보면 커밋을 한 날짜, 시간, 커밋을 한 사람(Author), 커밋 메시지가 확인된다. 그리고, 커밋의 주소값인 해시값이 함게 확인된다. 이후에 특정 커밋으로 코드를 되돌릴 때 이 커밋 해시값이 사용된다.
결론
이후에 커밋 단위나 메시지 작성 컨벤션, 특정 커밋 시점으로의 롤백, 브랜치 관리 등 더 다양한 Git 활용법을 공부하겠지만, 결국 수정 사항을 스테이징하고, 커밋하는 것은 핵심 중의 핵심이다. 사용법을 잘 익혀두자.
'Git-Github' 카테고리의 다른 글
Git과 Github (2) | 2024.11.07 |
---|---|
CLI 기본 명령어 (0) | 2024.11.06 |