개발자 관련 구인공고를 보면 상당수의 글의 우대조건에 git유경험 또는 숙련자가 적혀있는걸 볼 수 있었다.
아니 개발자의 역량이 CS지식이나 라이브러리 숙달, 프로젝트 퀄리티만 보면 답이 나오는거지 왜 코딩과 무관한 git이 자꾸 적혀있는지
처음엔 이해가 되지 않았다. 그래서 git관련 경험이 github에 프로젝트를 올려 본걸 뜻하는건가 싶어 그려러니 했다.
실무에 와서 느꼈다. 개발은 혼자 하는게 아닌것을. 당연한 얘기긴 했지만 개발자 혼자 개발하는거면 git의 중요도는 지금보다 훨씬 못미쳤을 거다.
기업의 주요 비즈니스 사업을 전문가 한명이 몰빵해서 맡는거는 구인하는 과정, 시간적, 퀄리티 면에서 상당히 비효율적이기에 여러 레벨의 개발자들을 모아 진행하는 방향이 옳다.
그럼 여러 개발자들이 하나의 프로젝트를 완성하려면 어떤식으로 해야할까?
대학교 재학 시절 동기들이랑 프로젝트를 진행했던 기억을 떠올려봤다. 사실 그때는 실력도 또이또이였지만 코딩수준도 꼬꼬마 레벨이라 누가 저 기능 맡고 누가 이 기능 맡고가 아닌, 여러명이서 하나의 기능을 머리 싸매며 개발했던 기억이 났다. 그렇게 개발하다가 한 명이 기능을 완성하면 완성된 기능의 코드를 복사하여 카톡으로 넘기고, 받은 사람이 다시 그 코드를 자기 프로젝트에 붙여넣기 했었다.
근데 이건 다른 클래스에 의존성이 없거나 적은양의 코드만이 가능했고 이 보다 복잡하거나 한참뒤에 건내준 코드는 카톡으로 하기 벅찼다. 그래서 프로젝트를 압축하여 .zip파일로 만들고 이 파일을 카톡으로 보내 압축해제시켜 그 프로젝트에서 시작했었다.
지금 글 쓰면서도 어떻게 했나 싶을정도로 답답해죽겠다...😫
Git은 이러한 귀찮은 문제를 해결해준다!
아까의 상황에서 git을 대입하게 된다면 동기들끼리 코드를 복사해서 만든 메인 프로젝트가 있다. 이 메인 프로젝트를 복사해서 각각의 인원들이 개발중인 서브 프로젝트들이 있다. 이때, 누군가가 한 기능을 완성했으면 카톡으로 코드나 압축파일을 보내는 것이 아닌 한 줄의 명령어(git push)로 메인 프로젝트에 추가시킬 수 있는 매우 편리한 기능을 제공한다.
강점은 이제 시작
Git전엔 VCS
여러 개발자들이 몇개월에 걸쳐 드디어 앱을 릴리즈했다. 이제는 유지보수를 하며 버전을 업그레이드 하는 절차가 남아있다. v1.0에서 여러 VoC들을 종합하여 개선된 기능을 V1.1에 추가하는 도중, 코드가 매우 엉키고 버그가 많아 다시 v1.0으로 돌아가야하는 상황이 닥쳤을 때, 누군가가 v1.0버전을 저장해놓지 않았다면 매우 곤란한 상황이 될 것이다.
git이전 협업을 위해 개발자들이 주로 쓰던 툴은 VCS였다. VCS는 버전별로 서버에 백업을 시켜놓는 방식이다. 하지만 이는 서버에 의존적이다. 서버에 장애가 발생하면 잠정적으로 백업을 하지 못하고, 서버가 터져 날아가버리는 최악에 상황에는 답이 없어져버린다.
git은 이러한 문제를 해결할 수 있게 서버뿐 아니라 개발자들의 컴퓨터(로컬)에도 저장할 수 있는(commit)기능을 제공한다. 이로써 서버에 불안해할 필요도 없고 백업도 여러군데 해놓은 상황이라 매우 안전하다고 할 수 있다. 또한 로컬작업은 네트워크가 불가한 상황에서도 commit은 가능하고, 각각의 commit에 고유의 Description을 기록하여 내용을 보고 원하는 commit으로 코드를 롤백할 수도 있다.
이는 버전 단위보다 더 작게 분류할 수 있다는 장점이 생긴다.
검증된 Git flow
git에는 commit외에 branch라는 것도 존재한다. 많은 기업들이 협업을 위한 플로우로 git flow를 사용한다.
나는 아직 소규모라 위 사진과 같은 복잡한 플로우로 개발을 해보진 못했다. 더 간단하게 진행하는데 몇자 적어보자면,
Local에서 작업을 완료한 한 후(commit), 작업을 Remote Repository에(GitHub) 저장(push, branch)한다. 그리고 Remote Repository에 push한 브랜치를 Main Repository로 통합하기 위해(merge) PR(Pull Request)를 사수에게 요청하고 코드리뷰를 거친 후 merge 하는 방식이다. 이후 merge가 됐다면 최신화된 Main 코드를 추후 충돌이 나지 않게 Local로 당겨온다(pull).
이 중 Pull Request를 하는 부분을 GitHub에서 보면, 전 commit고 비교하여 달라진 부분들 파일별로 딱딱 보여줬는데 이게 진짜 신기했다.
코드리뷰가 원활히 가능하게 했던 부분이 다 이런 신기한 기능들 덕분인듯 하다.
이렇게 장점만 있을 것 같은 git에도 확!실!한! 단점이 있다. 바로 진입장벽,,
구글링이나 유튜브 또는 커뮤니티에 가봐도 알 수 없는 에러로 고생하는 사람들이 눈에 훤히 보인다. 물론 나 포함.
git특성상 개인적으로 경험할 수 있는 범위보다 협업을 통하여 얻는 경험의 범위차이가 상당하게 난다고 생각한다. 그래서 1달동안 혼자 익히는 것보다 1주일 실무에 가서 느끼는게 10억배 낫다고 생각이 들었고, 맞았다..
git관련 강좌까지 있는것을 보면 말 다한듯? 평소 개발하면서 봐왔던 에러로그와는 다른 메세지에, 경험하지 못한 아키텍쳐라 어쩔 수 없지 모,,
뭐 다들 사용한다는데 해야지,,
그런김에 여기는 git명령어나 에러 대처법을 적어보려 한다!
끗!
윤강희!