[Git] Git은 뭐하는 친구일까

git은 뭐하는 친구일까?

일단 git은 친구가 아니다

하지만 친근해져야만 하는 도구이다

 

개발의 길을 걸으면서 엔지니어가 되려하거나 프로젝트를 진행한다면

안 쓸 수가 없는 기능이다

 

 

그래서 깃은 무엇일까?

깃

---

GIT

무슨 수를 써서라도 익혀야 하는 이것은

형상 관리 도구(Configuration Management Tool) 중 하나로,

버전 관리 시스템이라고도 불린다

관련되어있는 용어는 다음과 같다

• Staging Area
  • = 대기 장소(출처: 구글 번역기)
  • 코드의 변경사항이 실적용되기 전에 거쳐야만 하는 장소이다
• Pull Request(PR이라고도 많이 부른다)
  • Staging Area에 있는 코드를 git에 동기화시키기 위한 작업(=업로드)
• Branch
  • = 나뭇가지(출처: 구글 번역기)
  • 개발 흐름에 따른 코드 변화 경로이며,
  • 서로다른 기능을 독립적으로, 동시에 만들 수 있게 하는 것이다
  • 종류는 아래와 같이 총 5가지 종류로 나뉜다 (main = 상시 유지, sub = 일정 기간 유지)
    • Master Branch(main) = 제품으로 출시될 수 있는 브랜치
    • Develop Branch(main) = 다음 출시 버전을 개발하는 브랜치
    • Feature Branch(sub) = 기능을 개발하는 브랜치
    • Release Branch(sub) = 이번 출시 버전을 준비하는 브랜치
    • Hotfix Branch(sub) = 출시 버전에서 발생한 버그를 수정하는 브랜치
• Merge
  • 갈라져 나온 브랜치들을 하나로 합쳐 다음 단계로 나아가는 과정
• Git rebase
  • 이미 갈라져 나온 다른 branch에 역순으로 패치를 걸어 변경사항을 적용시키는 것
• issue
  • 이슈

---

How to deal with Branch

프로젝트를 진행함에 있어 개발할 때 Repository를 분리해서 개발을 하는 방법과

브랜치를 분리해서 개발을 하는 방법이 있다

 

그렇다면 이 중요한 기능을 가진 브랜치를 어떻게 관리하는 것이 좋을까

많이 쓰이는 방법으로는 다음과 같다

위에 적힌 5가지의 브랜치 종류에 근간해 기능에 따라 분리해서 작성하기
Git Commit Message Convention을 이용하여 변경 내용을 알아보기 쉽도록 하기
-> 이 때 메세지는 서술적이어야 한다(이에 대한 내용은 다음 블록에서 다루도록 하겠다)
-> ex) feat: 로그인 기능 구현 완료

---

Git Commit Message Convention

간단히 말해 코드를 작성하고 이에 대한 메모를 작성하는 것에 대한 약속(규칙)이라고 보면 된다

프로젝트를 진행하는 팀마다 모두 다를 수도 있지만 크게 보면 다음과 같은 규칙을 보편적으로 다루고 있다

• Commit Type
  • feat: 새로운 기능 추가
  • fix: 버그 추가
  • docs: 문서 수정
  • style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
  • refactor: 테스트 코드, 리펙토링 테스트 코드 추가
  • chore: 빌드 업무 수정, 패키지 매니저 수정
  • design: CSS 등 사용자 UI 디자인 변경
  • comment: 필요한 주석 추가 및 변경
  • rename: 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우
  • remove: 파일을 삭제하는 작업만 수행한 경우
  • !breaking change: 커다란 API 변경의 경우
  • !hotfix: 급하게 치명적인 버그를 고쳐야 하는 경우
• Commit Message Structure
  • 커밋 메세지의 구조를 나눠두는 규칙이다
• Subject
  • 제목은 50자를 넘기지 않고, 대문자로 작성하며, 마침표를 붙이지 않는다
  • 과거형 미사용, 명령어로 작성한다

이 외에도 여러 요소에 대한 규칙을 정해서 사용하기도 한다

---

Git Organization

