Git 정리 1편: 기초 개념과 사용법

 개발 동아리에 들어와 처음으로 팀 프로젝트를 시작했다. 협업을 위해서는 Git 사용이 필수적인데, 지금껏 간단한 코드만 작성하다보니 Git을 제대로 써본 적이 없었다. 뒤늦게 부랴부랴 익혀보겠다고 찾아보지만... 이상하게 개발 쪽에서는 초보자를 위한 설명보다는, 이미 아는 사람에게 더 잘 설명하는 글들이 더 많은 것같다. 참 아쉬울 따름. 어쨌거나 내가 쓰기 위해 조금은 정리해둘 필요가 있을 것 같다.

 

---

 

명령어에 대한 전반적인 틀

출처: https://www.devguide.at/en/git/pull-push-the-remote-repository/

 

 우선 평상시에 코드 짜는 곳을 work space라 한다. work space에서 작업하던 파일을 컴퓨터 안에 백업해놓듯 저장해놓는 게 바로 local repository(저장소). 그러니까 local은 작업하고 있는 컴퓨터라 보면 된다. 단지 실제로 작업하던 work space를 따로 폴더로 빼놔 저장할 뿐(.git folder)

 

 Local repository에서는 내가 작성한 파일들을 버전별로 관리할 수 있다. 예를 들어 시간표 프로그램을 작성하고 있다고 하자. 나는 다음과 같이 단계별로 코드를 작성했다.

 

1. 레이아웃 작성

2. 스타일 적용

3. 함수 구현

 

 원래라면 1, 2, 3을 무대뽀로 work space에서 진행하겠지만, git을 이용해 각각의 단계에서 작업 환경을 저장할 수 있다. 1을 끝낸 뒤 버전 #1로 저장, 2를 끝낸 뒤 버전 #2로 저장, 3을 끝내...려 했으나 무언가 이상한 일이 벌어졌다. 왠지 모를 버그로 개발 웹페이지에서 에러가 발생했고, 그 이유를 도저히 찾을 수 없다. 이때 이전에 저장했던 버전 #2 상태의 코드로 되돌릴 수 있다. 혹은 더 이전으로 가고 싶다면 버전 #1로도 갈 수 있다. 전부 Local repository에 백업이 된 상태이기 때문이다.

 

 실제로 개발 동아리에서 2048을 구현할 때, 나는 내 코드가 어떻게 돌아가는지 전혀 이해하지 못했다. 어느 순간 AI의 코드가 내 환경을 잡아먹고 있었다. 그러다보니 리팩토링을 전혀 할 수 없었고, 구현된 로직을 변경하기도 불가능했다. 결국 다시 내 코드로 만들어야 하는데, 이 상황에서는 맨 처음부터 다시 작성하는 것 외에는 방법이 보이지 않았다. 만약 이때 내가 각 기능별 구현 단계마다 버전을 저장했다면? 그랬다면 내가 코드를 온전히 이해했던 마지막 순간의 코드들은 살릴 수 있었을 것이다. 황무지에서 다시 삽질을 하며 시작할 필요가 전혀 없는 셈이다.

 

 이게 바로 git의 존재 이유 중 하나인 버전 관리다. 작업 능률을 위한 길라잡이. 사실 팀프로젝트를 하며 git을 사용하긴 했지만, 앞으로는 혼자 코드를 작성할 때도 습관적으로 git을 사용할 예정이다. 한 번 경험해보니 안 쓸 이유가 없다.

 

---

 

 그 다음으로는 협업을 위해서다. local repository에 최종적으로 작성한 버전을 저장했다면, 팀원에게 어떻게 전달할까? USB로? Airdrop으로? 뭐... 여러 가지 방법이 있겠지만 그냥 git을 쓰면 된다. 그게 바로 Remote repository다.

 

https://github.com 사이트에 접속해서 로그인을 하면, 개인 repository를 만들 수 있다. 이게 바로 Remote repository다. 여기에 내가 Local repository에 저장했던 파일을 올리면 된다. 마치 구글 드라이브에 파일을 저장하는 것처럼! 그래서 Remote라는 이름을 달고 있다.

 

 내가 Remote repository에 파일을 올리면 타인에게 공유할 수 있다. 내 코드를 타인이 가져가거나(clone) 혹은 리뷰하는 등 다양한 상호작용이 가능하다.  혹은 남이 올려놓은 Remote repository에서 내 work space로 파일을 가져와 작업할 수도 있다. 이를 통해서 협업을 하는 게 바로 git의 두 번째 존재 이유다.

 

위와 같은 일들을 하기 위해서는 git 명령어들을 사용해야 한다. 그런데 git 명령어 또한 개발 기술답게 변경해오고 있다는 사실. 그래서 각각의 명령어들이 하는 역할과 존재 이유, 그리고 변천사에 대해 다음 글에서 톺아볼 예정이다. 그래야만 앞으로 바뀌게 될 명령어에 적응할 수 있을테니!

 

 이에 대해서는 재미난 에피소드가 있다. 나는 git checkout이라는 명령어가 아닌, 처음부터 switch와 reset을 통해 작업하는 방식을 배웠다. checkout이 직관적이지 않다는 이유로 git에서 switch와 reset으로 기능을 분리하고 더 직관적인, 유저 친화적인 명령어로 작성했다. 그런데 이에 대해서 팀원들에게 알려주니 깜짝 놀랐다. 반응은... "엥 진짜?". 다들 당연히 checkout만 쓰고 있었는데 갑자기 날벼락이 떨어진 셈. 그래서 내가 switch와 reset을 전파시켰다.

 

 아무튼 개발 세상에서는 쓰임새에 대한 히스토리를 아는 게 중요한 것같다. 그래서 장황하게 repository에 대해 설명한 것도 이러한 이유. 이제 다음 글에서 정확히 어떤 식으로 쓰이는지 확인해보자!