[Git] 협업을 위한 최소한의 Git 안내 사용서

안녕하세요.

오늘은 개발자를 위한 Git 설명이 아닌, 개발자가 아닌 분들에게 협업을 위한 최소한의 Git 정보를 전달 드리기 위해 포스팅 합니다. 

 

다름이 아니라, 현재 활동중인 게임 개발 팀에서 디자이너분들에게 Git에 대해 설명드리기 위해 문서를 작성했었습니다.

그리고 해당 문서를 조금 다듬어 블로그에 공유하면 다른 분들에게도 도움이 될 것 같아 작성해보았습니다.

Git은 제대로 사용하면 정말 복잡하고, 여러 개념이 있습니다만.. 이번 포스팅에선 정말 축약하여 쉽게 설명하기 위해 가감했다는 걸 감안해주세요. 감사합니다.

Git이란

Git은 소스 코드 버전 관리 시스템입니다.

• 소스 코드의 수정 사항을 관리해 사용자가 읽거나, 되돌리거나, 다른 시점의 코드로 변경하는 등의 작업을 진행할 수 있게 됩니다.
  • 아직 잘 이해가 되지 않을 수 있는데, 아래에서 Git을 사용하는 이유에 대해 읽고 다시 읽으면 이해가 되실 거에요.
• Git 공식 사이트에서 Git을 설치하면 이러한 내용 전부를 사용할 수 있게 됩니다.
• 기본적으로 이러한 시스템의 동작은 로컬에서(원격에 올라가지 않고, 내 컴퓨터 안에서) 이루어지게 됩니다.

GitHub/GitLab이란

그럼 Github, Gitlab 등은 Git과 무슨 차이가 있는걸까요?

• Github/Gitlab은 내 로컬에만 존재했던 소스 코드의 버전 관리 사항을 원격(인터넷)에 공유해서 사용할 수 있도록 해주는 시스템입니다.
• 그래서 Github/Gitlab의 경우, Git 시스템을 사용할 수 있는 원격 사이트쯤으로 생각해주시면 됩니다. 그렇기에 두 사이트 모두 크게 차이는 없습니다.

Git을 사용하는 이유

만약 Git 시스템을 사용하지 않는다고 치고, 다음과 같은 상황을 생각해봅시다.

우리에게 Git이 없다면.. (절망편)

1. 한창 런칭중인 게임 소스코드 존재
2. 5월 1일, A 개발자가 B 개발자가 개발한 내용에서 필요 없어보이는 소스 코드 1줄 제거
3. 5월 2일, 새로운 기능 추가로 100줄 정도의 코드 추가
4. 5월 3일, 새로운 기능의 버그로 소스 코드 대량 수정 (추정 불가)
5. (한참의 시간이 지난 후)
6. 원래 잘 돌아가던 게임 기능이 갑자기 버그가 난다는 제보
7. 버그를 수정해야 하는데, 어느 시점에서부터 소스 코드가 잘못된 건지도 알 수 없고 난리난리
8. ((폭풍 야근))

우리에게 Git이 있다면.. (희망편)

1. 1~6번까지의 과정은 그대로 진행되고…
2. 버그가 나는 기능 관련 소스코드의 Git 기록을 살펴본다.
3. 5월 1일 A 개발자가 관련 소스 코드를 지운 기록이 있다.
4. 해당 시점 이전으로 코드를 돌려보고, 실행해본다.
5. 어? 이 시점에선 잘된다. 원인 파악 완료.
6. ((해피 엔딩))

이렇게 소스 코드의 기록이 남아있는 것으로 우리는 엄청난 이점을 가져갈 수 있습니다.

또한, 이것은 1차원적인 이유일 뿐입니다. 외에도 여러가지 장점이 있지만.. 더 나아가 로컬 Git 시스템이 아닌 원격 Git 시스템을 사용하면 여러 사람과 협업도 편리하게 진행할 수 있습니다.

SourceTree? Kraken?

우선적으로 Git은 기본적으로 CLI 명령어를 통해 동작하게 됩니다. 이러한 과정은 명령어를 알아야 하고, 이해해야 하기 때문에 상당히 어렵습니다.

그렇기에 이런 과정을 GUI(Graphical User Interface)를 통해 진행할 수 있도록 하는 툴들이 있다면 훨씬 사용하기 쉽겠죠. 이러한 툴들은 이미 많이 나와 있습니다. 그것들이 바로 SourceTree나 Kraken 등 입니다.

모든 툴은 기호에 따라 편한 것을 사용하면 됩니다.

알아야 하는 최소한의 개념

Repository

• 흔히들 레포(이하 레포) 라고 줄여 부릅니다.
• 예를 들어 A라는 게임잼 프로젝트가 있다면, A 프로젝트의 코드 목록들을 특정한 공간에 저장하게 됩니다. 바로 그 공간이 레포입니다.
• 물론 이 레포 안에 여러개의 프로젝트를 동시에 저장할 수도 있지만, 보통은 하나의 프로젝트를 하나의 레포에 보관합니다.

