이런, 에러다.

오픈소스를 참고하며 열심히 앱을 만들었다. 어느 순간부터 크래쉬가 나고, 빨간 글씨들이 나를 반긴다. 아.. 어느 순간부터 에러가 났는지 모르겠다. 나는 부분부분 주석처리를 해가며 에러를 찾는다. 이렇게 막무가내식으로 에러 지점을 찾는 것도 한 두번이여야지. 좋은 방법이 없을까? 필자와 같은 공감을 한 독자들이라면

우린 아마도, Git을 배울 시점이다.

도대체 Git이 뭔데

대학교 과제를 해 본 사람, 아니면 어떠한 문서나 ppt를 작성해본 사람들이라면 이미 git 시스템을 알고 있다.

버전1 - 과제_5England.ppt
버전2 - 과제_5England_최종.ppt
버전3 - 과제_5England_최종최종.ppt
.
.
버전n - 과제_5England_최종최종최종최종최종진짜최종.ppt

ppt 작업의 변경 사항들을 그냥 저장해버리고, 나중에 ppt 내용에서 큰 문제를 발견하면 어떻게 될까? 이전으로 돌아갈 방법이 없다. 지금껏 수정했던 내용들을 일일이 지워가며 ppt를 대대적으로 손 봐야할 것이다. 어라, 코딩할 때 내 모습 같은데

아무튼 이러한 이유로, 우리는 다른 이름으로 저장을 통해 문서를 여러 개 만들어본 경험이 있을 것이다. 새로운 변경 사항에 대해 다른 파일로 백업시켜 놓고, 나중에 문제를 발견하면 문제 이전의 파일 상태로 손 쉽게 돌아가자는 것이다.

개발 측면에서 관련 기능을 제공해주는 것이 git이다.
좀 더 자세히 알아보자.

• Version Control System
  • git은, 버전 관리 시스템이다.
• Version Management not by changing the file name
  • 위의 과제ppt 저장 내역이 지저분하지 않은가? 버전이 여러 개 생성된 건 맞지만, 결국은 똑같은 프로젝트 아닌가.
  • git은 여러 개의 버전을 동일한 파일 이름으로 사용할 수 있도록 도와준다. 우리가 과제를 할 때 git을 사용했더라면 바탕화면이 깔끔!했을 것이다.
• +Backup, +Recovery, +Collaboration
  • 단순 버전 관리 이외에도, 다양한 기능을 개발자에게 제공한다. 굉장하다!
• 사실 Git은 제품 이름이다.
  • 이 Version Management System에는 Git을 포함해 여러 가지 제품이 존재한다. 이 중 가장 대표적으로 사용되고 있는 제품의 이름이 Git이다.
• 처음 사용하면 어렵다.

버전 관리를 해야하는 이유

지금껏 우리가 해오던 개인 프로젝트 단위가 아니라, 5개월짜리 실무 프로젝트를 우리가 진행하고 있다고 상상해보자. 2개월 차까지는 그럭저럭 에러 없이 잘 돌아갔다. 평온한 마음으로 일을 진행해왔다. 하지만 지금껏 쌓여오던 코드들이 보이지 않던 문제를 축적하여 말썽을 일으켰다. 이 때 당신은, 당신의 팀은 어떻게 할 것인가?

우리의 팀은 문제를 맞이할 대비를 틈틈이 해둬야 한다. 체계적인 버전 관리라는 말도 있지 아니한가. 단순 버전 관리 뿐인가! 다음 글에서 설명하겠지만 Git과 연동되는 저장소 사이트 Github도 있다. code review, pull request, Actions(+자동화), issue, wiki,,,, 당신이 다른 개발자들과 협업하여 크고 멋진 프로젝트를 완주할 수 있도록해주는 수많은 기능들을 Git과 Github는 제공한다. 그러려면 git의 기본을 알아야 한다.

터미널에서 git을 쳐보세요.

Git을 설치한 적이 없다면 Git Download URL

