Git으로 협업하기

실무를 하다보면 feature, develop branch, rebase 등등 관련된 단어들은 알지만 실무에선 딱히 쓰여지고 있진 않은 경우가 있다. 

나만 해도 거의 혼자서 back단의 작업을 하기때문에 내 이름으로 브랜치 하나 만들어 놓고 테스트 마스터에 올리고 실서벙 반영하는 형식으로 사용하고있다.

 사실 큰 이슈가 없다면 이렇게 써도 되지만 과거로 돌아가야되는 순간엔 개망하는거다. 별다른게 이슈가 아니다. 이게 빅이슈다.. 

 한번쯤은 이 개념들이 정리가 되고 정석의 git전략을 써보고싶었는데 마침 DND의 운영진님께서 관련된 온라인 세미나를 열어주셨다.

 * 여러분 dnd하세욤

 

 - git 이전에는 어떻게 버전관리를 했을까? 

 git이전에는 CVS(Centralized Version Control)가 존재하였다. 중앙에서 모든것이 통제되었던 것으로 서버가 죽을때마다 모든 로컬들또한 죽어버렸다고 한다. 현재 널리 사용되고있는 github, gitlab은 로컬 컴퓨터마다 서버를 분배시킨 개념으로 로컬컴퓨터가 서버처럼 동작을 한다. 즉 git서버가 죽더라도 로컬에서의 커밋 작업은 가능하다는 것이다.

 

 - git은 어떻게 동작 될까? 

 스냅샷 기법을 사용한다. 각각의 스냅샷을 저장하여 그 시점으로 돌아갈 수 있다.

이때 코드 전체를 찍게 되면 용량의 문제가 발생할 수 있는데 git은 최초 1번에 대해서만 저장하고 그 파일을 기준으로 어떤 부분이 변경되었는지만 저장하게된다. 용량 최소화를 시킨 다는 의미이다.

 

 

 

- git branch 사용 전략

 

 

 

master였는데 요즘은 main으로 용어가 바뀌었다고한다.

 - main : 실제 배포가 가능한 상태만을 관리하는 브랜치

 - hotfix : main에서 급히 수정해야되는 브랜치, 만약 이 브랜치를 땃으면 release/develop/main에 함께 반영

 - release : 모든 관계자들이 확인하여 마지막 확인 QA를 거치는 브랜치

 - develop : 실질적인 개발 브랜치

 - feature :  개발브랜치에서 세부적인 기능으로 나눈 브랜치로 수십, 수백개가 존재하고 닫힐수 있다. 

 

* 굵은게 메인브랜치, 그 외에는 보조브랜치들!

 

머릿속에만 둥둥 떠다니던 것들이 한번에 정리되는 느낌이다 좋다!

 

 - merge & rebase 

rebase는 전혀 사용해보지 않은 작업이라 설명을 할때에도 흠? 하고 들었는데 아래의 블로그 글을 보니 조금은 이해가 간다.

 간단히 말 하자면 기능은 같으나 깃의 흐름을 좀 더 정렬해주는 느낌이라고 생각 하면 되려나..?

https://brunch.co.kr/@anonymdevoo/7

4. Merge 와 Rebase의 차이점

 

 

 - 지속적 통합/배포(CI,CD)

CI/CD는 한번도 경험해 본 적이 없었는데 한번쯤은 경험해보고싶군

CICD는 master에 올리기만 하면 바로 적용 되는 것을 의미하는데 이것을 하려면 git branch전략이 중요할 것같다.

* github runner를 통해 web page 쉽게 구축해 나갈 수 있음.

 

 - commit prefix약속

feat : 새로운 기능 추가

fix : 버그 수정

improvement : 호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등 향상

docs : 문서 수정

style : 코드 포맷팅, 세미콜론 누락 등

refactor : 기존 코드에 대한 리팩토링 진행

 

커밋 메시지에 대한 약속을 정해놓는 것인데 나는 혼자서 작업 잘 하니까... 그냥 생각나는대로 커밋메세지를 적는데 협업에는 이런 규칙이 필수인 것 같다.

 

git나름 잘 알고있다고 생각해서 세미나를 들을까 말까 고민했었는데 듣길 잘 했다.

안들었으면 진짜 후회할뻔 했다.. 나는 아직도 갈길이 멀구나.. 이번 주말도 열심히 했는데 왜 맨날 계속 일이 많아지냐 난..

오늘도 내일도 다음주도 열심히 해야지..