dragonhyeon 님의 블로그

초기 커밋: README.md, .gitignore 등의 설정 파일들을 main 브랜치에 커밋main 브랜치에서 develop 브랜치를 분기하고, 개발에 필요한 템플릿 코드 등을 develop 에 커밋기능 단위로 develop 브랜치에서 feature/ 브랜치를 분기하고 작업 진행ex. feature/add-user-profile기능 개발이 완료되면 해당 feature 브랜치를 develop 에 병합병합 이후 develop 브랜치에서 버그가 확인되면 develop 브랜치에서 바로 수정 (git flow 방식에서는 develop 브랜치에 직접 커밋하지 않는 것이 원칙이긴 함)develop 브랜치에서 발견된 버그의 규모가 크다면 feature/ 브랜치로 분기하여 작업 진행후 다시 develop 에 병합실제 ..

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 변경