본문 바로가기
개발 관련 학습 및 문제해결

깃 용어 이것만 알면된다! 기초 완벽 정리[20221122-TIL]

by 날파리1 2022. 11. 22.

깃 뭔데..? 너무 어려운 거 아냐?

라고 생각한 당신 이 글을 보라.

 

는 농담이고 깃을 계속 써왔지만 챙겨야 할 과제에 밀려오는 강의에 풀어야 할 프로그래머스 문제를 챙기느라 깃은 제발... 충돌만 피하자 라는 기도 메타(기도 메타는 아니고...) 비슷하게 정확히는 깃과 충돌 나지 않는 법만 선택해서 요리조리 피해 다녔다.

처음 프로그래밍을 배우면 프로그래밍 언어도 너무 어려운데 애써 작업한 것들이 알아듣기도 어려운 깃이 자신만의 언어로 오류 메시지를 내뱉고 애써한 작업을 날려먹어 해결해야 하노라면... 그날이 바로 깃을 포기하게 되는 날이다.

깃 눙물 짤

아무튼 각설하고

깃(Git)이란?

분산 버전 관리시스템(Distributed Version Control Systems)으로 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들의 파일에 대한 작업을 조율하는 데 사용하는 시스템이다.

 

깃의 대표적 특징은 죄다 설명이나 정의가 어렵게 되어 있다는 건데 즉 요약하면

과거에 일일이 수동으로 백업을 해두고 코드를 작성하고 다시 작성한 코드를 검증하고 사용해도 되면 정식 코드로 등록해 사용하는 등의 실수가 잦을 업무 방식을 버전으로 관리해준다는 것이다.

버전으로 관리함으로써 내가 merge(병합)한 main은 항상 작동이 되는 검증된 코드만 업데이트를 하고 이외의 코드를 테스트하거나 만드는 것은 각각의 새로운 branch에서 작업하여 이러한 작업 내역을 버전으로 관리할 수 있다. 즉 내가 커밋한 포인트를 기점을 버전으로 삼아 언제든 이동하고 돌아갈 수 있어 깃의 규칙 내에서 잘 사용만 한다면 언제든 코드를 작성하고 백업해오고 할 수 있다.

 

깃허브(Git Hub)란?

깃과 깃허브의 차이

너무도 헷갈리기 쉬운 두 개념인데 사실 별 거 없다.

깃허브란 깃을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스

깃은 버전을 관리해주는 시스템 그 자체를 의미하고 깃허브는 이러한 깃을 사용한 것들을 서버에서 저장이나 배포 등의 서비스를 제공하는 웹 서비스이다.

깃 = 버전 관리해주는 도구

깃허브 = 깃을 이용해서 다양한 작업 ( 협업, 코드 공유 , 버전 관리, 배포)을 하게 해주는 공간

이라고 생각하면 편할 것 같다.

 

1. 브랜치란?(branch)

깃을 사용하면 가장 먼저 듣게 될 단어 중 하나이다. 깃은 이름 그대로 메인이라는 곳에서 코드를 관리하는데 ( 관리라는 말이 조금 이상하긴 하다 관리는 모든 곳에서 한다. 다룬다라고 생각하면 편하다.) 이 메인이라는 곳은 '작동이 제대로 되는 인증된 코드'만 저장하는 게 컨벤션(원칙)이다.

따라서 브랜치라는 개념이 나온다. 브랜치는 영어로 나뭇가지 또한 나뭇가지에서 파생된 말로 본사의 하위 개념인 지사라는 뜻을 가지고 있는데 메인에서 다른 버전을 만들어서 이 브랜치라는 곳에서 서버를 관리해 줄 수 있다.

 

즉 브랜치란 제대로 된 코드를 저장하는 메인과는 별도로 코드를 테스트하고 작성하고 관리할 무대이다.

우리는 이 브랜치를 생성해서 여기서 코드를 작성하고 커밋을 하고 add를 하고 메인에 병합(merge)시켜 줄 수 있다.

 

브랜치에서는 작업을 마친 것을 커밋하고 코드가 모두 검증되었을 때 메인에 머지한 후 해당 브랜치는 삭제하는 것이 일반적이다. 삭제하더라도 커밋을 해놓았다면 그 버전으로 언제든 돌아갈 수 있으니 브랜치 삭제와 내 코드로 다시 돌아가지 못할 걱정과는 무관하다.

2. 커밋(commit)

