[Git] WorkFlow 및 .gitignore

Git Workflow

Local

깃 레포지토리에 커밋을 하기까지는 총 3개의 영역이 존재

---

1. Working directory

내가 작업하고 있는 프로젝트 디렉토리

Untracked : Git 체크하지 못하는 파일들.

Tracked : Git이 체크하고 있는 파일들.

• Unmodified : 수정되지 않은 파일. (원격 레포지토리의 파일과 같은 상태)
• modified : 원격 레포지토리의 파일과 다른 상태로 add 명령을 통해 staging area로 넘길 수 있는 상태
• staged : "add" 명령어를 통해 staging area에 추가된 상태

2. Staging Area

커밋을 하기위해 “add” 명령어로 추가한 파일들이 모여있는 공간

 

3. Repository

커밋들이 모여있는 장소

---

Staging Area는 왜 필요한가?

바로 커밋을 하면되는데 왜 staging area라는 추가적인 메모리 공간을 사용하는지에 대한 궁금함이 생김.

 

찾아본 결과 아래와 같은 3가지 이유와 직결됨.

1. 일부분만 커밋하고 싶을 때

>> Working directory에서 자유롭게 소스코드를 수정하면서 원하는 부분만 atomic하게 커밋을 하고 싶을 때 staging area를 활용하면 일부분 커밋이 원활히 가능.

2. 충돌을 해결할 때

>> 충돌이 발생했을 경우 해결을 위한 데이터를 Staging Area에 저장해두는 것이 좋음.

svn도 마찬가지로 어떤 파일이 충돌했는지 ‘파일 상태’를 기억하지만 Git은 필요한 만큼만 충돌을 해소하고 그 부분만 add하여 커밋하면 되기 때문에 편리함.

3. 커밋 다시하기

>> 커밋을 수정할 때 로그메시지 뿐만 아니라 파일들도 조금의 수정이 필요할 때 staging area에 수정 후 다시 add를 해주면 됨.

 

 

---

.gitignore

- Git으로 Tracking하고 싶지 않은 파일들에 대한 설정 파일.

작성하는 방식으로는

- 파일이름을 지정하거나.

- *.txt 처럼 특정 확장자를 지정하거나.

- folder/ 처럼 폴더안의 모든 내용을 지정할 수 있음. (예로 node_modules와 같은 의존성을 담고 있는 폴더 등을 지정)

 

---

GitHub ?

깃헙을 사용하는 이유는 단순하게 로컬 레포지토리에 저장해놨을 경우

로컬 자체에 문제 때문에 데이터가 다 날아갈 수 있는 위험이 있기 때문에

원격 레포지토리를 추가로 사용하는 것.

클라우드 서비스 느낌과 동일함.

 

 

---

Reference

https://www.youtube.com/watch?v=Z9dvM7qgN9s&t=979s