티스토리 뷰
Intro
사실 나는 깃에 대한 이론 공부를 꽤 많이 했었다. 처음 개발을 시작했을 때부터 특강도 자주 듣고, 연습도 해봤지만 이론만 알고 실무에서는 막상 제대로 써 본적이 없었다. 혼자 작업하면 브랜치를 따로 팔 일도 없고, 맨날 커밋 푸시만 하게 된다ㅜㅠ 또 얼마 전에 git reset -hard 로 레포를 크게 날린 적이 있었기 때문에 (미리 백업을 해두어서 복구는 잘 했지만...) 한동안 깃을 쓰는걸 피하고 있었다. 회사에서 깃을 날리면 정말 큰일이 날 수 있으므로 이번기회에 잘 정리해보려고 한다!
서론
개발자들은 왜 깃을 쓸까? 단순히 코드를 저장하는 곳 보다는 깊은 의미가 있다. 굳이 코드를 저장하기 위한 용도라면 그냥 드라이브를 쓰는게 더 편할수도 있다. 복잡한 깃을 쓰는 이유는, 깃은 **'버전 관리'**가 쉽기 때문이다.
만약 내가 파일을 편집 전 상태로 돌리고 싶다고 해 보자. 그냥 문서 툴로 작업 했다면,
<파일1>
<파일 1- 최종>
<파일 1- 최최종>
<파일 1- 최최최종>
<파일 1- 진짜 최종>
매번 수정할 때마다 다른 이름으로 저장해야 하고, 파일명과 저장시간을 보고 내가 원하는 파일을 찾아야 할 것이다.
또 여러명이 동시에 한 파일에 작업할 때는 수정사항이 꼬이는 일들도 자주 발생한다.
이런 단점들을 해결하기 위해서 도입한 코드 관리, 협업 툴이 깃이다.
우리 회사에서는?
우리 회사에선, gitlab이라는 툴을 쓴다. [민트기술 깃랩 바로가기](https://gitlab.mintech.kr))
깃허브와 비슷한 툴이지만 private이 무료이므로, 회사에서 자주 쓴다고 한다. 깃허브와 쓰는 방식이 동일하다는 점만 알고 넘어가고 한다. 깃랩에 대해서 더 알고싶으신 분은 밑에 블로그를 참고하면 될 것 같다.
https://technote.kr/108
콘솔보다는 GUI를 쓰자
물론 개발자의 워너비가 검은색 배경에 흰색 글씨인 콘솔이긴 하지만, 깃은 GUI를 쓰는걸 추천한다. 콘솔을 쓰다가 실수하면 대참사가 일어날 수 있다.
회사 분들은 대부분 [Source Tree](https://www.sourcetreeapp.com)를를) 추천해 주셨다. 아마 [Git Kraken](https://www.gitkraken.com)에서에서) 우리 회사가 쓰는 self-hosted GitLab을 클론하는 것이 유료여서 그런것 같다. 이미 쓰던 깃 툴이 없으신 분이라면 Source Tree를 추천한다.
명령어
Repository
Git에는 두가지 종류의 repository가 있다.
- Local Repository : 내 컴퓨터에 저장되는, 개인적인 repo
- Remote Repository: 깃랩 서버에 저장되며, 여러사람이 함께 쓰는 repo
평소에는 내 PC의 local repo에서 작업하다가 작업한 내용을 공개하고 싶을 때에 원격 저장소에 업로드 한다. 물론 remote repo에서 다른 사람이 작업한 파일을 local로 가져올 수도 있다.
Repo를 만드는 방법에는 두 가지가 있다.
- 새로운 repo 만들기
- remote repo를 복사해오기
Commit
어떤 사람이 커밋을 '포스트잇 붙이기' 에 비유했는데, 매우 적합한 표현인 것 같다.
커밋을 하면, 이전 상태부터 커밋할 때까지의 상태 변화가 기록된 커밋이 만들어지게 된다. 커밋을 할 때는 메세지를 쓰게 되는데, 나중에 이전 커밋으로 되돌아가고 싶을 때 이 메세지를 보고 과거 커밋을 찾게 되므로 커밋 메세지를 잘 쓰는 것은 매우 중요하다.
Git에서 권장하는 메지 형식은 다음과 같다.
1번째 줄 : 커밋 내의 변경 내용을 요약
2번째 줄 : 빈 칸
3번째 줄 : 변경한 이유
Work Tree, Index
Work Tree는 폴더라고 생각하고,
Index는 커밋하기 전 repo와 Work Tree 사이에 존재하는 공간이라고 생각하자. 가상 공간이다.
왜 index가 필요하냐면, 우리는 수정한 모든 파일을 커밋하지 않기 때문이다. 내가 10개의 파일을 수정했지만 7개의 파일만 커밋하고 싶을 수 있다. 10개의 파일 중에서 7개의 파일을 선택하는 과정을 indexing, 또는 staging이라고 부른다.
index 덕분에 우리는 모든 수정사항을 커밋하지 않고, 내가 원하는 일부 변경사항만 커밋할 수 있게 되었다.
Push
내 로컬에서 변경된 사항을 remote repo에 저장하기 위해서는, push를 해야한다. Upload라고 생각하면 쉽다. Commit을 push하면, 내 커밋과 동일한 상태로 remote repo가 업데이트 된다.
Pull
Push가 업로드였다면, Pull은 다운로드이다.
Commit
- origin/master : 원격 저장소 「origin」의 브랜치인 「master」의 위치를 나타내고 있습니다.
- origin/HEAD: 원격 저장소 「origin」을 복제해 올 때 다운로드되는 커밋의 위치를 나타내고 있습니다. 일반적으로 「origin/master」와 동일한 위치를 가리킵니다.
- master: 로컬 저장소 브랜치인 「master」의 위치를 나타내고 있습니다.
origin이라는 말이 헷깔릴 수 있는데, origin은 git 서버에서 내려받으면 자동으로 생기는 remote의 이름이다. 서버에서 저장소를 clone하면 git은 자동으로 master branch를 origin/master 브랜치의 트래킹 브랜치로 만드는데, origin/master가 remote를 트랙킹하는 브랜치이다.
Merge
내가 끌어온 저장소가 최신 버전이 아닌 경우, 즉 내가 pull 을 실행한 후 다른 사람이 push 를 하여 원격 저장소를 업데이트 해버린 경우에는 내 push 요청이 거부되어 버린다. 이런 경우 병합(merge)이라는 작업을 진행하여 다른 사람의 업데이트 이력을 내 저장소에도 갱신 해야한다. 만약 병합하지 않은 채로 이력을 덮어쓰게 되면 다른 사람이 push 한 업데이트 내역의 커밋이 사라져 버리기 때문이다.
자동으로 Merge가 안될 때
원격과 로컬 저장소에서 동일한 부분을 변경하면, 자동으로 어느쪽을 저장할 지 알 수 없으므로 충돌이 생긴다.
<<<<<HEAD
(코드1)
/========
(코드2)
/>>>>>> (이상한 숫자들)
이렇게 깃에서 충돌난 부분을 표시해주면, 우리는 충돌난 부분을 수정한 후에 다시 커밋하면 된다.
master 브랜치
'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어진다. master branch를 integration branch로 많이 사용한다.
브랜치 전환하기
'**checkout**'은 브랜치를 전환할 때 쓰는 명령어이다. 체크아웃을 하면, 우선 브랜치 안에 있는 마지막 커밋 내용이 Work Tree에 펼쳐지고, 이후에 실행한 커밋은 전환한 브랜치에 추가된다 .
rebase와 merge의 차이
rebase(재배치)는 merge 커밋을 보기 싫을 때 한다. 두개의 브랜치를 하나로 합치는 것 보다, 한 브랜치를 기준으로 나머지 커밋들을 그 브랜치에 붙여주는 느낌이다.
rebase를 쓸 일은 거의 없겠지만 있다면 위의 블로그를 읽어보는 걸 추천한다.
HEAD
'HEAD' = 현재 사용중인 브랜치의 선두 부분
~, ^ 이런 기호를 사용해서 현재 커밋으로부터 특정 커밋의 위치를 가리킬 수 있다.
HEAD ~3은 3개 전의 커밋이고, HEAD^은 원본이 여러개일 때 몇번째 원본인지를 알려준다. HEAD ~1 ^1, HEAD ~2 ^2는 브랜치가 두개 있어서 원본이 두개인 경우의 예제이다.
stash
//TODO
'Others' 카테고리의 다른 글
| safari 여러개 윈도우 사이에서 창 전환하는 단축키 (0) | 2019.07.26 |
|---|---|
| 파이널컷 용량 줄이기 (0) | 2019.07.05 |
| [VisualStudio] LNK 1168 에러가 계속 날 때 (0) | 2019.06.05 |
| [Vimium] 물음표는 되는데 키 안먹을 때 (0) | 2019.01.02 |
| Safari에서 개인정보 보호 윈도우 사용하기 (0) | 2018.09.22 |