위클리 과제는 내 언어 위주로 정리를 하려고 한다.
😀 Git에서 branch merge 방법들과 각 방법의 특징
❤️ merge commit 만들기
merge commit 란?
: 두 브랜치의 변경 사항에 대한 커밋을 유지하면서 머지 커밋을 새로 하나 생성하는 방식
<장점>
히스토리의 커밋 내용을 모두 유지하면서 변경 사항을 병합할 수 있다. 프로젝트의 진행 상황을 명확하게 이해하고 추적할 수 있다.
<단점>
프로젝트의 규모가 커지면 복잡성이 증가한다.
❤️ squash and merge 하기
: 하나의 기능에 대한 여러 커밋들을 압축하여 머지하는 방식이다.
<장점>
pr에서 가장 중요하고 필요했던 내용만 압축하여 보여줄 수 있다.
<단점>
히스토리를 저장할 수 없어, 상세한 커밋 이력을 잃게되는 단점이 있다.
❤️ rebase and merge 하기
: 현재 브랜치를 target 브랜치 위에 rebase 시킨 후, 병합하는 방식이다.
<장점>
: 깨끗하고 선형적인 커밋 히스토리를 만들어준다.
<단점>
: 브랜치가 복잡한 경우 복잡한 충돌을 일으킬 수 있따.
😀 Git Flow 브랜치 전략
: 메인 브랜치는 모든 기능들이 합쳐진 배포를 위한 브랜치이다. 그런데, 여기서 모든 기능을 만드는 작업을 진행하면, 여러 기능들에 대한 커밋들이 뒤섞여 복잡해질 수도 있고, 협업과정에서 다른 개발자가 나의 커밋을 잘못 만지게 될 수도 있다. 이런 상황을 방지하고자 git 브랜치를 효과적으로 관리하기위한 워크플로우이다.
: git flow는 아래와 같이 3개의 브랜치로 구분한다.
❤️ Main 브랜치
: 출시 가능한 프로덕션 코드를 모아두는 브랜치
-> 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치
❤️ Develop 브랜치
: 다음 버전 개발을 위한 코드를 모아두는 브랜치
-> 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치
-> 개발이 완료되면 Main 브랜치로 머지
❤️Supporting 브랜치
: 필요할 때마다 생성되고, 역할을 다하면 삭제
-> 이 브랜치 덕분에 팀이 병렬적으로 역할 수행
Feature 브랜치
: 하나의 기능을 개발하기 위한 브랜치
-> 기능이 개발 완료되면 다시 Develop 브랜치로 머지
-> Merge Commit을 생성하며 머지 (히스토리가 특정 단위로 묶이게 됨)
Release 브랜치
: 소프트웨어 배포를 준비하기 위한 브랜치
-> Develop 브랜치에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정
-> Main과 Develop 브랜치에 둘다 머지
Hotfix 브랜치
: 이미 배포된 버전에 문제가 발생
-> Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 머지
--> Git Flow는 명시적으로 버전관리가 필요한 이를 테면, 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트에 적합
--> git flow는 복잡해서 요즘엔 github flow도 많이 사용한다.
⭕ git flow 나의 언어로 정리
: 일단 이 전략은 웹 어플리케이션보다는 버전관리가 필요한 앱에 적합하다. 이는 브랜치를 관리하는 전략이다. 크게 3가지로 나뉜다. 일단 Main 브랜치는 배포를 위한 브랜치이다. 그 다음 Develop 브랜치는 버전 관리를 위한 브랜치이고, Supporting 브랜치는 필요할 때마다 생성되는 브랜치이다. 이는 다시 3개로 나뉜다. Feature 브랜치는 기능 단위로 개발하기 위한 브랜치이다. 이후 디벨롭 브랜치에 머지한다. Release 브랜치는 배포 전 데이터 수정, 버그 수정을 위한 브랜치이다. 마지막 호픽스 브랜치는 배포 이후, 그 버전에 문제가 생겼을 경우 해결하기 위한 브랜치이다. 해결 완료 후, main, develop 브랜치에 모두 머지한다.
아무튼 git flow는 브랜치를 관리하기 위한 전략인 것이다. 역할에 따라 나누어 브랜치를 관리하고 머지하며 협업하고 사용한다.
