작성
·
313
답변 3
0
0
아아 이제 이해됬네요!! 좋은 설명감사드립니다!! 추가적으로 pr을 날릴때 브랜치를 따로 파서 날리는데 그 이유가 pr용 브랜치, 내 메인 로직 작성 브랜치를 나누어서 각각의 기능을 분리하려고 하는 것인가요??
0
안녕하세요 :) 좋게 들어주셨다니 너무 감사합니다~
.
네, 말씀하신 것 처럼 나도 변하고, 원격 저장소도 변한 경우
(만일 충돌이 일어나는 부분을 홀로 해결할 수 있다면)
pull 해준 뒤 push해 줘도 merge가 가능합니다.
.
하지만, 만일 pull request를 이용한 코드 논의 없이
원격저장소를 다시 pull 한다면,
.
내가 열심히 내 저장소에서 뚝딱뚝딱 작업을 하고 있던 내용을
파기해야 하는 상황이 생길 수 있어요.
.
예를 들어보자면, 원격 저장소에서 아래와 같은 코드가 있엇다고 가정해보죠
ABCD
근데 질문자님께서는 이 코드를 pull 해 와서,
ABDDE
로 바꾸었다고 가정해봅시다. (C가 D로 바뀌고 E가 새로 추가되었습니다)
.
이 상태로 push하려고 할 때, 두 가지 문제점이 생길 수 있습니다.
1. 원래 원격저장소의 주인이 C를 D로 바꾸길 원치 않은 경우
> 이 경우, 코드에 대한 논의 (pull request)가 없다면, 이 코드를 받을지 말지에 대한 커뮤니케이션을 하기 어렵겠죠.
2. 질문자님께서 코드를 ABDDE로 바꾸는 동안 원격저장소가 BBCDA로 바뀐 경우
> 이 경우 충돌을 해결하기 위해 질문자님께서 애써서 작성한 E라는 코드는 버려하 할 것이고 BBCDA로 바꾸어야 할 겁니다.
이건 질문자님이 보내려던 코드가 애초에 아니죠.
.
요약하자면, 진행 중인 프로젝트에서는 (원격저장소가 수시로 변하는 상황에서는),
pull request 자체가 "코드에 대한 논의"이기 때문에, 협업을 할 때에는 pull request를 통해
"나 이렇게 수정했어~ 한 번 봐 줄래?"를 알려주는 것이
훨씬 안전하고 질문자님의 의도와 합치되는 코드를 원격저장소에 반영하기도 쉽습니다.