Git

2005년에 첫 선을 보인 오픈 소스 버전 관리 시스템. 사실상 버전 관리 시스템의 표준으로 자리 잡았고, 그 이전의 강자들을 다 씹어먹어 버렸다. 리누스 토르발스가 개발했으나 지금은 리누스는 개발에는 손을 뗀 상태이며 다른 여러 개발자들이 운영하고 있다. 리누스도 직접 개발에 손을 뗐다 뿐이지 여전히 프로젝트의 운영 권한을 쥐고 있으므로 리눅스 소스 코드 관리는 당연히 이걸로 하고 있다. 애초에 Git을 개발한 계기가 기존의 VCS에 빡친 나머지 리눅스와 같은 거대한 프로젝트도 잘 관리할 수 있는 시스템을 만들기 위한 것이었으니.

여러 개발자가 팀으로 작업하는 프로젝트에서는 소스 코드를 가지고 이 사람 저 사람들이 이렇게도 해 보고 저렇게도 해 보고 하게 마련이고, 그러다 보면 남의 코드를 건드려서 문제를 일으키기도 하고 버그가 있을 수도 있고, 개선했다고 만든 코드가 영 아니라서 되돌려야 할 수도 있다. 그래서 버전 관리 시스템을 사용하게 되는데, 리누스 토르발스는 CVS나 서브버전(Subversion, SVN) 같은 기존의 VCS를 별로 마음에 들어하지 않아서 메일링 리스트를 사용해서 소스 코드를 관리했지만 덩치가 점점 커지면서 결국 VCS를 안 쓸 수 없게 되었다. 그래서 2002년부터 채택한 게 BitKeeper라는 것인데, 상용 소프트웨어라 오픈 소스 진영에서는 비난하는 사람들도 많았지만 이만한 기능을 제공해 주는 VCS도 딱히 없는 지라 그냥 쓰고 있었다. 그런데 BitKeeper 측에서 갑자기 리버스 엔지니어링을 문제 삼아 일부 개발자들을 막는 사태가 벌어지면서, 리누스가 이에 빡친 나머지 '그냥 내가 직접 만들고 만다!' 하고 단 2주만에 개발한 게 Git이다. 그래서 BitKeeper는? 리누스를 빡치게 만든 죄로 Git에 점유율을 다 털리고 뒤늦게 오픈 소스로 전환하긴 했지만 대세를 돌리기에는 역부족.

오픈소스계의 영원한 아이돌 리누스 토발즈는 리눅스 커널을 관리하는 기존 툴이 엉망인 것에 너무 빡친 바람에 git이라는 소스관리 툴을 만든다. 그게 리누스에게 얼마나 깊은 빡침이었는지, 단 2주만에 완성하는 기염을 토했다 (그러고는 후에 “git 만드는게 제일 쉬웠어요” 라는 인터뷰로 나와같은 빠돌이를 지리게했다).

"오픈소스의 승리", Human-Computer Symbiosis.

Git은 순식간에 기존의 강자들을 누르고 버전 관리 시스템의 대세가 되어 버렸고, 그만큼 기존의 VCS에 비해 막강한 기능과 안전성을 자랑하는 소프트웨어다. 오죽하면 '리누스 토르발스는 리눅스 안 만들었어도 Git만으로도 존경을 받았을 거다'는 말이 나올 정도. Git 이외에는 아파치재단이 운영하고 있는 서브버전이 어느 정도 점유율을 가지고 있다. 일단 아파치재단이 이걸 쓰고 있으니. CVS는 2008년 이후로는 개발이 중단된 상태고 일부 핵심 개발자들이 서브버전으로 넘어간 것으로 알려져 있다. IDE도 대체로 서브버전까지는 지원하지만 Git 지원에 중심을 두고 있다.

이를 기반으로 한 온라인 서비스인 GitHub가 소스포지를 누르고 오픈 소스의 성지로 자리를 굳혔고 Bitbucket, GitLab과 같은 서비스도 한자리씩 차지하면서 Git의 입지는 더더욱 강고해젔다. 비주얼 스튜디오, IntelliJ IDEA를 비롯한 웬만한 IDE들도 버전 관리를 위해 Git을 기본으로 지원하고 있다. 팀 작업을 하지 않는 개인 개발자라고 해도 이러한 서비스를 이용하기 위해서는 Git에 익숙해져야 한다.

Git의 가장 큰 특징이라면 '분산 버전 관리 시스템'(Distributed VCS, DVCS)을 기반으로 하고 있다는 부분이다. Bitkeeper나 CVS 같은 기존의 버전 관리 시스템은 중앙 집중식 시스템을 사용했다. 즉 중앙에 버전을 관리하는 저장소 서버가 있고, 개별 클라이언트는 여기에서 코드를 받아오고 코드를 밀어넣는 구조로 되어 있다. 대체로 클라이언트에는 최신 버전의 코드가 남아 있고, 이전 버전들은 중앙에서 관리하는 방식이다. Git은 원격 저장소를 지원하지만 로컬에도 이전 버전들을 가지고 있다. 이렇게 되면 로컬에 그만한 저장용량을 필요로 하지만 요즘의 저장 장치 크기로 볼 때 단순 텍스트 파일인 소스 코드가 차지하는 용량은 미미한 수준이다. 대신 인터넷 연결이 끊어져 있는 상태에서도 로컬에 버전을 저장하고 작업을 하다가 인터넷 연결이 될 때 변경된 내용을 푸시하면 되므로 편의성이 많이 올라간다. 또한 브랜치를 만들고 병합하는 과정에서도 분산 시스템의 특징이 반영되어 있기 때문에 중앙 집중식에 비해 브랜치 간 충돌 위험이 적은 편이다.

윈도우를 사용하는 개발자들에게는 약간 다른 의미로 쓸모가 있는데 윈도우용 Git에 들어 있는 Bash 쉘이 은근히 물건이다. UNIX 계열, 즉 POSIX 호환 쉘이 필요할 때 굉장히 요긴하다. 이전에는 Cygwin이 좋은 해법이었지만 어차피 개발자라면 Git은 깔아야 하고, 거기에 기본으로 딸려오는 게 Git Bash라 별도 설치가 필요한 Cygwin과는 편의성이 비교가 안 된다. WSL은 아예 가상머신을 하나 설치해야 하므로 덩치가 큰 데다가 파일 시스템이 따로 놀기 때문에 윈도우 파일 시스템 속을 그대로 돌아다닐 수 있는 쉘로는 Git Bash만한 게 없다. 비주얼 스튜디오 코드의 터미널로 윈도우 커맨드 대신에 이놈을 쓸 수도 있어서 설정만 잡아주면 대단히 편리하다.