dragonhyeon 님의 블로그

Git Flow 브랜칭 전략을 전제로 합니다. develop 브랜치에서 feature 브랜치로 분기한 상황입니다. feature 브랜치 개발 완료 후 develop 에 merge 시, develop 에 이미 새로운 커밋 이력이 생겨있는 경우merge 사용이 일반적히스토리를 그대로 보존하므로, 이력이 안전하게 남고 협업에 적합merge 정책에 따라 rebase 혹은 squash 를 사용할 수 도 있지만 기본적으로는 merge 사용feature 브랜치에서 개발 진행중에 develop 에서 코드 수정이 발생해 수정된 develop 코드 기반에서 개발을 이어가야 하는 경우rebase 사용이 일반적커밋 히스토리가 깔끔해지고, develop 의 최신 상태를 기반으로 개발 가능merge 를 사용하면 불필요한 병합 커..

Create a merge commit vs Squash and merge vs Rebase and mergeCreate a merge commit포크 (병렬 분기) 형태로 병합fast-forward merge 가 가능한 병합일지라도 GitHub 상에서는 해당 옵션 선택시 항상 포크 형태로 병합커밋 이력을 직선형으로 유지하고 싶다면 Rebase and merge 옵션을 선택해야 함하지만 Rebase and merge 옵션을 선택할 경우 커밋 해시는 변경됨커밋 이력 보존SHA 동일Squash and merge직선형으로 병합커밋 이력 손실SHA 변경Rebase and merge직선형으로 병합커밋 이력 보존SHA 변경

Git Flow 기반 워크플로에서의 브랜치 관리 방식develop:main 브랜치에 병합한 뒤에도 삭제하지 않는것이 일반적 (프로젝트의 지속적인 개발 흐름을 담당하는 브랜치이므로)main 브랜치로 병합 시 merge 방식이 일반적 (릴리즈 단위의 기록을 보존하려는 목적, 여러 feature 통합 흔적 유지)feature/*:develop 브랜치에 병합한 뒤 삭제하는 것이 일반적 (기능 개발이 완료되어 develop 에 반영되었기 때문에 더 이상 해당 브랜치가 필요 없음. GitHub, GitLab 등에서는 PR 을 머지할 때 자동으로 브랜치를 삭제하는 옵션도 있음)develop 브랜치로 병합 시 squash 또는 rebase 방식이 일반적 (커밋을 정리해서 develop 히스토리를 깔끔하게 유지하려는 목..

rebaserebase 는 브랜치의 분기 이후의 커밋들을 부모 브랜치의 최근 커밋 위로 재배치 해주는 작업입니다. rebase 를 진행하는 방식은 크게 두 가지가 있습니다. 아래와 같이 실행하면 develop 브랜치의 분기 이후의 커밋들을 main 브랜치의 최근 커밋 위로 재배치 해줍니다.git switch develop # develop 브랜치로 이동git rebase main # main 브랜치로 rebase 아래는 -i 옵션을 사용하여 리베이스 작업을 인터랙티브하게 진행하는 방식입니다. git rebase -i 명령어를 사용하면 단순히 git rebase 했을때와 다르게 리베이스 과정 중에 커밋을 수정, 삭제, 합치기 등 세부적으로 제어할 수 있습니다.git switch develop #..

Git 병합Git 에서 여러 브랜치에서 작업한 내용을 하나의 브랜치로 합치는 작업을 병합 (merge) 이라고 하며, 대표적으로 fast-forward merge 방식과 3-way merge 방식이 있습니다. 병합이 성공할 경우 3-way merge 에서는 병합 커밋이 자동으로 생성됩니다.비병합 커밋 (Non-merge commit): 단일 브랜치에서 발생하는 커밋으로 하나의 부모 커밋만 가지며, 다른 브랜치와의 병합 없이 그 브랜치에서만 변화가 일어난 커밋입니다.병합 커밋 (Merge Commit): 두 개 이상의 브랜치를 병합할 때 Git 이 자동으로 생성하는 커밋으로 두 개 이상의 부모 커밋을 가집니다. 하나의 병합을 진행하며 병합 충돌이 여러 번 발생하여도 병합 커밋은 최종적으로 병합이 성공하는 ..