[Git] branch 이해하기와 Git workflow 늦은 찍먹

🛠️ Tools/🐈 Github

minhe2810 2025. 7. 10. 00:28

1. 안정적으로 merge 성공하기

2.두 브랜치에서 만일 같은 파일, 같은 줄을 수정했을 경우, Conflict, 즉 충돌이 발생할 수 있다.

현재 HEAD는 어디있고, 즉 내가 있는 브랜치의 내용은 어떤 내용이었고, (초록색 부분)

merge 를 하려고 했던 해당 브랜치 (예시 상황에서는 coupon 브랜치)의 내용은 어떤 내용이었는지를 (파란색 부분)

vscode 에디터가 보여준다.

그렇다면

코드를 수정한 뒤에(충돌을 해결한 뒤에) 다시, git add --> git commit 을 진행한다.

그리고 나서 잘 합쳐졌는지 확인하기 위해 로그를 그래프로 한 번 살펴보자.

CLI 에서 바로 git log graph 확인하는 명령어

git log --all --oneline --graph

그래프를 보니 coupon 브랜치가 main 브랜치에 잘 합쳐진 것 같다!

이렇게 브랜치 병합(merge)에 대해서 공부를 해봤고,

자연스레 git workflow 에 대해서도 관심을 갖고 찾아보았다.

Git Workflow란 팀이나 프로젝트가 Git을 사용하는 방식, 즉 협업하는 규칙과 흐름을 정의한 것이다.

단순히 git add, git commit, git push 명령만 쓰는 게 아니라,
브랜치를 어떻게 만들고, 누가 어떤 브랜치에 작업하며, 어떤 순서로 병합하고 배포하는지에 대한 체계를 말한다.

그러다 Git flow에 대해서 공부를 하던 중, git flow에 대한 내용 중 release 브랜치에 대해서 조금 더 심층적으로 알게 되었다.

릴리즈 브랜치는 기능 개발이 완료된 이후, 본격적인 배포를 준비하기 위한 단계를 담당하며, 이 시점에서 QA, 버그 수정, 문구 변경 등 마무리 작업이 이루어진다.

따라서 , release가 "최종 검수 결과의 덩어리"니까, main과 develop 둘 다에 병합해야 함.

** 혼자서 헷갈리는 개념 정리 **

merge 를 한다는 건

브랜치를 분기해서 개발하던 것을 기존 브랜치에 해당 개발 내용을 합쳐나가겠다는 의미.

따라서 main 브랜치로 이동 후 release 브랜치를 merge를 해주는 명령어를 실행하여

main 브랜치에 버그 및 최종 검수 결과의 덩어리인 release 브랜치의 내용을 합쳐주는 것이다.

git workflow 중 한가지인 Git flow에 대해서만 이해를 하면 나머지도 대강 이해를 할 수 있을 것 같다.

따라서 Git flow를 공부하면서 대충 브랜치를 어떻게 따고, 어떤 식으로 Merge 하고 배포하는지 감이 잡힌 것 같다.

- master 혹은 main : 배포

- develop : 개발

- 3개의 서포팅 브랜치 : feature(기능 개발) / release/v1.0(배포를 준비:버전 등 메타 데이터 변경 및 버그 수정) / hotfix

* 릴리즈 브랜치를 별도로 운영해줌으로써 배포 업무와 연관이 없는 다른 팀 멤버들은 다음 버전 배포를 계속 진행할 수 있음

코딩 애플 영상을 보다가 gitlab flow 가 특이하다고 해서 youtube에 검색해서 찾아보다가 발견한 NHN cloud 영상인데

workflow 별 설명과 배경 그리고 현재 팀에서는 branch 전략을 어떻게 가져가고 계신지, 배포 어떻게 진행하시는지 설명해주신다.

아직 다 보진 못했지만 뒤쪽에 나오는 jenkins 배포 이야기도 들어봐야겠다. 내일.