두가지 모두 하나의 branch로 통합한다는 면에서는 같은데 세부적으로 commit에 대한 부분이 다른 것으로 이해했습니다
master 브랜치(main) 와 신입인 저를 위한 rookie 브랜치가 있습니다
main = master, feature = rookie 입니다
회사 팀장님이나 상급자가 음 .... merge하도록 그러면 merge를 합니다
git checkout main(master)
git merge rookie
merge를 하고 나면 이렇게 됩니다!
병합 커밋(merge commit)을 생성하여 병합하고, 이 커밋은 병합된 브랜치의 모든 변경 내용을 포함합니다.
Merge는 브랜치의 이력을 보존하고, 작업 내용을 투명하게 유지하는 장점이 있습니다.
이력에서 어떤 브랜치에서 언제 어떤 변경 사항이 병합되었는지 쉽게 파악할 수 있습니다.
Merge 커밋은 다소 복잡할 수 있으며, Git 이력이 복잡해질 수 있습니다.
Rebase는 브랜치의 이력을 다시 쓰는 방법으로, 병합하는 대신 현재 브랜치의 커밋을 대상 브랜치 위에 순차적으로 적용합니다.
Rebase를 사용하면 이력이 더 선형적으로 보이고 깔끔해집니다. 이전 브랜치의 변경 사항을 현재 브랜치의 커밋으로 옮겨올 때 새로운 커밋을 생성하지 않고 단순히 커밋들을 옮기는 방식입니다.
Rebase를 사용하면 이력이 깔끔해지지만, 이미 공유된 브랜치에 대해 리베이스를 수행하면 문제가 발생할 수 있으므로 주의가 필요합니다.
git checkout feature-branch
git rebase main
Merge와 Rebase 모두 상황에 따라 사용하는 것이 좋습니다.
Merge는 공유 브랜치에서 주로 사용되며, 이력의 완전성을 중요시하는 경우 유용합니다.
Rebase는 개인 브랜치에서 작업하는 동안 주로 사용되며, 이력을 깔끔하게 유지하고 불필요한 병합 커밋을 피하려는 경우에 유용합니다.
git Flow는 Git 브랜치 관리를 단순화하고 프로젝트의 배포 및 유지 관리 단계를 명확하게 정의하는 데 도움을 줍니다. Git Flow의 핵심 아이디어는 다음과 같습니다:
프로덕션 환경에서 실행 가능한 안정적인 코드를 관리하는 브랜치입니다. 새로운 기능과 버그 수정은 다른 브랜치에서 개발되며, Master 브랜치로 병합됩니다.
개발 중인 기능과 버그 수정을 통합하는 브랜치로, Master 브랜치로의 배포를 준비합니다.
새로운 기능을 개발하는 데 사용되는 브랜치입니다. 각 기능마다 별도의 Feature 브랜치를 생성하고, 개발이 완료되면 Develop 브랜치로 병합합니다.
다음 릴리스를 준비하는 단계에서 사용됩니다. 개발이 완료되고 테스트가 완료된 경우 Develop 브랜치에서 Release 브랜치를 생성하며, 여기에서 추가 테스트 및 마지막 버그 수정이 수행됩니다. 이후 Master 브랜치와 Develop 브랜치로 병합되고 새 릴리스로 표시됩니다.
프로덕션 환경에서 발생한 긴급한 버그 수정을 처리하는 데 사용됩니다. Master 브랜치에서 생성되고 버그가 수정되면 Master 및 Develop 브랜치로 병합됩니다.
이러한 브랜치 전략은 프로젝트의 안정적인 유지 관리와 버전 관리를 용이하게 합니다. 이전에 릴리스한 코드를 수정하거나 새로운 기능을 동시에 개발하고 배포하는 데 도움이 됩니다. 또한 Git Flow를 사용하면 작업이 분리되어 충돌 및 혼란을 줄이고 다수의 개발자가 효과적으로 협업할 수 있습니다.
Git Flow를 구현하려면 Git 명령어를 사용하여 브랜치를 생성, 병합 및 삭제하는 작업을 수행하며, 명확한 작업 흐름을 유지하는 것이 중요합니다.