Cộng đồng Hỏi & Đáp của Inflearn
câu hỏi đã được viết
rebase 시, conflict 발생하는 경우에 대해서
Đã giải quyết
Viết
·
262
0
rebase 시, 충돌이 발생했을때 관련해서 질문이 있습니다.
master 의 commit이 만약 이렇게 되어있다면,
(master)
commitID_4-2 # test1.txt 수정
commitID_4-1 # test1.txt 수정
commitID_3
commitID_2
commitID_1그리고 feature/rebase의 브랜치의 commit이 이렇게 되어있다면,
(feature/rebase)
commitID_4-4 # test1.txt 수정
commitID_4-3 # test1.txt 수정
commitID_3
commitID_2
commitID_1여기서 feature/rebase 브랜치에서 master를 rebase를 하려고 한다면,
4-1, 4-2도 test1.txt를 수정했고, 4-3, 4-4도 test1.txt를 수정해서 conflict이 발생한다면,
그래서, rebase를 만약 해본다면
git checkout feature/rebase
git rebase master여기서 conflict이 발생하고, 그걸 해결하게 된다면
# conflict 발생 후, 수정
git add test1.txt
git commit -m "conflict1"
git rebase --continue
git add test1.txt
git commit -m "conflict2"
git rebase --continue
>> resolved conflict ... 이렇게 모든 conflict를 수정한 다음에 여기서 어떻게 처리할지 질문입니다.
여기서 제가 git push origin feature/rebase 를 하게된다면,
원격저장소와 로컬저장소의 commit이력이 달라서 다시
git pull origin --rebase feature/rebase 후,
다시 conflict를 수정하고 새로운 commit을 만들어서,
push를 하는게 맞는건지
여기서 어짜피 모든 conflict를 해결했으니 git push origin feature/rebase -f 로 강제로 밀어 넣던지
아니면 다른 방법으로 push를 하는건지 보통 rebase시, conflict이 발생 후, conflict를 해결하더라도 push 시, 로컬/원격 저장소간의 commit이력이 달라질텐데 이것을 해결하기 위해 어떤방법을 사용하는지 궁금합니다.
Câu trả lời 2
0
1.(로컬에서 충돌해결시)pull을 굳이 받을필욘 없어보이고 --force로 push하는게 나아보입니다.
2.그런데 더 나아보이는 대안은, 로컬에서 rebase를 시키는것이 아니라, github에서 pr을 통해 충돌을 해결하면서 바로 rebase시키는게 더 나아보입니다. 그러면 push할때 pull할지 고민할필요는 없어질것 같아요. 어차피 한번사용된 branch를 rebase를 했을경우에는 재활용하기가 어렵기 때문에, 바로 github에서 충돌해결후에 rebase하고 해당 브랜치를 삭제하는게 더 좋아보입니다.
0
안녕하세요, 인프런 AI 인턴입니다. Hyeonghwan Kwon님.
Git에서 rebase 중 충돌을 해결하고 나서의 처리는 중요한 부분이죠. 질문해주신 상황에 대해 간단히 요약하자면, feature/rebase 브랜치에서 master 브랜치를 rebase 했을 때 충돌이 발생하고 이를 해결한 후, 원격 저장소와의 싱크를 맞추기 위한 방법을 고민하신 것 같습니다.
rebase는 브랜치를 재정리하여 브랜치 히스토리를 깔끔하게 만드는 데 유용하지만, 과거의 커밋을 덮어쓰므로 원격 저장소에 업데이트하기 전에 주의해야 합니다.
옵션 1: git push --force 사용
이 방법은 전체 작업 내역을 재작성하고 있으므로, git push --force를 사용하여 원격 저장소의 커밋을 강제로 업데이트해야 합니다. 이는 로컬 브랜치의 히스토리가 변경된 것을 원격으로 반영하는 일반적인 방법입니다. 주의해야 할 점은, 이 방법은 다른 사람들이 같은 브랜치를 사용하는 경우 문제가 될 수 있으므로, 사용하는 프로젝트 관행에 따라 신중해야 합니다.
옵션 2: git pull --rebase 후 해결
이 옵션은 이미 충돌을 해결했다면 일반적으로 필요하지 않습니다. 하지만, 강제로 덮어쓰고 싶지 않다면 사용하는 방법이며, pull 과정에서도 충돌이 발생할 수 있습니다.
기본적으로 rebase 후 충돌 해소 후에는 git push --force로 원격 브랜치를 덮어쓰는 것이 일반적인 방법입니다. 다만, 이 방식은 모든 팀원이 같은 브랜치에서 작업 중인 상태에서 혼란을 초래할 수 있습니다. 따라서 팀 내의 규칙을 미리 협의하는 것이 중요합니다.
보다 자세한 사항은 아래의 유사한 질문과 답변을 통해 확인해보시기 바랍니다:
위의 링크에서 rebase와 관련된 충돌 해소 방법 및 여러 팁을 확인하실 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.