rebase 시, conflict 발생하는 경우에 대해서
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이력이 달라질텐데 이것을 해결하기 위해 어떤방법을 사용하는지 궁금합니다.
Answer 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와 관련된 충돌 해소 방법 및 여러 팁을 확인하실 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
깃 풀(git pull)에 대한 궁금증이 있습니다!
0
11
1
섹션7 수업자료 업로드 부탁드립니다.
0
22
2
gitforwindows에서 맥은 뭘 다운받아야 하나요...?
0
31
2
d-day count소스및 그라비티에서 기술하면 뭔가 내용이 안나오네요
0
21
1
간단한 사이드 프로젝트 작성에도 Max 요금제를 결제하는게 좋을까요?
0
56
2
git 커밋한 내용 궁금합니다.
0
27
1
충돌의 최소화 파트 질문입니당!
0
28
1
자바스크립트 파일 중, DOM 영역에서 querySelector가 아닌 다른 함수를 쓰는데 괜찮을까요?
1
81
2
48강에 필요한 아스키아트 자료가 첨부되어 있지 않습니다.
0
54
2
mac python 3.10 - permission denied
0
54
1
26강 [게임 메인 루프 및 메뉴 구현]에서 2가지 오류가 있어서 남기게 되었습니다.
0
69
2
Rider에서 .ignore 플러그인으로 .gitignore 파일 내용 생성시 Csharp으로 검색되는 내용이 없습니다.
1
67
2
EC2 설정보다 RDS를 먼저 설정하는 이유
0
101
1
pull할때
0
41
1
기획과 개발 반복 실습 질문
0
138
1
궁금한 점
0
58
2
깃허브 main 브랜치에서 dev 브랜치 분기
0
68
2
깃허브에 new_git_github.git 생성한후 터미널에서 push할때 에러가 안생겨요.
0
84
1
안녕하세요. 맥에서 키체인등록 후 push할때 문제가있습니다.
0
189
1
선생님 안녕하세요. 해당 강의 질문이 아니라 다른 강의에서 질문 드립니다.
0
85
1
Main Branch 자동 생성 안됨
0
246
2
질문 있습니다
0
82
1
안녕하세요 강사님 질문 있습니다.
0
100
2
소스트리를 따로 쓰는 장점이 뭔가요?
0
786
2