git | Git 브랜치 전략 비교: Git Flow, GitHub Flow, Trunk-Based Development
·
git
Git Flow브랜치는 크게 main, develop으로 나누며, 이 둘은 항상 유지feature, release, hotfix는 필요할 때마다 생성되고 역할을 다하면 삭제됨 main출시 가능한 production 코드를 모아두는 브랜치버전 태그를 달아(1.0, 1.1 등) 배포 develop다음 버전 개발을 위한 코드를 모아두는 브랜치개발이 완료되면 main으로 머지 feature하나의 기능을 개발하기 위한 브랜치develop 브랜치에서 생성되고 구현 완료 후 develop에 머지feature/{name} release배포 전 QA를 진행하는 브랜치develop 브랜치에서 생성하고 QA가 통과하면 main에 머지수정사항이 있으면 main, develop에 머지release-{version} hotfi..
git | Git 브랜치 통합 방법: Merge와 Rebase 비교
·
git
Git에서 merge와 rebase는 한 브랜치의 변경 사항을 다른 브랜치에 통합하기 위한 두 가지 방법이다. merge두 브랜치를 통합한다.분기(branch)가 유지된다.merge commit이 생성된다.기존 커밋 해시가 유지된다. M이라는 merge commit이 생성되며, 기존 커밋 기록이 그대로 보존되어 히스토리가 분기된 형태로 남는다.# feature 브랜치에서:git checkout featuregit merge mainmain: A --- B --- C \ \feature: D --- E --- M rebase한 브랜치의 커밋들을 다른 브랜치 위로 옮긴다.히스토리가 직선(linear) 형태로 정리된다.기존 커밋을 재작성(re..
git | git revert 했는데 왜 다시 들어올까? — 브랜치 머지 방향이 만드는 결과 차이
·
git
git revertgit revert는 커밋을 지우지 않는다“되돌리는 커밋”을 하나 더 만든다즉, 히스토리는 살아 있고, 결과물만 바뀐다 시나리오1. dev에서 A작업을 한 후 해당 커밋 위치(C1)에서 feature 브랜치를 만듦dev:C0 ── C1(A 작업)feature: └── C1(A)2. dev에서 A를 revert 한 경우dev:C0 ── C1(A) ── R1(A revert)feature: └── C1(A) Case 1. 아무것도 하지 않고 feature -> dev 머지git checkout devgit merge feature 결과A + feature 작업 전부 dev에 들어옴이유: feature에는 revert가 없기 때문 Case 2. feature d..