평소에 깃이 뭔지, 깃허브가 뭔지, 정확히 모른 채로 일단 코드를 쓰고 제출을 하면 잔디가 심어지고 뿌듯하고..?가 다였는데, 오늘 내일배움캠프에서 GIT 특강을 들으면서 아 그래서 이런 작업들을 했던 거구나 하고 알게 되는 계기가 되었던 것 같다. 일단 실전에 앞서 간단한 개념을 정리해보려고 한다.
< 깃이란? >
CLI(Command-Line Interface), 명령어 기반 인터페이스이다.
:::깃 명령어 정리:::
- pwd : 현재 경로 확인, 어디에서 명령어를 치고 있는가.
# 경로 > 절대경로 : c ~ 지금폴더까지의 경로 이름
> 상대경로 : 현재 경로를 기준으로 나타낸 경로. '.'(점)으로 나타냄 - ls : 현재 경로의 파일 및 폴더 조회하기
- ls -al : 현재 경로의 숨김 파일 및 폴더까지 모두 목록으로 조회하기
# 숨김 파일 및 폴더의 특징 .hello처럼 점이 앞에 있음. - cd <경로> : <경로>로 이동하기
- cd .. : 상위 디렉터리로 이동하기
- cd . : 현재 디렉터리로 이동하기
- cd ~ : 홈 디렉터리로 이동하기
- touch <파일명> : 파일 생성
- cat <파일명> : 파일 내용 확인
- vi☆☆☆ <파일명> : 파일 편집하기
# 입력하려면 입력 모드로 전환을 해야 함. a혹은 i를 눌러서. 아래에 insert가 뜸.
# 입력 모드를 빠져 나오려면 esc 눌러서.
# 입력 모드를 빠져 나와서 insert가 있는 창에 :w 입력 >> 저장
# :q >> vi 편집기 빠져 나오기
# :w 와 :q를 동시에 :wq 입력 - rm <파일명> : 파일 삭제하기(remove)
- mkdir <폴더 이름> : 폴더 생성
- rmdir <폴더> : 비어있는 폴더 삭제
- rm -rf <폴더> : 비어있지 않은 폴더도 삭제(-rf : 강제)
< 왜 깃을 배워야 할까? >
여러 명의 사람들이 같이 프로젝트를 할 때,
- 1. 변경 내역 확인이 어렵다.
- 2. 작업을 되돌리기 어렵다.
- 3. 협력하기 어렵다.
우리는 프로그램을 개발할 때, 유의미한 변화를 쌓아서 프로그램을 만들어 나간다. 유의미한 변화는 새 기능 추가, 버그 삭제, 수정 등이 있을 수 있다. 이 유의미한 변화가 결과물로 나온 것을 버전이라고 하는데, 깃은 버전 관리를 위한 도구이다.
< 깃허브란? >
원격 저장소 호스팅 서비스이다. 여기서 저장소는 깃으로 관리한 프로젝트를 뜻한다. 개발자들의 SNS가 되기도 한다.
깃이 관리하는 세 개의 공간
| 작업 디렉터리(working tree) | 버전 관리의 대상이 위치하는 공간(.git이 있는 디렉터리) |
| 스테이지(index) | 작업 디렉터리에서 변경사항이 있다면 이 중에서 내가 다음 버전이 될 후보를 선별하여 스테이지에 올린다. 다음 버전이 될 후보가 올라가는 공간. |
| 저장소(repo) | 버전이 만들어지고 관리되는 공간. 로컬 저장소(local repository)와 원격 저장소(remote repository)가 있다. |
- 작업 디렉터리에서 스테이지로 추가하는 것 >> add한다
- 스테이지에 있는 파일을 저장소로 추가한다 >> commit한다
:::commit add 명령어:::
- git init : 로컬 저장소 만들기
- git status : 작업 디렉터리 상태 확인하기
# untracked files : add되지 않은 file
# checked files : add된 file - git add : 스테이지에 올리기
- git add . : git add -A
- git commit 자세한 커밋 메시지와 함께 커밋하기
# 제목만으로 커밋하기 - git commit --message " " : " "(커밋 메시지)"로써 커밋하기
- git commit -m " " : 위와 동일
# 커밋 메시지는 제목과 본문으로 이루어져 있다. - git log --patch(git log -p) 무엇이 바뀌었는지 알 수 있다.
git commit을 입력하면 vi 편집기로 들어간다. i를 눌러 insert 모드로 들어가
첫째 줄은 제목, 셋째 줄은 본문을 입력해준다.
커밋 메시지는 중요!!. 이 사람과의 협업 가능성을 본다.
두 줄을 수정하였더라도 두 줄을 왜 수정하게 되었는지 자세하게 쓰는게 좋다.
다시 add 해주고 다시 commit 한 뒤, git log 해보자.
노란 부분 : 커밋 해쉬
git log --oneline으로 하면 짧게 나오는데 이는 git log을 했을 때 나온 긴 커밋 해쉬의 앞부분이다.
긴 부분으로 할 수 있는 건 다 짧은 부분으로도 할 수 있다.
git 명령어 중 커밋 해쉬를 사용하는 명령어가 있다.
git diff 최근에 만든 commit과 현재 작업 디렉터리를 비교해주는 명령어
git diff --staged 최근 commit과 스테이지 비교해주는 명령어
git diff 커밋해쉬1 커밋해쉬2(짧은거) : commit끼리 비교하기
>> 1에 비해 2가 뭐가 달라? (순서 중요!!)
중간에 명령을 내렸는데 새롭게 명령어가 입력이 되지 않을 때는 q를 누르면 명령이 끝난다.
< 브랜치란? >
버전을 여러 개의 흐름으로 관리하는 방법.
브랜치가 없다면?
- 서로의 작업과 전혀 관련 없는 부분, 같은 코드를 다르게 수정한 부분(충돌이 발생했다. 라고 한다.) 혼재
- 일일이 수작업으로 합쳐야 함
- 때로는 서로의 코드를 합치다 실수가 생길 수도 있다.
이런 문제점을
- 브랜치를 나눈다.
- 각자의 브랜치에서 작업한다.
- (필요하다면) 나눈 브랜치를 합친다.
로 해결할 수 있다!
예를 들어, 쇼핑몰을 관리하는 코드가 있다고 하자. 개발자 A는 장바구니 기능을 추가해야 하고 개발자 B는 주문 목록 기능을 추가해야 한다. 두 기능은 서로 관련이 없다. 그럼 A는 장바구니 브랜치를 따로 만들고, B는 주문 목록 브랜치를 따로 만들어 합치면 되는 것!
브랜치의 이름
최초의 브랜치는 master 브랜치이다. 기본적으로 아무 브랜치도 생성하지 않고 commit을 하게 되면 commit은 master 브랜치에 속하게 된다. (master가 인종차별의 어감이 있어서 main으로 이름을 바꿔서 할 수도 있다. 두 개는 똑같은 것!)
:::브랜치 명령어 정리:::
- git branch : 브랜치 목록을 보여줘.( * : 현재 작업중인 브랜치)
- git branch foo : foo 브랜치 생성
- git checkout foo : 작업 브랜치를 foo로 바꿔줘.
- git branch -d <브랜치> : 체크아웃되어있지 않은 브랜치를 삭제해줘.
- (master 브랜치에서)git merge foo : 마스터 브랜치에서 foo 브랜치를 병합해줘.
- git checkout -b bar : bar라는 브랜치를 만들고 그쪽으로 체크아웃해줘.
그 밖의 용어 정리
- head : 포인터이다. 일반적으로는 현재 작업 중인 브랜치의 최신 커밋을 가리킨다. "내가 지금 어디에서 작업 중인가"
- 체크아웃 : 특정 브랜치에서 작업할 수 있도록 작업 환경을 바꾸는 것
- 브랜치를 merge한다 : 브랜치를 합친다. 병합되었다고 브랜치가 지워지지는 않는다.
- 빨리감기 병합(fast-forward) : 새로운 커밋을 만들지 않는 병합. 변함이 없던 브랜치가 마치 빨리감기하듯 브랜치 내용이 업데이트되는 병합 기법.
충돌이 발생했을 때 대처법
- 충돌을 해결한다(어떤 브랜치의 내용을 반영할지 직접 선별해준다)
- 다시 커밋한다
<<<<<<<head
" " <- 현재 브랜치 내용
===========
" " <- foo 브랜치 내용
>>>>>>> foo충돌이 나면 코드가 이런식으로 나오게 되는데 한쪽 걸 지워주고 다시 add해주고 커밋해준다.
'STUDY > GIT' 카테고리의 다른 글
| [TIL] pull request 연습. (0) | 2023.05.26 |
|---|---|
| [TIL] 깃 에러 해결(README 충돌) (2) | 2023.05.24 |
| [TIL] GitHub Repository 정리(IntelliJ 파일 정리하기) #내 잔디 돌려줘.. (1) | 2023.05.20 |
| [TIL] GitHub README를 잘 적는 방법. (0) | 2023.05.19 |
| [TIL] Git 협업할 때 오류가 덜 나는 브랜치를 이용하는 방식(주관적) (0) | 2023.05.17 |