위와 같이 터미널에서 git ~~ 와 같은 방식으로 git을 활용할 수 있는데, 우리가 사용하는 유명한 frameWork(android studio)나 ide(VScode)에서는 git을 더욱 손 쉽게 사용할 수 있게 만들어놓았다. 그래서 필자는 독자들이, 주로 사용되는 기능들에 대해 최소한의 이해와 사용을 시도해보고, git에 관심을 가지게 되면 좋겠다.

VScode에서의 git

실습 환경은 VScode, C언어로 진행하겠다.

• git

  • 먼저 프로그램을 하나 작성한다.
  • 우리가 사용하는 프레임워크나 ide에서 git에 대한 메뉴를 찾는다.

  

  • VScode 기준, 왼쪽 중간에 git 모양이 보인다. 눌러보자.

  

  
  

• init

  • initialize Repository, 무슨 뜻일까
    
  • 현재 디렉토리에 대해 git 버전 관리를 시작하겠다! 라는 뜻이다.
  • 버전 관리를 하려면 각 버전에 대한 파일들을 저장할 저장소가 필요하다.
  • git에서 이 저장소를 번역 그대로 repository라고 부른다.
  • 해당 파일의 버전 정보를 저장할 repsitory(저장소)에 대한 초기화를 수행하는 것이다. 눌러보자.

  

  • 초기화가 수행되었다.
  • 해당 파일의 버전 관리 정보를 저장할 저장소가 생성되었다.
  • Changes(변경 사항)에 우리가 작업한 내역들이 올라와있는 것이 보인다.
  • 코드 변경사항에 대해 각 버전으로 저장하는 것이 git이라고 했지 않은가?
  • 이제 저장을 해보자

  
  
  

• add
  

  • save도 아니고 다음 단계로 add가 튀어나왔다.
  • 어떤 파일은 git 버전 관리를 하고 싶고, 어떤 파일은 git 버전 관리를 굳이 할 필요가 없다는 것을 우리, 즉 개발자는 알고 있다. git은 모른다.
  • 버전 관리할 파일과 하지 말아야 할 파일을 구분해서 git에게 알려주는 단계다!
    
  • 나는 hello.cpp 파일만 버전 관리를 진행하고 싶다.
  • hello.cpp 파일에 커서를 대보면 생기는 + 기호를 눌러보자.
    
  • hello.cpp 파일이 Staged Changes 위로 올라갔다.
  • 저장 대상이 된 파일은 stage area(commit 대기 목록)에 올라가 있는다.
  • hello.cpp 파일을 커밋할 준비가 되었다. 다음 단계는 무엇인가?

  
  
  

• commit

  • 1일1커밋, 들어본 적 있지 않은가?
  • 개발자들이 매일마다 어떤 작업의 코드 변경사항을 자신의 저장소에 추가함으로써, 하루하루 성장해나가는 행위가 daily commit이다.
  • commit의 정의를 살펴보자.

  

  • 저장소에 변경 사항을 기록하는 것
  • 우리는 commit할 파일들에 대해 stage로 올려놓았다. (hello.cpp)
  • 자, commit을 눌러보자

  

  • 경고창이 뜬다.

  

  • 우리는 버전 관리를 할 파일을 구분하여 stage에 따로 올려놓았으니, Commit Staged Changes를 클릭하면 되겠다.

  

  • 메세지를 입력하라고 뜬다.
  • 작성하는 이 메세지가 commit message이다.
  • 여기에 보통 해당 코드 변경 사항이 어떤 작업을 의미하는지 적어주면 된다.
  • "print "Hello World"라는 메세지를 입력하고 엔터를 눌러주자.

  

  • Staged Changes 목록에서 사라졌다.
  • 정상적으로 commit이 된 것이다.
  • hello.cpp에 코드 변경 후 컴파일을 해보자.

  

  • 다시 Changes(변경 사항)에 hello.cpp가 올라온 것을 볼 수 있다.
  • git은 코드의 변경 사항을 관찰하고 있다.

