[Git] 버전 관리 시스템(VCS), 깃과 깃허브란?

안녕하세요. 깃과 깃허브 사용법에 대한 포스팅입니다. 깃과 깃허브에 대한 소개부터 작성 중인 문서의 버전 관리, 백업, 그리고 협업까지 방법을 알아보겠습니다. OS X를 기반으로 설명할 예정입니다. 간단한 목차는 아래와 같습니다.

 

• 깃과 깃허브란?
• 깃으로 버전 관리하기
• 깃허브에 백업하기
• 깃허브로 협업하기

우선 깃과 깃허브란 무엇인지 알아보겠습니다. 프로그래밍을 막 배우기 시작한 사람이면 깃과 깃허브란 말을 자주 듣게 될 것입니다. 프로그래밍을 독학한 저는 처음에 깃=깃허브라고 생각했습니다. 결론부터 얘기하면 깃은 버전을 관리해주는 프로그램(Version Control System)이고 깃허브는 깃으로 관리된 정보를 백업하는 저장소 서비스입니다. 깃에 특화된 웹하드라고 볼 수 있겠습니다. 깃 말고도 다른 vcs가 있습니다. 깃허브 말고도 여러 저장소 서비스들이 있습니다. 그러나 깃과 깃허브가 가장 유명하고 이용자가 많습니다. 따라서 문제가 생겼을 때 해결책을 찾기 쉽습니다. 또 그만큼 많은 소스가 올라와 있습니다. 그래서 많은 개발자들이 깃허브에 올라온 다른 사람들의 소스를 보며 공부하거나, 오픈소스를 개선에 기여하곤 합니다. 그런 이유에서 개발자의 놀이터라고 부르기도 합니다.

 

흔한 디자이너의 최종 파일.psd

그럼 개발자들은 깃을 왜 사용할까요? 위 사진은 인터넷에서 유머로 돌아다니는 사진입니다. 파일 수정이 잦은 디자이너들의 고충을 한 눈에 보여주는 사진인데요. 초안을 가져갔더니 수정해달라 하고, 수정해갔더니 다시 수정해달라 하고, 정말 최종인 줄 알았더니 또 수정이 필요하고. 이렇게 계속 파일명_최종, 파일명_최종2, 파일명_최종3, 파일명_진짜최종, 파일명_진짜진짜최종...과 같은 식으로 버전 관리를 합니다. 작업물 단위로 관리되고, 개인의 작업 비중이 큰 디자인은 이렇게 버전을 관리해도 큰 문제가 없어보입니다. 그렇지만 불편하고 안 이뻐보이네요.

 

버전 1.1 업데이트

소프트웨어 개발의 경우는 어떨까요? 디자인 파일의 경우 '다른 이름으로 저장'하여 원본을 그대로 두고 바뀐 버전을 저장하기가 용이합니다. 현재 개발이 완료된 프로젝트_ver1.0 폴더가 있다고 가정해보겠습니다. 현재 프로젝트 폴더에는 수천개의 파일이 있다고 합시다. 그 중 index.html만 수정하는 ver1.1 업데이트를 하고 싶어요. 기존 버전을 유지하기 위해 먼저 프로젝트_ver1.0에서 프로젝트_ver1.1을 복사했습니다. index.html을 수정했습니다. 괜찮은가요? 버전 관리에 있어 큰 문제는 없습니다. 하지만 index.html을 제외한 수천개의 똑같은 파일이 중복 생성되어 버렸네요. 그다지 효율적인 저장 방법 같지는 않습니다.

버전 2.0 업데이트

이번엔 ver2.0으로 대형 업데이트를 해야 해요. 언제 어떤 오류가 날 지 모르기 때문에 되돌아갈 수 있도록 기존의 ver1.1은 그대로 유지해야 합니다. 프로젝트_ver1.1에서 프로젝트_ver2.0을 복사했습니다. 그리고 한 50개의 로직과 관련된 파일을 수정한다고 하죠. 중간에 오류가 났습니다. 언제 어디서 어떤 파일 때문에 오류가 났을까요. 방금 수정한 a의 오류를 잡으니 아까 수정한 b에서 오류가 나네요. b 오류를 잡으니 c에서 오류가 나고. 엉망이에요. 아예 ver1.1부터 다시 시작해야할 것 같아요. 얼마나 비효율적인가요.

 

프로젝트 매니저의 입장에서 생각해봅시다. 5명의 팀원들이 각각 서로 다른 파일을 수정하도록 일을 분배했어요. 일단 똑같은 프로젝트_ver1.1 폴더를 복사해서 주어야 합니다. 그리고 팀원 A가 a 파일을 수정하면 그걸 받아서 프로젝트_ver2.0에 붙여넣어야 하네요. B가 b를 수정하면 또 그걸 붙여넣고. 그랬더니 a에서 오류가 나서 A가 다시 a를 수정하면 받아서 붙여넣고. 너무 불편하네요.

 

그래서 나온 게 깃과 깃허브입니다. 깃을 쓰면 매 업데이트마다 폴더를 복사할 필요가 없어요. 깃으로 관리되는 프로젝트_git 폴더가 있다고 합시다. 그냥 바로 해당 폴더에서 소스를 수정하면 돼요. 그리고 commit(깃의 저장 같은 개념)을 하면 새로운 버전에서 이전 버전과 무엇이 바뀌었는지 그 내용이 따로 저장이 됩니다. 그리고 깃 명령어를 통해서 이전 버전과의 차이점을 볼 수도 있고, 이전 버전으로 돌아갈 수도 있어요.

 

그리고 깃허브를 쓰면 보다 효율적인 백업과 협업이 가능합니다. 팀장이 프로젝트_git을 깃허브에 올립니다. 팀원들은 알아서 깃허브에서 프로젝트를 내려받으면 돼요. 그리고 본인이 수정한 부분을 push(깃허브로 업로드 같은 개념)하면 깃허브에 있는 프로젝트에 반영이 됩니다. 이번 포스팅에서 다 설명할 순 없지만 두 사람이 같은 소스를 작업했다든가 하는 예상 가능한 문제점은 모두 해결할 수 있도록 갖춰져 있습니다. 언제든지 자유롭게 아주 작은 단위의 코드조차 반영 가능하면서 반영 전 버전을 유지합니다. 이전 버전과 무엇이 바뀌었는지 비교하기도 쉽습니다. 여러 명이 같은 소스를 작업하면서도 굉장히 효율적으로 프로젝트의 버전을 관리할 수가 있어요.

 

이 글을 읽는 분들은 아마 개인 프로젝트를 주로 하고, 소스의 많은 수정도 없는 초보 개발자일 것입니다. 사실 저도 그래서 깃과 깃허브 사용이 늦었어요. 나중에 알았지만, 초보자들에게도 깃과 깃허브를 사용할 충분한 유인이 있습니다. 본격적으로 깃/깃허브 사용법을 강의하면서 설명드리도록 하겠습니다. 다음 포스팅은 깃 설치입니다.