개발자의 영원한 친구 Git!! 나는 Git에 대해 얼마나 알고 있을까? 이번에 사오정 앱개발을 하며 Git에 대해서 조금 더 알게 되었다. 그것을 명확하게 기록해놓고자 한다. 어차피 다음에 또 까먹어서 찾으러 오니깐..

사오정 앱개발 이전

나는 Git을 그냥 코드 저장소로 활용했다. 조금 더 잘 활용하면 README를 잘 작성해서 프로젝트를 소개하거나 커밋 메세지를 보고 코드를 살펴보지 않고 어떤 작업이 변경되었는지 아는 정도로만 활용했다. 그것만 활용해도 너무나 편했다. 당연히 문제점도 있었다. 어떤 문제점이 있었는지 살펴보자

• 노트북, 데스크탑 등 여러 환경을 넘나들며 작업을 하다보니 충돌이 일어났다.
• Git을 사용하면 협업이 편하다는데 나는 오히려 잦은 충돌로 인해 협업이 너무 불편했다.

Repository를 혼자 편집하는데 충돌이 난다고?

놀랍지만 정말로 그랬다. 그 이유는 이랬다. 노트북과 데스크탑 모두 1.0 버전의 코드를 가지고 있었다. 이제 노트북에서 1.1 버전을 PUSH 했는데 데스크탑에서 1.1 버전을 PULL하지 않고 1.0 버전에서 1.2 버전을 만들고 PUSH를 시도했다. 이런 형태의 충돌이 자주 있었다. 그런데 원인을 알려고 노력하지 않고 그냥 git push -f origin master 로 불도저처럼 밀어버렸다. 왜냐하면 충돌이 발생하는 이유조차 몰랐기 때문이다. 반성한다.

Git으로 협업이 불편하다고?

놀랍지만 정말로 그랬다. issue, pull request, merge, branch 기능을 거의 쓸 줄 몰랐다. 그러니 master branch안에서 여러명이 작업을 했고 issue를 사용할 줄 모르니 commit 횟수가 많아지고 충돌이 발생하기가 너무 쉬웠다. 반성한다. 이제 제대로 한번 알아보자

사오정 앱개발 이후

다음과 같은 변화가 일어났다!

• branch로 작업하기
• 충돌이 발생하는 이유를 알고 충돌을 예방하기

branch로 작업하기

branch로 작업하는 것은 아주 편리하다. 많은 기업들에서는 git work flow라는 이름으로 여러가지 branch를 나누는 패턴이 있다. 나도 어떤 문서를 참고해서 branch를 활용하기 시작했는데 사오정 서버 프로젝트에서는 master, develop, feature/# branch를 활용한다.

• master: 실제 서비스할 수 있는 코드의 버전을 유지한다.
• develop: 개발 단계의 코드의 버전을 유지한다.
• feature/#: issue 등록으로 발행된 issue number 혹은 기능을 구현하는 코드를 유지한다. 구현이 완료되면 삭제하는게 일반적이다.

branch를 활용하여 작업을 하니 아주 편리하더라. 아직 issue number를 타겟으로 branch를 생성한 적은 없는데 앞으로 그렇게 해야겠다. 이것의 장점은 issue에 작성된 내용을 보고 각 branch가 어떤 작업을 하고 있는지 알 수 있는 것이 큰 장점인 것 같다.

충돌이 발생하는 이유를 알고 충돌을 예방하기

충돌이 왜 일어날까? push, merge, pull request 등과 같이 코드의 상태를 변경하는 작업을 수행할 때 변경 당할 코드를 fork, pull, clone 등의 작업으로 복사해온 시점의 코드와 상태를 변경하는 작업을 수행할 때의 시점의 코드가 다를 때 충돌이 발생한다. 충돌을 예방하기 위해서는 많은 방법이 존재하지만 가장 확실한 방법은 협업하는 사람들끼리 충분히 소통하는 방법이겠다.

더 나아가서

Git의 기능은 엄청나게 방대하다. 아직도 이해해야 할 부분이 너무나 많고 궁금한 점도 많다. Soruce Tree도 써보고 싶고.. 하지만 공부 욕구를 접어두고 나중에 필요한 시점이 왔을 때 다시 공부할 것이다. 이 공부 패턴이 너무 효율적이라고 생각하기 때문이다.