우리는 종종 릴리스 브랜치에서 파일/패키지의 이름을 바꾼 다음이 변경 사항을 많은 다른 것들과 함께 트렁크에 병합해야합니다. 큰 문제는 많은 SCM 솔루션 (현재 SVN)은 파일 이름을 추적하지 않는다는 것입니다. SCM이 MyOriginalFileName과 MyRenamedFileName이 동일한 파일/클래스/등임을 알만큼 인텔리전트가 아니기 때문에 제품의 릴리스 지점을 다시 트렁크에 병합하면 이러한 변경 사항을 잃을 수 있습니다.GIT가 파일 이름 변경을 추적하지 못한다면 어떻게 이러한 병합 변경 사항을 잃지 않게 할 수 있습니까?
우리가 뭔가 잘못하고있는 것 같아요, 이것을 처리하는 GIT 방법은 무엇입니까?
나는 힘내가 이것을 추적 할 수 있다고 믿는다.
예를 들어, 테스트 자식 저장소를 만들었습니다. test.txt라는 파일 하나를 추가하고 커밋했습니다.
그런 다음 해당 파일의 이름을 변경하고 변경 사항을 커밋했습니다. 여기
는에서 자식 로그 내 커밋 :[master cf5c827] test
1 files changed, 0 insertions(+), 0 deletions(-)
rename test.txt => test_renamed.txt (100%)
내가 제안하는 것은 당신의 SVN 저장소에서 자식 저장소를 만들 git-svn을 사용하는 것입니다. 그럼 그걸 가지고 놀 수 있고 니가 필요로하는지 알 수있어.
나는 SVN에 익숙하지 않아서 문제가 뭔지 확신 할 수 없다.하지만 힘내는 좋은 직업을 가진 것처럼 보인다. 이름을 바꿉니다.
이름 바꾸기를 한 후에 파일을 git 색인에 추가했는지 확인해야합니다. 그렇지 않으면 이전 파일을 이름을 바꾸지 않고 삭제 한 것입니다.
파일의 이름을 바꾸고 몇 가지 사항을 변경하면 어쩌면 #include 파일 중 하나의 이름을 변경했을 수도 있습니다. 비율은 새가 원본 파일에 방법과 유사한 의미
rename: MyOriginalFilename -> MyRenamedFileName (99%)
, 그래서 심지어의 내용의 정확한 사본 일 필요는 없다 : 당신이 커밋 할 때 같은 메시지가 나타납니다 파일.
실제로 Git은 파일을 파일로 추적하지 않지만 트리 구조 내에서 내용을 추적합니다. 차이점은 하나의 파일에서 다른 자식으로 덩어리를 옮길 때도 자동으로이를 인식하고 이에 따라 병합을 적용하므로 수동으로 작업 할 필요가 없다는 것입니다.
물론 이것은 이동 된 청크가 크고 고유 할 때만 작동하지만 특히 전체 파일의 이름을 변경할 때 매력처럼 작동합니다.
힘내 가 추적 의 이름을 변경 사용하지 않지만, 감지에게 이름을 변경 기반의 휴리스틱 유사성을 사용 않습니다. Git은 변경된 파일을 비교/검사하고 이름 변경, 그리고 병합을 해결하는 동안 어떤 파일이 일치해야 하는지를 결정합니다. 그것은 실제로 잘 작동합니다.
너무 간단한 테스트 케이스를 사용하면 이름 변경 감지 알고리즘으로 인해 작동하지 않을 수 있습니다. 그러나 진짜 합병에 그것은 잘 작동해야합니다.