git 기초

들어가며

본 글은 국민대학교 임베디드 소프트웨어 동아리 KOBOT의 과제로, 학습 내용을 정리하기 위해 쓰였습니다.

내용

git 없이 각 버전 별로 파일을 만들 경우 문제점

• 파일을 편집할 때마다 파일을 만드는 것이 번거롭다.
• 어느 파일의 어떤 부분이 변경 되었는지 확인하기 힘들다.
• 한 파일을 여럿이 동시에 편집하다가 다른 사람이 작업한 부분을 날려버릴 수 있다.

 

원격 저장소와 로컬 저장소

원격 저장소 : 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소

로컬 저장소 : 내 PC에 파일이 저장되는 개인 저장소

 

git 구성도 (출처)

이미지 출처

기초 명령어

git 구조와 git 기초 명령어 관계도

이미지 출처

git add <파일 이름>

특정 파일을 index(혹은 staging area)에 추가

 

git commit -m "커밋 메세지"

index에 있는 파일들을 로컬 저장소로 옮김

 

git push origin master

로컬 저장소에 있는 파일들을 원격 저장소로 옮김

 

git pull origin master

깃 서버에 업데이트 되어 있는 내용을 받아오는 것

※ origin : 원격 저장소, master : 기본 브랜치

 

브랜치

특정 커밋을 가리키는 포인터

브랜치의 사용 이유

원래 코드와 별개로 독립적인 개발이 가능토록 한다.

바로 main 브랜치에서 개발할 때 기능을 추가했는데 에러가 나면 UX가 떨어진다.

브랜치가 각 기능별로 쪼개서 병렬적으로 작업할 수 있도록 한다.

 

작업물 합치기

1. Pull Request 보내기
2. PR에 대한 리뷰 받기
3. 브랜치 merge하기

※ Pull Request : 수정한 자신의 브랜치를 검토 후 요청한 브랜치에 병합 할 것을 요청하는 것

    merge : 한 branch를 다른 brach로 합치는 과정

 

브랜치 관리 전략

브랜치를 어디서 생성하냐에 따라 생성된 브랜치 코드가 달라지므로 적절한 위치에 브랜치를 생성하기 위해 여러 브랜치 관리 전략을 취한다. ex) Git Flow, Github Flow, GitLab Flow

Git Flow

기준이 되는 다섯가지 브랜치

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 머지함
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 devlop 브랜치로 PR 보냄
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기 위한 브랜치
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치

master와 develop이 메인 브랜치, 나머지는 필요에 의해서 운영하는 브랜치이다.

 

git flow

이미지 출처

전반적인 Flow

1. master 브랜치에서 시작
2. 동일한 브랜치를 develop에 생성. 개발자들은 develop에서 개발을 진행
3. 개발을 진행하다가 추가적인 기능 구현( ex) 회원가입, 장바구니 등)이 필요할 경우 develop에서 개발자별로 feature 브랜치를 생성하여 기능을 구현
4. 완려된 feature 브랜치는 리뷰를 거쳐 다시 develop 브랜치에 머지
5. 모든 기능의 구현이 완료되면 develop 브랜치를 release 브랜치로 만들고 QA를 하면서 보완점을 보완하고 버그를 수정
6. release 브랜치를 master 브랜치와 develop 브랜치로 생성
7. 배포 이후 미처 발견하지 못한 버그는 hotfixes 브랜치로 긴급 수정