Clone

• Github/Gitlab을 사용해 원격 레포 올려둔 코드 덩어리를, 말 그대로 내 컴퓨터(로컬)에 복사하는 과정을 clone(이하 클론)이라고 합니다.
• 로컬에 최초 1회 클론을 진행했다면, 이후는 원격에 업데이트 된 내용이 있는지를 확인 이후 최신화 하는 과정만 진행해주면 됩니다.

Branch

• 새로운 게임잼 프로젝트를 진행한다는 가정을 해봅시다.
• 총 세명의 사람들이 공통 프로젝트에서 작업을 진행해야 합니다.
  • A → 점프 기능 개발
  • B → 애니메이션 개발
  • C → 공격 기능 개발
• 각각의 기능 구현을 별도의 분리된 공간에서 진행할 수 있도록 한다면 훨씬 편할 것 같습니다. 이러한 기능이 바로 브랜치 입니다.
• 모든 작업 시 브랜치를 필수적으로 사용해야 하는 것은 아니지만, 작업을 합치는 과정에서 훨씬 가독성 있고 편하게 작업할 수 있습니다.
• 보통 하나의 주제로 브랜치를 제작하고, 작업이 진행된 이후 합치고 삭제합니다. (이후 새로 파고..의 반복)

Merge

• 앞서 설명했던 브랜치 개념의 연장선입니다.
• 모든 레포는 기본 브랜치가 존재합니다. (이름은 보통 Main 혹은 Master 입니다.)
  • 이러한 기본 브랜치를 master라고 부르겠습니다.
• 그렇기에 일반적으로 모든 작업은 Master 브랜치를 기준으로 진행되어야 합니다. 그렇기에 브랜치를 각각 나눠 가진 후, 작업이 완료되었다면 각 브랜치를 master 브랜치로 병합 하는 과정을 진행해야 합니다. 그게 바로 merge 작업입니다.

Commit

• Git은 기본적으로 파일의 변경 사항을 추적합니다. 특정 파일이 A 시점에서 B 시점으로 넘어갔을때, 어떤 줄이 변경 되었는지 파악한다는 것입니다.
• 우리는 이러한 ‘시점’을 마치 게임을 진행할 때 각 게임 시점에서 세이브 파일을 저장하듯이, 원하는 변경 사항이 생겼다면 세이브 할 수 있습니다. 그 세이브 사항에 이름을 붙이는 것이 바로 커밋 입니다. (파일의 단순 저장과는 다릅니다. 게임 세이브의 개념처럼 생각해주셔야 합니다.)

예를 들어 오늘 먹은 음식.txt라는 파일이 초기에 이러한 파일이었다고 생각 해봅시다.

1. 초기 상태

- 오늘 먹은 음식
- 바나나, 사과, 파인애플

2. 내용 수정

- 오늘 먹은 음식
- 바나나, 사과, 파인애플, 요거트

• , 요거트 항목이 추가되었다.

분기

• 여기서 요거트가 추가되었다는 사실을 커밋(=게임 세이브) 하고 싶다면?
  • 먹은 음식에 ‘요거트’ 추가 라는 커밋 메시지를 남긴다. (내용은 무엇이든 될 수 있습니다.)
  • Git 기록에 커밋 메시지를 남긴 시점이 추가되었다. (아직 원격에 올라가진 않은 상태, 원격에 올린다는 것은 아래 push 항목에서 설명합니다.)
• 여기서 커밋(세이브)를 하고 싶지 않다면?
  • 단순히 로컬 파일인 오늘 먹은 음식.txt 만이 변경되었을 뿐이다.
  • Git 기록엔 아무 영향이 없

위 설명처럼 우리가 단순히 로컬에서 파일 내용을 저장하는 것은, 레포에 아무런 영향이 없습니다. 파일이 이전과 달리 유의미한 변경 상태가 일어났을때, 그 변경사항만을 커밋을 만들어 레포에 공유해야만 합니다.

Push

• 위에서 설명했던 커밋 작업은 로컬에만 남길 수도 있습니다. 기록은 남겼지만, 그 기록 자체는 원격에 공유되지 않을 수 있는 것입니다.
• 그러나 우리는 협업을 위해 원격에 올려야 합니다. 그래야 다른 사람들도 내가 요거트를 추가했다는 사실을 공유받아 작업할 수 있기 때문입니다. 이처럼 로컬의 ‘커밋’ 기록을 원격에 올리는 작업을 push 라고 합니다.

Pull

• 특정한 원격 레포 브랜치의 내용을 내 로컬 레포 브랜치로 가져와 최신화 하는 작업입니다.