병합 된 변경 사항이 '커밋 변경'으로 표시되는 것을 방지하는 방법

Question

두 번째 개발자와 함께 기능 분기를 작업 중입니다. master 브랜치에서 변경된 사항을 가지고이 기능을 테스트하고 싶다. 일반적으로 git rebase master을 사용할 수도 있지만 몇 가지 이유로 인해 작동하지 않습니다.

• 변경 사항이 원격으로 푸시되었으며 다른 개발자와 공유되었습니다.
• rebase를 복잡하고 위험하게 만드는 마스터와의 병합 충돌이 있습니다.

그래서 master를 내 기능 분기에 병합하여 변경 사항을 적용하려고합니다. 그러나 병합 할 때 마스터에 대한 특정 변경 사항은 '커밋 될 변경 사항'으로 표시됩니다. 그것이 내가 다른 사람들의 변화의 소음 때문에 변화를 검토하기가 지저분하고 어렵다는 것을 검토하게 만들 것이라고 생각합니다.

git merge을 사용하면 관련이없는 변경 및 커밋과 함께 풀 요청을 어지럽히 지 않고 마스터에서 변경된 기능 분기를 업데이트하는 올바른 방법은 무엇입니까?

대부분의 사람들이 리베이스를 권장하므로이 사안에 대해 좋은 답변을 찾을 수 없습니다. This은 가장 가까운 것으로 보이지만 그 대답에는 -1 표가 있고 다른 응답자는 실제로 질문에 대답하지 않습니다.

Answer 1

다른 한편으로는 단계적 변경 (커밋 변경)과 다른 쪽에서 요청 변경 집합을 가져옵니다.

끌어 오기 요청은 git 개념이 아니므로 변경 집합을 얼마나 잘 계산하는지는 해당 변경 내용을 구현하는 호스트 서비스에 따라 다릅니다. 풀 요청이 합당한 방법으로 변경 세트를 계산하면 설명하는 문제가 발생하지 않아야합니다. git 수준에서 에서으로 끌어 오기 요청을 할 때 변경 내용을 master..branch으로 계산하려면 -커밋을 이미 제외했을 때와 동일한 이유 때문에 병합 된 master 커밋을 제외해야합니다. branch가 생성되었습니다. I github이 올바르게 처리한다고 믿습니다.

질문의 다른 측면 : 변경 사항을 "체크인 변경 사항"으로 표시하지 않겠다는 가정 - 또는 견해 요청 검토 검토 방식과 밀접하게 관련되어 있음을 전제로합니다. 잘못 인도했다. 병합 커밋이 마스터의 변경 사항을 올바르게 통합하려면 인덱스에 표현되어야하며,이를 커밋하도록 변경해야합니다.

유일한 방법은 병합을 전혀 수행하지 않는 것입니다. 어떤 사람들은 (일부 사람들이 지속적인 rebase 작업을 권장하는 것과 비슷한 이유로) 추천합니다. 나는 그 권고안에 동의하지 않는다. (나는 왜 꾸준한 rebase 작업에 대한 권고 사항에 동의하지 않는 것과 비슷한 이유로).

병합을 유지하지 않기로 결정한 경우 git rerere을 사용하여 해당 결정의 일부를 완화 할 수는 있지만 제거하지는 못합니다. 이로 인해 충돌이 발생할 때 발생할 수있는 충돌 해결을 다시 적용하는 데 도움이됩니다. 병합을 버립니다.