Git

2005년에 첫 선을 보인 오픈 소스 버전 관리 시스템. 사실상 버전 관리 시스템의 표준으로 자리 잡았고, 그 이전의 강자들을 다 씹어먹어 버렸다. 리누스 토르발스가 개발했으나 지금은 리누스는 개발에는 손을 뗀 상태이며 다른 여러 개발자들이 운영하고 있다. 리누스 자신에 따르면 실제로 Git 관련 일을 한 건 6개월 정도였다고 한다. 리누스도 직접 개발에 손을 뗐다 뿐이지 여전히 프로젝트의 운영 권한을 쥐고 있으므로 리눅스 소스 코드 관리는 당연히 이걸로 하고 있다. 애초에 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 창시자로만 알고 있다고 한다. Git 이외에는 아파치재단이 운영하고 있는 서브버전이 어느 정도 점유율을 가지고 있다. 일단 아파치재단이 이걸 쓰고 있으니. CVS는 2008년 이후로는 개발이 중단된 상태고 일부 핵심 개발자들이 서브버전으로 넘어간 것으로 알려져 있다. IDE도 대체로 서브버전까지는 지원하지만 Git 지원에 중심을 두고 있다.

이를 기반으로 한 온라인 서비스인 GitHub가 소스포지를 누르고 오픈 소스의 성지로 자리를 굳혔고 Bitbucket, GitLab과 같은 서비스도 한자리씩 차지하면서 Git의 입지는 더더욱 강고해젔다. 비주얼 스튜디오, IntelliJ IDEA를 비롯한 웬만한 IDE들도 버전 관리를 위해 Git을 기본으로 지원하고 있다. 팀 작업을 하지 않는 개인 개발자라고 해도 이러한 서비스를 이용하기 위해서는 Git에 익숙해져야 한다. 요즈음은 기업에서 개발자를 채용할 때 자신의 포트폴리오를 GitHub에 올려놓고 URL을 제공하도록 하는 게 일반적이라, 개발자로 밥 먹고 살려면 Git 사용법은 반드시 익혀놔야 할 정도다.

Git의 가장 큰 특징이라면 '분산 버전 관리 시스템'(Distributed VCS, DVCS)을 기반으로 하고 있다는 부분이다. Bitkeeper나 CVS 같은 기존의 버전 관리 시스템은 중앙 집중식 시스템을 사용했다. 즉 중앙에 버전을 관리하는 저장소 서버가 있고, 개별 클라이언트는 여기에서 코드를 받아오고 코드를 밀어넣는 구조로 되어 있다. 클라이언트에는 최신 버전의 코드만 남아 있고, 이전 버전들은 중앙에서 관리하는 방식이다. Git은 원격 저장소를 지원하지만 로컬에도 이전 버전들을 가지고 있다. 즉 각각의 클라이언트도 저장소 기능을 하고 있는 것이다. 이렇게 되면 로컬에 그만한 저장용량을 필요로 하지만 요즘의 저장 장치 크기로 볼 때 단순 텍스트 파일인 소스 코드가 차지하는 용량은 미미한 수준이다. 대신 인터넷 연결이 끊어져 있는 상태에서도 로컬에 버전을 저장하고 작업을 하다가 인터넷 연결이 될 때 변경된 내용을 푸시하면 되므로 편의성이 많이 올라간다. 만약 중앙 저장소가 어떤 이유로 손상되어 데이터가 손실되면 최신 버전을 제외하고는 이번 버전의 내용들이 날아갈 수도 있지만 DVCS는 로컬 저장소 중에 최신 버전을 가지고 있으며 데이터가 온전한 것을 이용해서 복구할 길이 있다.

또한 브랜치를 만들고 병합하는 과정에서도 분산 시스템의 특징이 반영되어 있기 때문에 중앙 집중식에 비해 브랜치 간 충돌 위험이 적은 편이다. Git에서 브랜치를 사용하는 전략은 어느 정도는 정립되어 있는 편인데, 즉 실제 릴리즈가 가능한 코드를 가지고 있는 master(main) 브랜치, 개발 중 버전이지만 실행 가능한 코드를 가지고 있는 develop 브랜치, 개별 기능 개발이나 버그 수정을 위한 브랜치, 이렇게 크게 세 가지 줄기로 브랜치를 관리하는 패턴을 많이 사용하고 있다.

반면 단점이라면 우선 높은 진입장벽. 버전 관리 시스템이 명령행 방식이 기본이라 명령어와 옵션 사용 방법은 어느 정도 익혀야 하지만 Git은 기능이 강력하고 대규모 분산 프로젝트도 원활하게 수행할 수 있는 반면 명령어와 옵션의 종류도 많고 사용 방법을 익히는 데 시간이 걸린다. 그러다 보니 많은 개발자들은 Git의 파워를 충분히 활용하지 못하고 자기 일에 쓰는 정도만 겨우 활용하는데 이러다가 버전이나 브랜치가 충돌한다든가 하면 바로 멘붕에 빠지기 일쑤다.

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