프로젝트의 경험이 쌓이고, 본격적으로 팀 프로젝트를 진행하면

git에서 organization을 생성하기도 한다

 

Organization은 팀 단위 프로젝트를 공동으로 관리하기 위한 "공동 계정"이다

이를 이용하면 사용자, 저장소를 공동으로 관리하게 되고

동시에 팀원들의 하는 일들을 실시간으로 알 수 있기에 그야말로 협업에 도움이 되는 필수적인 도구라고 볼 수 있는 것이다

---

Merge 전 Code Review는 필수?

팀원들과의 규칙을 정하다 보면 'merge 할 때에는 Review를 필수적으로 하나 이상 받아야 한다'

라는 규칙을 정해 본 기억이 있을 것이다

그렇다면 왜 Merge할 때 리뷰를 남겨야 하는 걸까?

 

이에 대한 답은 공장의 기계 관리에 빗대어 설명해보겠다

 

1. 공장에 제품을 생산하는 기계를 납품하는 업체가 있다

2. 이 업체에서 일단 만들고 검수 없이 공장에 납품했다

3. 납품했던 기계에서 큰 결함이 발생하여 굉장히 거슬리는 상황이 발생하였고 공장의 생산라인에 혼돈이 찾아왔다

 

이제 이 상황을 코드 리뷰에 빗대어 보면 이렇게 된다고 말 할 수 있다

1. 개발자를 꿈꾸는 열정이 가득한 개발자 지망생이 있다

2. 이 개발자는 브랜치를 만들어 일단 코드를 써서 기능을 개발하고 시간이 아까워 리뷰없이 merge했다

3. merge 이후 코드를 받아 다른 작업을 진행하던 다른 팀원들에게 동시다발적으로 예기치 못한 버그가 생겼고, 팀에는 혼돈이 찾아왔다

 

코드를 작성하고 나면 작업단위로 Pull Request를 올리게 되는데 기존의 브랜치 상태랑 비교하면서 다른 개발자 분들이 비교하면서 코드 리뷰를 남길 수 있는 상태가 된다

그런 상태에서 리뷰를 받아 코드의 상태 등을 점검받으면 훨씬 더 안전하게 개발을 진행할 수 있게 되는 것이다

 

이렇기에 review 받는 상황이 익숙하지 않더라도, 혹은 리뷰를 달기가 어렵더라도 익숙해지기 위한 노력이 필요하다

 

Q. 그렇다면 리뷰 할 때에는 어떤 내용을 남겨야 하는가?

A. 참고 https://techblog.woowahan.com/2712/

코드리뷰가 쏘아올린 작은공 | 우아한형제들 기술블로그

• 가벼운 마음가짐
• 오타 지적 OK
• 이 코드의 의도는 무엇입니까?
• 이 부분을 잘 모르겠어요
• 변수명 어떤 기준으로 생성하셨나요?
• 머지 템플릿에 대해 학습한 이후 적용해보는 것도 괜찮다(위 링크 참고)

---

코드리뷰 할 때 이건 하지 말아주세요

 

스스로 PR하고 스스로 Merge
=
스스로 스르르 스르지는 지름길

 

이는 검증되지 않은 사람에게 복어 손질을 받아서 먹겠다는 것과 같다

 

코드리뷰는 초반에는 익숙해지기가 굉장히 어려운 편이기에

팀원분들과 많은 연습 혹은 실전을 진행하면서 성급하지 않는 것이 중요하다

 

인내심을 가지고 익숙해지기까지 반복하는 것을 추천한다

---

End

 

 

 

Git 명령어가 궁금하다면??
⬇️

[Git] 명령어 정리

 

 

참고자료

https://goddaehee.tistory.com/91

[웹개발 기초] Git 이란?

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

Git - Rebase 하기

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

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

https://doublesprogramming.tistory.com/256

Git - 커밋 메시지 컨벤션

https://git-scm.com/book/ko/v2/GitHub-Organization-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0

Git - Organization 관리하기

https://techblog.woowahan.com/2712/

코드리뷰가 쏘아올린 작은공 | 우아한형제들 기술블로그