init : 해당 폴더에 대한 repository를 초기화하고
add : commit할 파일을 구분 및 선택하여
commit : 해당 작업에 대한 commit message를 작성하여 훌륭하게 commit했다.

당장이라도 push라는 것을 통해, github에 내 커밋 기록을 공유하고 싶지만 이는 다음 글에서 다뤄보자. 더 중요한 것이 남아있다.

• Version
  • 버전, 필자는 처음에 게임 1.16.2 버전, 이런 애플리케이션 업데이터의 버전을 의미하는 줄 알았다.
  • 물론 그것도 버전이지만, git에서 의미하는 버전이란 하나의 커밋을 의미한다.
  • 그리고 하나의 커밋은 하나의 작업만 포함시키는 것이 좋다.
  • 정리하자면
  • ((1 Version = 1 Commit) == 1 Task)이다.
• 왜 하나의 버전, 즉 하나의 커밋은 하나의 작업만 포함하는 것이 좋을까?
  • 왜 지금 우리가 각기 같은 파일을 다른 버전들로 여러 번 저장하고 있는지, 상기해볼 시간이다.
  • 각기 다른 버전을 만듦으로써
    • 버전 별 차이점을 쉽게 알 수 있다.
    • 커밋 메세지를 통해, 각 작업이 어떤 작업을 수행한 것인지 쉽게 파악 가능하다.
    • 각 버전에 대한 정보를 참고해 과거로 돌아갈 수 있다.(언제 버그가 발생할지 모르기 때문)
  • 결국은 장기적 관점으로 유지보수성을 높이겠다는 것인데

  <<Best Case>>

  하나의 작업을 할 때마다 커밋을 해주고,

  이후 어떤 문제가 발생하면

  해당 문제가 발생된 것으로 예상되는 커밋 지점으로 돌아가서 문제를 찾고, 해결하겠다는 것이다.

  <<Worst Case>>

  근데 어떠한 기준 없이 수시로, 시시때때 커밋을 하거나, commit message가 단일 작업을 표현하고 있는 것이 아니라 여러 작업들이 마구 적혀있다면 어떨까?

  나중에 수많은 commit 내역 중에서 우리가 되돌아가야 할 지점을 찾기 매우 어려워질 수 있다.

  어떠한 기준도 없이 commit을 남발할 것이라면, git을 차라리 안 쓰는게 나을지도 모른다.

  • 물론 현업 및 실무에서의 commit하는 시점은 필자도 잘 모른다.
  • 현재로써는 하나의 작업에 대해 깔끔하게 commit하며 유지보수성을 높이는 것에만 집중해도 당신의 프로젝트에 있어 혁신적인 변화가 생길 것이다.

Head, Branch

필자가 공부한 내용이다. 안 읽고 스킵해도 된다.

• HEAD

  • 저장소를 만들면 HEAD가 생기는데, HEAD가 master를 가르킨다.
  • 또 master는 최근 commit의 commit id를 가르킨다.
    • commit은 이전 commit의 주소를 저장하고 있는다.
    • HEAD -> master -> commits
    • 개발자에겐 HEAD가 가르키고 있는 부분이 보인다.

      • HEAD : 버전 포인터
      • master : 마지막 버전 주소
      • commit id : 각 commit의 40자리 주소

• Branch

  • 어떤 개발자는 버그를 수정하고, 어떤 개발자는 기능을 추가하고.. 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없다.
  • 분리된 작업 영역에서 변경된 내용을 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있게 해준다.
  • 이와 관련된 것이 branch이다.
  • 추후에 다시 공부해야 한다.
  • 참고 링크

Github

다음 글에선 우리가 생성한 repository와 프로젝트의 commit들을 git 원격저장소인 github에 공유하고, github가 제공하는 대표적인 기능들에 대해 알아보자.

Github - 협업의 시작

p.s : 선택적 수용을 지향합니다. 오류가 있을 수 있습니다.