Git

Git

• 마지막으로 수정한 사람이 누구에요..ㅜㅠ 코드 사라졌어요 ㅜㅜ

팀워크에 문제가 생기고 프로젝트가 문제가 생길 수 있다!

이러한 문제를 해결하기 위해 Git 이 필요하다..!

Git은 리눅스 토발즈가 만든 툴이다.

핵심 개념 3가지

• 저장소 (Repository) : 코드 보관소. 원격 저장소가 있고 로컬 저장소가 있다.
  • git init 이라는 명령어로 로컬 저장소를 만들수도, git clone 으로 원격 저장소를 만들어서 로컬 저장소에 옮길 수도 있다.
• 커밋 (Commit) : 원격 저장소. 특정 상태를 메모와 함께 현재 버전의 코드를 저장
  • 누가, 언제, 무엇을 바꿨는지를 기록하는 것
• 브랜지 (Branch)

커밋은 언제, 얼마나 자주 해야 할까

시점

논리적으로 완결된 작업 단위를 커밋해야 한다.

어떤 기능을 만들 때 완성한 이후 커밋을 하세요..

횟수

작은 단위로 자주 커밋해야 한다.

큰 기능을 만들 때는 작업 단위를 나누고, 이를 커밋해야 한다.

커밋 정보 분석

• 커밋 ID : 커밋의 특정 해쉬값
  • 이걸로 해당 커밋의 코드 상태로 되돌릴 수 있다.
• 작성자 정보 : 누가 커밋했는지 이름, 이메일 정보
• 커밋 메세지 : 코드 변경사항 등의 커밋 내용을 작성한 정보

커밋 메세지는 팀원과의 소통이다!

명확하고 일관된 작성이 중요하다!

깃 컨벤션

• 일관된 형식으로 작성하도록 정한 공식 규칙

feat : 닉네임 중복 체크 기능 구현 // Header

서비스 요구사항에 따라 각 사용자의 닉네임은 유일해야 해서 구현 // Body

JIRA: SPOASD=123 // Footer

브랜치

• 안전한 실험 공간! : 메인 코드를 건드리지 않고 막 아무거나 넣어봐도 괜찮은 코드 버전

Merge

• 완성되면 합치고, 실패하거나 문제가 있으면 삭제하면 된다.

MR, PR

Merge Request, Pull Request : 코드 검토 과정이 포함된 병합 기능

너무 많은 브랜치가 있으면 관리가 어려워진다..!

그래서 브랜치 전략이 필요하다!

• 어떻게 생성, 관리, 통합할지에 대한 규칙과 워크플로우 정의

협업 규칙

• 커밋 메세지 작성 규칙
• 브랜치 네이밍 규칙
• 브랜치 전략
• 코드 리뷰 규칙

“기술은 도구일 뿐이다. 중요한 것은 그것을 어떻게 활용하느냐이다.”