실제 개발을 업으로 삼게 되면 어떤 프로젝트에서도 먼저 접하게 되는 것이 소스 관리 프로그램이다. (형상 관리 툴)
그중 Git은(깃) 가장 널리 쓰이는 프로그램 중 하나로. 리눅스의 창시자인 리누스 토발즈(Linus Torvalds)에 의해 개발이 시작됐으며 gnu로 대표되는 오픈소스 진영의 구심점이 되기 위해 만들어졌다.
그런데 이는 매우 잘 만들어진 형상 관리 툴로 인정받게 되었고, 지금은 오픈 소스 진영뿐만 아니라 세상 거의 모든 종류의 개발 환경에서 사용되고 있다.
위의 Git 공식 사이트에서 Windows 버전을 다운로드하고 실행시키면 설치 과정에서 이것저것 물어본다.
크게 의미 있는 옵션은 없으므로 그냥 확인을 누르며 넘어가자, 그럼 아래와 같이 설치를 시작한다
파일이나 폴더를 오른 클릭 했을 때 Git 옵션이 보이면 설치가 잘 된 것이다.
GIT이란?
형상 관리 툴(머지 툴, 소스 관리 툴), 그게 뭐냐?라고 묻는다면 한 번에 설명하기 애매한 부분이 있다.
보통 개발 프로젝트들이 다수의 인원으로 진행되기 때문에 서로간의 마찰을 줄이기 위해 자연스럽게 필요해진 툴이며, 현대 개발자들에게 있어 이를 다루는 법은 필수 교양에 가깝다.
게임 개발에서는 SVN과 git이 제일 많이 쓰이고 있다
기본 개념
위의 Git의 로고에도 들어있듯이 이런 모양의 그림이 git관련 자료 여기저기에 보인다.
이는 Git이 가진 트랙킹 기능을 상징하는 기호
가로선은 시간의 흐름을 나타내고 중간중간의 동그라미는 그 시점에 저장된 파일이나 코드들을 의미한다. 만약 마지막 동그라미 코드가 어디가 이상하거나 불의의 사고로 뭔가 잘못되었다면 우린 바로 전 동그라미로 돌아가서 그 시점부터 뭔가를 다시 시작할 수 있을 것이다.
그런 의미해서 Git이 뭐 하는 건데요?라고 물으면 Git은 백업해주는 프로그램입니다.라고 말할 수도 있을 것이다.
필자는 과거 한 사이트를 관리하면서 HTML과 CSS내역 들을 지속적으로 커스터마이징 해왔다.
이를 편집하다, 뭔가 잘못 돼버리면, 바로 전 상황으로 돌아가기 위해 위의 그림처럼 그날, 그날 날짜를 파일명에 붙여 저장해두었다
뭔가 딱 봐도 더럽지 않은가? 6월 27일인 오늘도 바꾼 게 있어서 백업해 둬야 한다. 하지만 이제부턴 저런 식으로 관리하기보단 좀 더 세련되게 Git으로 관리하고자 한다.
Github
Github은 이런 Git프로그램을 지원해주는 어떤 하나의 웹사이트라고 보면 된다. 매우 크고 체계적인 웹사이트이긴 하지만 말이다.
보통 어떤 회사에서 “하나의 개발 프로젝트를 진행한다..”라고 말한다면 그건 보통 그 회사의 개발자들이 거대한 소스 뭉치들과 그에 관련된 데이터 파일들을 통째로 트랙킹 해가면서 위의 노란 선 모양 그림처럼 한 칸 한 칸 작업을 진행해 나아가고 있는 거라고 말할 수 있다.
그런데 프로젝트에 참여하는 개발자가 다수라면 그들은 노란 선위에 동그라미가 생길때마다, 다시말해 누가 프로젝트에 자기의 작업을 업데이트 할 때마다, 이것을 바로바로 공유할 필요가 있다.
그래서 그 동그라미들이 의미하는 코드들은 단순히 그걸 만든 개발자의 PC속에 담겨있는 것이 아니라. 그것을 만들지 않은 다른 개발자들이 모두 쉽고 빠르게 공유할 수 있는 상태가 되야 한다.
이때부터 상황이 복잡해진다. 하나의 프로젝트를 같이 개발한다고 해도, 모든 개발자가 같은 모니터 앞에 앉아서 그 하나의 코드를 함께 수정하지 않는다. 각각의 개발자들은 자신의 개발 PC에 앉아서 본인이 담당하는 파트를 만들어 나가며, 수정하고, 업데이트해 나간다.
따라서 시간에 따른 개발의 진행 과정이 개발자의 수만큼 갈라지게 되며 이것들이 필요한 시점에 합쳐져야 한다.
참고로 만약 완성되지 않은 각 개발자들의 작업들이 순간순간 실시간으로 프로젝트에 반영된다면 버그가 있는 불안전한 작업들도 프로젝트에 반영된다는 소리다 이러면 다른 개발자들에게 방해를 주게 될 것이다. 따라서 완성되었고 문제가 없다고 판단되는 코드들만 프로젝트에 합쳐야 한다.
이와 동시에, 두 사람의 코드는 서로 너무 달라지기 전에 적절한 시점에 합쳐져야 한다. 너무 많이 달라지면 나중에 합쳐지는데 애를 먹으며 그 과정에서 문제가 생기기 쉽다.
하지만 위의 그림에서, 설령 두 개발자의 프로젝트가 적절한 시점에 합쳐진다 해도 문제는 있다.
두 개발자가 같은 하나의 파일을 따로 수정하고 그것을 합치려고 한다면 어떤 일을 해야 할까?
수정한 파일들이 겹치는게 없다면 그냥 편하게 합치면 된다.
하지만 두명 모두가 수정한 파일이 있다면 그 파일안에는 두 개발자의 변경사항을 모두 집어넣어야 할 것이다.
이런 충돌 상태를 처리해주기 위해 Git는 시간 흐름에 따른 각 개발자의 모든 변화 내용을 라인 단위로 기록해둔다.
설령 두 개발자가 같은 파일을 수정했다 해도 그 코드 파일안의 같은 라인을 건드리지 않았다면 알아서 합쳐주는 작업을 한다.
일단 문제없이 합쳐서 동그라미를 만들어 주는것. (그 코드가 잘 돌아가던 말던..)
근데 두 개발자가 같은 파일의 같은 라인을 변경했을 경우는 Git도 어쩔 수 없다.
이런 충돌을 막기 위한 가장 좋은 방법은 개발자들간에 개발 일정을 조절하는 것이다. 눈치 빠른 베테랑 개발자들은 다른 개발자에게 이렇게 말할 수 있다.
“xx 씨 혹시 이번에 그 파일 작업하실 거예요?”
“네? 아.. 네 할 거 같은데요?”
“그러면 다른 일보다 그거 조금 서둘러서 먼저 해주세요, 다 되면 저한테 말 좀 해주시고요, 저도 거기 좀 바꿔야 해서..”
“넵~”
이렇게 한 개발자가 작업을 완료하고 나면 다음 개발자가 그 완료된 동그라미를 공유받아서 거기서 부터 자기 작업을 시작하는 것이 가장 심플하다.
이런 협업 환경 속에서 개발 프로젝트는 자연스럽게 그 중심이 되는 프로젝트의 메인 진행 과정이 존재하게 되고 개발자들은 그 메인 진행과정 속에 자신이 만들고 개선한 부분을 시시각각 넣게 된다.
이 그림처럼 메인 진행과정이 건, 개발자가 따로 진행하는 작은 진행과정이건 결국 모두 흐름을 가지게 되며 이것들이 나뭇가지 같다고 해서 branch라고 부른다. 위의 그림 중 메인 진행과정이라고 볼 수 있는 노란색 브랜치는 보통 master브랜치나 develop브랜치, 또는 main브랜치라고 이름 짓는다. 참고로 처음 협업 환경을 생성했을 때 처음 만들어지는 브랜치 이름이 master이다.
따라서 최소한 이 마스터 브랜치 하나만이라도 개발팀 팀원들에게 손쉽게 공유되고 업데이트될 필요가 있다. 그래서 이를 위한 사내 서버가 세팅되기 마련이다. 이 서버를 Git server라고 하고 이 서버에 대한 접근은 보통 외부인이 할 수 없도록 어느 정도 보안을 유지하기 마련이다. 회사에서 협업 과정을 통해 개발하고 있는 건, 보통 상품일 테니까 말이다.
하지만 굳이 각 회사의 git 서버가 아니더라도, 어느 불특정 다수의 개발자 그룹이 외부에 대한 공개 없이 보안을 유지하며, 또는 그 불특정 다수의 개발자들이 아무런 보안조치 없이 공개적으로, 브랜치를 생성하고 공유하며 업데이트할 수 있는 초대형 git 서버가 인터넷에 있는데. 그게 Github이다.
링크를 남겨둔다.