main, dev 기능별 브랜치를 생성하고 합치며 분업과 협업 안정적인 배포에 도움이 됩니다.
git을 사용하면 현재 코드에 문제가 생겼을 때 비교적 쉽게 정상적으로 작동하던 과거 코드로 복구할 수 있습니다. -> git reset, revert...
스냅샷 방식으로 다른 방식(delta-base?)의 버전 관리 도구 보다 가볍고 빠릅니다. -> delta방식은 코드에 변경이 있으면 파일 전체를 새로 저장하는 듯 하다.
git만 설치해서 사용할 수 있지만 github와 같은 외부 저장소와 같이 사용합니다.
브랜치 전략
팀 프로젝트를 할 때 팀원간에 약속없이 브랜치를 사용하면 커밋간에 충돌이나 변경이 일어나 레포지토리에 저장된 코드에 오류를 만들고 최악의 경우에 서비스를 배포중인 main 브랜치에도 안좋은 영향을 줄 수 있다.
이를 방지하기 위해서 git을 같이 사용할 때는 main 브랜치와 dev 브랜치를 분리하고 dev 브랜치에서도 기능별로 별도의 브랜치를 만들어 사용한다. 이는 디렉토리 구조와 같이 계획한다.
브랜치를 나누고 사용 규칙을 만들어도 브랜치가 충돌하지 않도록 주의를 기울여 사용해야한다.
깃 브랜치 사용 예시(git-flow)
main, dev 브랜치는 항상 존재한다. (작은 규모의 개인 프로젝트는 main 브랜치를 dev브랜치로 사용하기도한다.)
main(master): 최종버전이 올라오는 브랜치 서비스가 가능한 수준의 안정적인 코드가 올라오며 CI/CD를 적용하여 제품 서비스 서버에 자동 배포를 진행하기도 한다.
dev: 기능별로 작성한 코드를 통합하고 테스트하는 브랜치 수시로 기능이 붙었다가 사라지는 등 개발을 위해서 비교적 자유롭게 사용한다. (기능별로 작성한 코드는 통합되기전에 어느정도 오류 발생 가능성을 확인한다.) 코드를 main 브랜치에 올리리 전에 최종 테스트용도로 사용하기도 한다.(release 브랜치를 만들어서 관리하기도한다.)
feature(기능별로 다양한 이름): 기능별로 작성되고 합쳐지는 브랜치 주로 기능에 따라 이름을 작성한다. dev브랜치에 중요한 업데이트가 있으면 업데이트를 반영하여 새로 만들기도 한다.(dev 브랜치에서 새로운 브랜치를 만들고 개발중이던 feature 브랜치를 합친다.)
주의
같은 기능을 여러명이 개발하지 않는다
하나의 기능을 만들고 pull/push 완료되기 전에 연관된 추가 기능 개발을 하지 않는다 (먼저 올린 커밋이 거부되면 연관된 추가 개발 기능도 당연히 같이 거부되거나 정상적으로 작동하지 않는다)
기능 개발에 많은 시간이 걸린다면 적당히 나눠서 최소 1일 1커밋 한다(완성하고 한번에 올리면 문제가 생겼을 때 수정이어렵다)
