Git 추출 요청 중 충돌 시 대응

입문

나는 라식 요청에서 충돌이 발생할 때 어떻게 해야 하는지가 초보자의 혼란의 첫 번째라고 생각한다.어느 것이 좋을지 모르겠지만 난처하지 않도록 한번 해보자.

준비

master부터 feature까지의 지점은 각각 몇 개씩 제출한다.
github의 pull-request 에서 master 를 가져올 때 충돌이 발생하는 경우.

[option1] feature에서 merge master.

master 최신

master merge

를

충돌 해결

feature 원격push

github에서pull-request

합병

git checkout feature
git merge master
(resolove conflicts)
git push origin feature

Benefits

한 번의 충돌 해결

역사를 다시 쓰지 않음

push를 강제할 필요가 없음

Drawbacks

통합 작업에서 로컬 통합 로그,github의 통합 로그 두 개가 남고 큰 의미가 없는 제출

[option2] feature에서 merge origin/master

feature 검사

pull featurefeaturemerge

충돌 해결(SourceTree가 메시지를 보내지 않음 주의)

feature 원격push

github에서pull-request

합병

git checkout feature
git pull origin master
(resolove conflicts)
git push origin feature

Benefits

option1과 완전히 같은 결과는 구조이지만 최근 +합병을 한 번 얻으면 빠르다

[option3] master rebase를 특징으로 합니다.

master 최신

feature 검사

master를 피처로 복사

충돌 해결

원격 피처origin/master

github에서pull-request

합병

git checkout feature
git rebase master
(resolove conflicts)
git push -f origin feature

Benefits

지점의 역사 기록이 다르고 이해하기 쉽다

Drawbacks

여러 차례 충돌 해결, 번거로움

원격 재작성 강제

[option4] origin/master rebase를 특징으로 합니다.

feature 검사

強制pushfeature,rebase

충돌 해결(SourceTree가 메시지를 보내지 않음 주의)

원격 피처origin/master

github에서pull-request

합병

git checkout feature
git pull --rebase origin master
(resolove conflicts)
git push -f origin feature

Benefits

option3와 완전히 같은 결과, 구조지만 최신 획득 + 기본 한 발만 더 빠르다

총결산

github에 합병 제출을 남기는 것을 감안하면 로컬에 합병 제출의 재기초를 남기지 않는 것은 낭비가 없다.다만 합병 작업은 여러 차례 위험한 향기가 발생할 뿐이다.
이 대응으로 혼란스러우면 Git가 잘 모른다는 평가를 받기 때문에 미리 생각을 정리하려고 한다.