커밋은 보다 익숙한 단어일 텐데 작업의 한 단위라고 생각하면 편하다.( 커밋 = 작업로서의 한 단위의 의미가 아니라 하나의 유의미한 작업을 한 후에는 add를 통해 스테이지에 올려주고 이것을 커밋한다.)

앞서 말했듯이 작업의 유의미한 단위로 쪼개 주는데 (이것의 단위를 작게 잘 나누는 것 또한 깃을 잘 쓰는 좋은 능력이면서 프로그래밍을 잘하는 방법이다. 작업을 작게 잘 나눈다는 의미는 일의 전체를 알고 부분까지 잘 파악한다는 뜻이기도 하기 때문이다.) 이것을 커밋하여 내가 작성한 코드를 작업 단위 상태로 구분하여 돌아갈 버전 포인트를 지정해주는 행위라고 생각하면 좋다.

3. 메인(main)

작업한 파일을 add와 커밋한 후 이 코드를 협업 멤버가 모두 공유하는 장소에 머지(병합)를 시켜주는데 이것을 모두 통합해서 공유하는 무대이다. 따라서 메인에는 반드시 모두 작동되고 테스트가 통과된 '공인' 된 코드만 올라가야 한다. 다른 멤버들이 모두 공유하고 공통된 작업물을 서로 나누어 작업하는 것이기 때문에 메인에서 받아오는 코드는 오류가 있어서는 안 된다. 

4. 애드(add)

애드는 작업한 파일들을 스테이지 위에 올려주는 행동이다. 스테이지에 add 한 파일들은 깃의 저장소로 pull request(PR이라고도 한다.)를 날리기 위해 commit point를 만들 수 있다.

이때 스테이지에 올릴 파일과 올리지 않을 것을 선별할 수 있다.

5. 스테이지 언스테이지(staged unstaged)

스테이 지드와 온스테이지는 쉽다. 말 그대로 작업한 파일이 깃 커밋 포인트를 만들도록 올라갔냐 올라가지 않았냐이다. 여기서 추가적으로 알아야 할 것은 tracked인데 이것은 조금 복잡하니 차차 더 알아보도록 하자.

6. 헤드(head)

소스 트리에서 main이나 브랜치들의 tip(끝 부분)을 헤드라고 한다. 작업을 하다 보면 

Your branch is ahead by ** commits 

 

이런 문구를 많이 보게 될 텐데 이유는 매우 다양하지만 주로 main의 헤드 위치와 내 현재 브랜치의 헤드 위치가 서로 맞지 않을 때 나오는 문구이다. 따라서 이 헤드를 서로 같은 위치가 되도록 맞춰주어야 한다.

왜요?

왜냐면 main은 내가 기록한 커밋과 코드의 업데이트들을 가지고 계속 추가되면서 하나의 머지마다 헤드가 앞으로 나아가는데 브랜치 또한 유의미한 작업마다 생성과 삭제를 반복하면서 메인에서 파생되고(새 브랜치 생성) 다시 메인으로 병합(작업 -> 애드 -> 커밋 후 메인으로 병합)을 거치면서 나아가야 하는데 이때 작업하는 브랜치를 바꾸지 않고 한 브랜치에 계속 작업을 하고 push 하고 merge를 하거나를 반복하며 메인과 작업 브랜치의 싱크를 맞춰주지 않은 채 계속하다 보면 내 현재 브랜치의 헤드와 메인의 헤드가 다른 곳에 있다. ( 즉 내 로컬 브랜치가 메인이 업데이트된 것을 못 받아오는 상황)

이럴 때에는 fetch와 rebase를 통해서 내가 있는 브랜치의 헤드를 메인의 헤드에 강제로 맞춰주는 방법이 있다. (강제라고 썼지만 rebase는 아주 유용한 도구이다. 애매하게 소스 트리를 망치기보다 rebase로 헤드를 맞추는 것이 낫다.)

 

추가적으로 리 베이스와 강제로 푸시해버리는 push -f (푸시 포스) , 잠시 작업을 보류하는 스태시 등 여러 가지가 있지만 이는 다음 글에서 담도록 하겠다.

 

오늘은 깃이 무엇인지 그리고 깃허브와 다른 점 그리고 자주 쓰이지만 완전히 정리가 안 되는 용어들만 숙지하고 넘어가도록 하자.

 

 

진심으로 깃 공부하는 모든 신입 개발자들 화이팅..

댓글