[우당탕탕] 협업툴의 기본 Git 도입기1

안녕하세요. 알에스팀 개발2팀 팀장 허윤입니다.

회사내에서 최초로 Git을 적용해보면서 경험했던 어려움과 해결해나가는 과정을 공유해보고자 합니다.

 

Git이란?

코딩을 하면서 버전관리(일종의 백업)을 하면서, 협업을 용이하게 도와주는 프로그램(?)입니다.

동시에 여러명이서 작업하는 경우, 실수로인해 파일이 삭제, 이동되거나 변경될 경우 복구하기 굉장히 편리합니다.

 

단순한 프로그램이지만 익숙해지기 까지 많은 트러블과 어려움이 존재했습니다..

 

계기

당시 우리회사는 PHP 업무를 담당하고 있었습니다.

AWS Lightsail 에서 서버를 생성하여 VSCODE 의 Remote-SSH를 연결하여 함께 작업하는 형식이죠.

Remote -SSH

공동 작업자가 한 워크스페이스에서 작업을 하다 보니, 누군가 열심히 작업해놓은 내용을 다른 공동작업자분께서 실수로 지우는 경우도 있고, 수정하였는데 더 꼬여버리는 경우 등 많은 에피소드가 왕왕 있었습니다.

하지만 우리가 할 수 있는 백업은 주기적으로 압축을 하거나, Lightsail 의 스냅샷이었는데, 이는 부분적으로 복원하는데 효율적인 방법이 아니었고, Git을 통한 백업이 가장 필요하였습니다.

 

PHP에서의 Git

생각보다 계획대로 착착 진행이 되었습니다.

Lightsail 서버에는 기본적으로 Git이 설치되어있었고, 회사 전용 Git 계정 또한 존재하였습니다.

그래서 Repository 를 생성하여 하라는 대로 add Remote 를 진행하고 git add, git commit, git push 를 진행하니 너무 잘 작동하였습니다.

그리고 Crontab 을 활용하여 주기적(매일 0시)으로 Autopush shell script 를 만들어 적용시켰습니다.

이렇게 적용을 시켰더니 백업도 주기적으로 항상 진행이 되고, 오류발생시 해당 파일만 확인하여 복원이 가능해졌습니다.

 

추가로 Git을 활용하면서 추가로 개발에 용이한점이 생겼습니다.

바로 개발서버와 운영서버 분리가 굉장히 쉬워졌습니다.

기존에는 개발서버에서 모든작업을 하고 완료되면 운영서버에 업로드를 하거나, 운영서버에서 작업을 하곤 했었습니다 ^^;;

하지만 Git을 도입하고 모든것이 바뀌었습니다.

개발서버에서 작업하여 목표한 부분이 완료가 되면 Push 를 하고

운영서버에서는 단순히 Pull을 하기만 하면 곧바로 적용이 되는것이었습니다.

출처 웃대

 

하지만 이렇게 사용 하였을 경우 몇가지 아쉬운점 또한 존재했습니다.

1. 한개의 서버에서 동시에 여러명이 작업하기 때문에 branch 를 서로 분리할 수 없었습니다.

2. 한개의 서버가 commit push를 하기때문에 작업자가 누군지 구분할 수 없었습니다.

 

Git을 말 그대로 백업의 용도로 사용을 하였지, 협업으로서 훌륭한 기능을 사용할 수 없었습니다.

Git 자체를 온전하게 사용하기 위해서는 로컬에서의 작업이 필수적이라는것을 깨달았습니다.

 

Nodejs에서의 Git

PHP 프로젝트가 마무리 되고 뒤이어 작업을 한 프로젝트는 Nodejs 를 활용한 프로그램이었습니다.

PHP 처럼 한개의 서버에 여러사람이 동시에 접속하여 작업하는것이 아닌 로컬에서 각자 작업을 하고 한 Repository에 작업물을 모아야했죠.

 

Nodejs는 호락호락하지 않았습니다.

일단 기본적으로 Git 작동원리를 완벽하게 이해하지 못했었던데다가

Git 작동 원리 출처 secmem.org

가장 심각한 문제는   Conflict  에 대한 경험이 없었습니다.

 

매일 Push, Pull 할 때 마다 Conflict가 발생했습니다.

개발자들이 흔히(?) 보는 Conflit...

근본적으로 이 문제가 발생하는 이유는 한개의 파일을 여러명이서 함께 수정하는것이었습니다.

 

이 문제를 해결하기위해 대부분의 공통파일을 분리하였고, import 하여 사용하는 방식으로 변경하였습니다.

그리고 담당, 작업하는 부분을 명확하게 분리하여 코딩을 함으로서 Conflict를 최소화시켰습니다.

 

그리고 이렇게 작업하는것이 습관화가 되면서 Conflict 에 대한 문제가 줄어들었습니다.

 

안정적 그리고 도전

Git에서 발생하는 문제들의 원인들을 대부분 분석까지 하였고 추가적으로 발생하는 문제들은 없었습니다.

하지만 여기에서 멈추지 않고 새로운 도전을 진행했습니다.

 

개발자 Branch 사용 문화 만들기

Branch를 사용하면 이점이 굉장히 많습니다. 새로운 아이디어가 나면 새로운 Branch 를 생성하여 제작해보고 원하는대로 작업이 된다면 기존 작업하던 Branch 에 Merge 하고, 생각처럼 작동이 되지 않으면 Delete 함으로서 기존 코드를 보존하면서 여러 시도를 해볼 수 있습니다.

 

하지만 이론상으로만 알고있었기 때문에 다른 기업에서의 Branch 문화를 카피해보기로 했습니다.

 - 참고 게시글( https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html )

 

위 게시글을 참고해서 우리회사에서도 Branch를 사용해보기로 했습니다.

 

Branch를 5개의 개념으로 분리했습니다.

1. Master - 배포 및 제품으로 출시할 브랜치
2. Release - 출시버전을 준비하는 브랜치
3. Hotfix - 출시버전에서 발생한 버그를 수정하는 브랜치
4. Develop - 개발에 중심이 되는 브랜치
5. Feature - 각각 기능을 개발하는 브랜치

이렇게 분리하였고 실질적인 개발은 feature 브랜치에서 작업을 하게 되었습니다.

사진을 인용하면

출처 : https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

위와같은 워크 플로우로 작업하였습니다.

 

Branch를 분리하여 작업을 하게 되니 오류가 발생해도 되돌리기 쉽고, 버전관리 또한 용이해졌습니다.

 

Git 문화가 이렇게 정착이 되고나니 서로간의 협업시에도 굉장히 안정적이고 효율적이 되었으며 오류 확인 및 복구도 빠르게 가능해졌습니다.