작성한 질문수 37

3

안녕하세요, 좋은 말씀 감사합니다 :)

master에 바로 하면 안되는 건 아닙니다.

branch를 따로 파고, 거기서 작업한 뒤 merge(pull request)를 날리는 가장 큰 이유는 아무래도

1. 안전빵

2. branch마다 비슷한 변경사항 그루핑

의 목적이 큽니다.

branch에서 새로운 변경사항/수정사항을 만들고, 시행착오를 겪어도 그 branch에서만 겪고, 테스트도 돌려보고

그 뒤에 (만일 branch에서 작업한 내용이 master에 merge될 수 있을 만큼 코드 자체도 완성도 있고 충돌에 대해서도 안전하고 판단되면 그 때) master와의 merge를 하는 게 이상적입니다.

무작정 master에만 작업하게 됐을 때, pull request에 대해 잘못 승인하게 되면 결국 그냥 pull & push 하는 것과 똑같이 번거로우니까요 :)

2. 예를 들어 버그 수정을 하는 브랜치, 기능 A를 추가하는 브랜치, 기능 B를 추가하는 브랜치 이랗게 나눠 놓으면 pull request가 오는 브랜치만 봐도 이 코드의 목적을 알 수 있겠죠? 이런 식으로 brancj 별로 개발의 기능을 나누고 마치 레고처럼 master에 붙여가며 로젝트를 진행하기도 합니다.

무작정 master에 추가하면, 만약 기능 A를 추가한 과거의 커밋들을 보고 싶을 때, 1번 commit은 버그수정, 2번 commit은 기능A수정, 3번은 기능 B추가.. 이렇게 커밋 내역들의 내용이 뒤죽박죽이 될테니 되게 보기 힘들겠죠..? 그래서 브랜치를 나누는 거랍니다.