[10분 테코톡] 렉스의 Git 브랜칭 전략

[@NytubeW]

최고에요! 도움 됩니다.

[@silian-jang]

목소리가 좋아요

[@donghoonshin2366]

정말 좋은 발표네요!! 감사합니다

[@mangopark11]

Git 에 대해 잘보고 갑니다 😆 화이팅이용

[@anyoungyoon2876]

설명 너무 좋아요! 친절한 설명 감사합니다!!

[@신동재-b4l]

git 브랜치에 대해 잘 몰랐는데 간단하게 잘 알려주셔서 감사합니당 :)

[@daw2able]

재밌게 잘 보았습니다..!

[@김수연-b8i9w]

좋은 설명 감사합니다 :)

[@Mtryr_ai]

깃 브랜칭 전략 개념에 대해 가장 깔끔하게 설명해주는 영상이네요👍

[@동차-x8f]

진짜 너무 깔끔한 설명 감사드립니다 덕분에 한번에 이해했어요

[@lokba1014]

전체적인 흐름 요약 파트가 설명이 특히 좋네요~. 한 눈에 흐름을 파악할 수 있었네요

[@kookbrown]

잘봤습니다 소개고맙습니다

[@djwhy5510]

깃 잘몰랐는데 덕분에 잘 배웠습니다~

[@제로-o4w]

덕분에 깃 브랜칭 전략 이해했습니다!!

[@sdaqkr3392]

감사합니다

[@TEST44403]

내용 좋네요

[@mjin1220]

잘 봤습니다 :)

[@KByunish]

release branch는 왜 develop branch로 merge 되어야 하나요?
저희 팀에선 Release에서 버그가 발견되면 develop으로 돌아가서 해당내용을 수정하고 다시 release로 머지 하는 방식을 통해 브랜치가 dev -> release -> master 로 한방향으로만 통합되는 방식을 써오고 있어서요

[@kimsijun]

그렇게 작업을 진행할 수도 있습니다. 회사 별로 팀 별로 전략이 다르니, 정답은 없겠지만 release에서 처리를 하는 이유는 다음과 같습니다. 만약 release에서 발견된 이슈를 develop에서 수정해 다시 release로 올린다고 했을 때, 그 사이에 develop에 merge된 기능이 있다고 가정해보세요. 해당 기능은 개발이 완료 됐지만, 아직 QA를 진행하기에 부족한 기능일 수도 있습니다.(기능 개발이 완료가 안됐을 수도 있지요. 그럼 개발이 안됐는데, 왜 develop에 병합을 하냐고, 반문하실 수도 있지만...develop에 병합을 하는 것은 기능을 공유하기 위함이기도 합니다.) 그럼 아직 QA 또는 배포를 할 준비가 되지 않은 기능이 추가되고, 해당 기능에 대한 QA를 진행하지 않은 채로 배포하게 되는 것입니다. 그렇기 때문에 release에서 검수를 진행하고 배포를 하는 것입니다. 답변이 됐길 바랍니다.

[@유현지-c6z]

렉스 멋져요