git branch 전략은 왜 사용할까? #2

Closed BeokBeok closed 2 years ago

git branch 전략은 왜 사용할까?

Git 브랜치 전략을 사용하는 이유

팀으로 개발하면 많은 branch가 생성되는데, 이 branch 들을 관리하고 한 branch로 통합 하기 위해서는 규칙이 필요하다. 이 규칙을 잘 정하는 방법을 Git 브랜치 전략이라고 이해했습니다! 프로그램 설계 잘하기 -> 소프트웨어 설계 ex) MVC, MVP, MVVM Git branch 관리 잘하기 -> Git 브랜치 전략 ex) GitHub Flow, Git Flow, GitLab Flow

➕
기본적인 골짜는 비슷하지만 회사마다 브랜치 전략이 다릅니다. 하지만 목적은 팀 단위 프로젝트를 효율적으로 관리하기 위해 사용합니다. 팀원이 수정한 코드가 내가 작업한 코드와 겹치게 되면 충돌이 발생하는데, 이를 최소화하기 위한 목적도 있습니다.

Git Repository

Upstream Repository는 개발자들이 공유하는 저장소로 최신 소스코드가 저장되어 있는 원격 저장소 Origin Repository는 Upstream Repository를 Fork한 원격 개인 저장소 Local Repository는 내 컴퓨터에 저장되어 있는 개인 저장소

장점 : 원본 Repository에 영향을 주지 않고 다양한 실험을 할 수 있다

➕ Origin Repository는 Upstream Repository가 없는 개인저장소도 포함됩니다. (예, 종성님 기준으로 UpbitAPI Repository) 이 부분도 회사마다 다르지만, 주로 Upstream Repository를 fork하지 않고 그대로 사용하고 브랜치만 관리하는 방향으로 개발합니다. fork를 하게 되면 내 개인 계정에 Repository가 생기게 되서 보안상 이슈가 될 수 있고, 팀원이 무슨 일을 하는지 보기가 어렵습니다. 하지만 오픈소스 contributor로 활동하려면 Upstream Repository를 fork해서 PR을 올립니다.

JIRA 티켓

해야 할, 하고 있는 업무들을 카드 형식으로 정리해서 일정을 관리하는 소프트웨어 자신의 업무와 고민을 정리하고 공유하는 것은 의무이자 역량 JIRA 티켓을 만들고, 각 티켓별 소요 시간 산정과 티켓별 우선순위, blocker 정리를 하면 개발에 필요한 일정 산정이 가능하다 하나의 티켓은 되도록 하나의 커밋으로 한다

참고자료 개발자가 Jira tickets를 통해 일해야하는 이유

➕ 회사마다 JIRA를 운영하는 방식이 다 다릅니다. 위의 정리한 글이 정답이 아닐 수 있기 때문에, 업무를 효율적으로 관리하기 위한 일종의 시스템으로 봐주시면 좋을 것 같아요.

Github Flow

GitHub flow: CI를 필수 조건으로 도입하여 항상 master 브랜치는 지속적으로 배포가 가능하도록 유지하며, develop 브랜치가 따로 있지 않다

CI(Continuous Integration): 개발자를 위한 자동화 프로세스인 지속적인 통합. 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되는 것

CD(Continuous Delivery) 지속적인 제공: 개발자가 코드를 작성하고 build하면 테스트 환경, production environment(실제 서비스를 위한 운영 환경)에 자동 배포

CD(Continuous Deployment) 지속적인 배포: Continuous Delivery + 사용자가 사용하게 될 버전에까지 자동 배포. 사람의 개입 없이 test 코드 만으로 배포를 통과시킨다

참고자료 : Continuous integration vs. continuous delivery vs. continuous deployment

➕ CI가 필수는 아니지만, 있으면 좋습니다. CI가 좋은 이유는 팀원마다 개발 환경이 다르기 때문에 이를 통일할 수 있다는 것입니다. CD같은 경우에는 테스트버전까지는 CD를 활용하나, 실제로 사용자가 사용하는 버전에는 CD를 하지 않습니다. (실수로 디버그 버전이 노출될 수 있기 때문)

Git Flow

git-flow 에서 사용하는 5가지 종류의 브랜치

master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출시 버전을 준비하는 브랜치 hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

develop 브랜치에서는 버그를 수정한 커밋들이 추가된다 develop 브랜치에서 feature 브랜치를 생성 feature 브랜치에서 기능 추가 작업이 완료되면 develop 브랜치로 merge

develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성 QA를 진행하면서 발생한 버그들은 release 브랜치에 수정

QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge

여러 커밋을 더 작은 개수의 커밋으로 합치는 squash를 하는 이유: 커밋 그래프를 단순하게 가져가고 의미 있는 커밋들로 관리하기 위해서

작업 브랜치를 완료한 후 rebase 하는 이유 : 작업 브랜치가 develop 브랜치의 최신 상태 다음에 commit 되도록 하기 위해서

질문 : 최신 develop 브랜치에 rebase 하기 위해 5번 직전에 git fetch upstream 을 해야 할 것 같은데, 해당 코드가 없습니다. rebase 할 때 fetch upstream이 자동으로 되는 건가요? 자답 : pull에 fetch가 포함되어 있다 git pull = git fetch; git merge git pull -rebase = git fetch; git rebase

git fetch : 원격 저장소로부터 commit, file, ref를 다운로드 하는 것. local repository에 강제로 merge 되지 않으므로 fetch가 local 작업에 영향을 미치지 않고 다운로드 할 수 있다. ref: git commit을 나타내는 hash 값

merge: 원격 저장소로부터 받은 commit A-B-C를 내부 commit A-D-E 다음에 한 개의 commit H로 잇는다 commit H에 B-C 내용이 포함되어 있다 ex) A-D-E-H 원격 저장소를 최신 데이터로 만들고 싶을 때 사용하기

rebase: 외부 저장소로부터 받은 commit A-B-C 다음에 내부 commit D-E를 잇는다 이때 D, E는 A-B-C에 따라 변경된 D, E 이다 ex) A-B-C-D-E 현재 작성하고 있는 데이터를 최신 데이터로 만들고 싶을 때 사용하기

참고 자료 Git pull GIt-flow, GitLab-flow, Github-flow란?

➕ squash merge는 주로 feature -> develop 브랜치로 머지할 떄 활용합니다.

상대적으로 feature 브랜치는 커밋수가 많기 때문에 히스토리 관리가 어려워집니다.

rebase merge는 주로 develop -> main 브랜치로 머지할 때 활용합니다.

develop 브랜치는 main 브랜치를 기준으로 만들기 때문에 rebase merge가 가능하며, rebase는 브랜치를 하나로 합칠 때 사용합니다.

@DoTheBestMayB 추가 의견을 달았으며, git의 merge와 rebase에 대해서 그림을 첨부해서 설명해주시면 더 좋을 것 같아요

@BeokBeok

기존 commit 상태 A-B-C : remote commit A-D-E : local commit 상태 : remote commit을 local commit에 합치려고 한다

원래 상태

merge 후 상태 remote commit 내용이 local commit 다음에 H commit 하나로 추가된다 merge

rebase 후 상태 remote commit 다음에 local commit 내용을 이어 붙이다 이때 기존 local commit D와 E는 remote commit B, C 내용이 반영된 D’ E’ 가 된다 rebase

좋습니다! 👍

DoTheBestMayB / UpbitAPI