깃, 깃허브에 대하여

깃이란?

버전 관리 시스템으로, 버전 관리, 협업 관리를 도와준다.

 

깃의 관리 영역

1. Working Directory(Local Repository) : 내가 작업하는 공간. 한마디로 내 컴퓨터의 폴더를 뜻함.

2. Staging Area : 수정 이력을 기록할 파일을 대기시키는 장소. 깃의 관리 영역(add 시 저장되는 곳)

3. Repository : Staging Area에서 대기 중이던 파일들을 최종적으로 기록하는 장소. 깃의 관리 영역

 

파일 권한

소유자  ||  소유자 그룹 ||  방문자

rwx            rwx                   rwx

r: read 4

w: write 2

x: 실행 1

666 rw rw rw 777 rwx rwx rwx 등등

<Second Upload 커밋 이후>

현재 HEAD는 Second Upload한 master를 나타내고 있다.

checkout으로 HEAD를 옮겨보자

<다시 돌아가기>

 

 

깃의 큰 흐름

1. git init : '.git'이라는 파일(커밋 내역, 브랜치 정보 등이 들어있음)을 만들어, 한 폴더 안의 파일들을 추적할 준비를 한다. 한마디로 폴더의 '깃화' 한다고 할 수 도 있음.

2. Untracked : '깃화' 한 폴더 내에 새롭에 파일을 만들게 되면, 깃은 아직 그 파일을 추적하지 않는 상태로 둔다.

3. Tracked : git add .이나 git add {파일명}을 통해 폴더 안의 모든 파일 또는 하나의 파일을 Staging Area에 대기 시켜 추적되게 한다.

3-1. Modified : 파일이 수정되었으나 아직 Staging Area에 반영되지 않은 상태. git add 명령어를 통해 반영할 수 있다. (보통 git status 시 빨간색 modified)

3-2. Staged : 파일이 수정되었고, git add 명령어를 통해 Staging Area에도 반영되었다. 즉, 커밋을 위한 준비가 마쳐진 상태.(보통 git status를 했을 시 초록색 modified로 볼 수 있다.)

3-3. Unmodified : 파일이 수정되지 않았거나, 이미 커밋을 한 상태. Staging Area에 반영된 모습과 같은 모습의 파일이 Working Directory에 있는 상태.(Repository가 아닌 Staging Area과 Working Directory를 기준으로 판단한다.)

 

깃의 여러가지 명령어

1. 커밋을 위한 과정

1-1. git init : '.git'파일을 폴더에 추가함으로 해당 디렉터리를 Git 저장소로 초기화한다. .git에는 커밋 내역, 브랜치 정보, 설정 파일 등이 포함된다. 

1-2. git add : Staging Area에 파일을 올린다.(새로운 버전에서의 추적을 시작한다.) git add .은 폴더 내 모든 파일을 Staging Area에 올린다.

1-3. git commit -m "커밋 컨벤션": 커밋을 통해 Repository에 최종적으로 현재까지 수정 내용을 업데이트한다. 커밋 컨벤션 부분은 커밋 시 남길 메시지 규칙에 맞게 작성한다.

2. 상태, 커밋 과정 등을 확인하기

2-1. git status : 현재 Git 저장소(Working Directory, Staging Area)의 상태를 보여준다.

2-2. git log : 커밋 이력을 보여준다. 커밋 메시지를 보고 확인할 수 있다. git log --oneline으로 좀 더 짧게 파악 가능. git log -- {파일명}으로 한 파일에 대한 커밋 이력을 볼 수 있다.

3. 상태로 되돌아가기

현 Working Directory 상태로 다시 되돌아가기 : 보통 다른 사람이 에러 덩어리를 커밋했을 시 사용할 수 있을 듯하다.

git restore --staged {파일명 || .} => Staging Area의 이 파일을 삭제한다. 후에 add와 커밋으로 내 Working Directory 파일로 덮어쓰기를 할 수 있다.

git checkout {커밋 해시} --{파일명} => 해당 커밋시점의 파일로 Working Directory에 불러온다. 이후 add와 커밋하기

***즉, checkout은 커밋 시점, restore은 내 Working Directory 시점으로 되돌릴 수 있음. 

 

 

gitignore

깃이 특정 파일이나 디렉터리를 추적하지 않도록 설정하는 파일이다. 주로, 설정 파일 등 중요한 내용의 파일을 담는다.

 1. touch .gitignore

2. nano .gitignore

3. 파일명 작성 후 ctrl + x 누르고 y이후 엔터

이제, git add .을 하더래도 .gitignore에 작성한 파일은 Staging Area에 추가되지 않는다.

만약, 이미 commit된 파일을 무시하고 싶다면

git rm --cached {파일명} 이후 커밋 : repository에서 삭제되고, .gitignore에 추가됨

 

 

브랜치란?

Git에서 작업의 독립된 흐름을 만들어주는 기능이다. 보통 새로운 기능을 개발하거나, 버그를 수정할 때 사용된다.

***후에 프로젝트 시 기능 별로 브랜치를 나누고 작업하면 좋을 듯 하다.

1. git branch : 현재 브랜치 목록을 본다.

2. git branch {브랜치명} : 새로운 브랜치를 생성한다.

3. git checkout {브랜치명} : 작업중인 브랜치를 변경한다.

4. git merge {브랜치명} : 현 브랜치에 다른 브랜치의 내용을 병합한다. 

 

깃허브 사용하기(브랜치가 나눠져 있는 경우로 가정한다.)

시작 전 간단한 흐름(??)

-로컬 메인 브랜치는 원격 메인 브랜치의 내용을 받아올때만 사용한다.

-로컬 메인 브랜치로 받아온 후 작업할 기능을 이름으로 하는 새 브랜치를 만든다.

-서브 브랜치로 이동해 작업한다.

-작업 완료 후 로컬 Staging Area, 로컬 Repository로 add, commit한다.

-원격 서브 브랜치로 push 한다.(만듦과 동시에 push한다.)

-원격 메인으로 병합 pull request

<clone 작업 과정>

 

<직접 원격 repo를 만들고 작업 과정>

============================================================================================

지금까지 사용해왔던 과정과 많이 다르다....

이게 왜 이렇지, 원래 이렇게 안했는데?????라는 생각에 죠큼 정리하는데 오래걸렸다.