Git rebase가 잘못된 위치에 파일을 패치합니다.

Question

git rebase가 의도 한대로 작동하는지 여부 또는 문제를 발견 한 경우 확실하지 않습니다. 나는 lorem ipsum을 사용하여 공개 저장소에 그것을 복제했다. (https://github.com/drewclauson/git-rebase-example)

여러 줄 (see lorem ipsum.txt)에 대해 정확히 동일한 두 개의 코드 섹션이있는 경우 문제가 발생합니다. 이상적으로 코드는 DRY를 유지하기 위해 리팩토링되지만 동일한 파일에 중복 된 코드가 존재한다는 것을 알지 못했습니다.

branch1에는 master에없는 커밋이 있고 그 반대의 경우도 있으므로 branch1을 master에 리베이스합니다.

branch1'schange is adding a line between lines 23 and 24. ("코드 라인 추가 테스트")

master'schange is editing line 23. I는 master 상 branch1을 리베이스 때 branch1's의 변화가 라인 24-25 사이 대신 patched in between lines 8-9을 얻는다 커밋

(선 (23)에 'NEW TEXT "를 삽입).

나는 git의 연산에 대해 많이 알고 있지 않지만, 24-25 행을 추가해야하는 커밋의 컨텍스트와 관련이 있다고 가정하고있다. 기본적으로 이전과 이후의 줄을 기반으로 패치를하고 싶습니다. 파일의 앞부분에 동일한 코드가 있기 때문에 줄 번호를 고려하지 않고 패치를 던집니다. 아니면 제가 빠진 것이 있습니까?

고마워, 나는 아직도 자식에 대한 상대적으로 안돼서, 그래서 난 그것에 대해 뭔가를 이해하지 못할 수 있습니다.

Answer 1

예상대로 Git은 일치하는 컨텍스트를 찾고 변경 사항을 적용합니다. 일반적으로 rebase가 충돌없이 성공하면 모든 것이 좋지만 때로는 그렇지 않습니다. 필요하면 결과와 fixup을 항상 확인하십시오.

Git을 사용하기 위해이 복제본을 사용하지 않는 것이 가장 이상적이지만, "성공적인"리베이스 이후에 커밋되지 않은 커밋을 피할 수있는 다른 방법이 있습니다. 예를 들어 어떤 함수에 변수 x을 사용하는 코드 블록을 추가하는 분기가 있다고 가정 해 봅시다. foo(). 이제 누군가가 x이 기술적 인 이름이 아니며 master의 foo_counter으로 이름을 바꾼다고 가정합니다. 우리가 브랜치를 master에 리베이스하면 (자), 선언 된 적이없는 변수를 참조하고 있기 (위해) 때문에, 결과적으로 커밋이 실패해도, 코드의 텍스트 머지가 성공할 가능성이 있습니다.이 시나리오에서는, x 대신 foo_counter을 사용하라는 리베이스 커밋. 다시 말하지만 항상 rebase의 reslt를 확인하십시오.

이것은 병사와 비교했을 때 rebasing의 단점을 암시합니다. 병합은 새로운 Git 사용자에게 종종 손실됩니다. 병합은 원래 분기의 커밋을 유지하므로 최종 병합 커밋 만 확인해야합니다. 그러나 리베이스를 사용하면 리베이스 된 커밋 각각을 테스트하여 리포지토리의 무결성을 저하시키지 않아야합니다. 종종 rebase 된 브랜치는 중간에 커밋을 untestable 상태로 남겨 두면서 맨 위에 추가 커밋을하여 수정 될 것입니다. 최종 결과가 괜찮은 경우에도 이러한 상황이 발생할 수 있습니다. 이것은 중요하지 않겠지 만 Git의 bisect을 사용하면 테스트 할 수있는 기록을 가지게됩니다. 리베이스 (rebasing)를 통해 달성 할 수있는 것은 아니지만, 단지 조금 더 많은 작업이 필요합니다.