마스터의 역사적인 커밋이 손상되어 어려움을 겪은 사람이 있습니까?

예. 백 포트, 되돌리기 및 이등분이 더 어렵습니다. 역사를 읽고 있습니다 (아래 참조).

그렇다면 개별 커밋 메시지와 변경 사항을 버리지 않고 이러한 어려움을 피할 수있는 간단한 방법이 있습니까?

브랜치가 괜찮은 해결책이지만, 내가 아는 것은 아닙니다.

그러나 나는 개인 커밋을 버리는 것 (또는 오히려 스쿼시)이 옳은 일이라고 생각합니다.

개발 중, 특히 TDD를 수행 할 때는 조기에 커밋하는 것이 좋습니다. 당신은 당신이하고있는 일의 완전한 흔적을 원하기 때문에 요즘 역행하거나 상황이 잘못되기 시작한 시점을 정확하게 파악할 수 있습니다 (또는 아마도 당신이 씹을 수있는 것보다 더 큰 리팩토링에 빠지게 될 것입니다). 커밋하세요.

그러나 기능 / 변경 사항을 푸시 할 준비가되면 커밋은 패키지화 된 변경 사항입니다. 이상적으로는 원 자성이므로 가능한 한 다른 변경 사항과 독립적으로 [검토, 재 기반, 병합, 체리 픽 선택, 되돌림, 주석으로 볼 수 있음] .

프로젝트 기록을 살펴보면 소프트웨어 변경을 자체적으로 평가해야합니다. 빌드합니까? 테스트가 제공됩니까? 작동합니까? 무엇을합니까? 해당 기능을 제공하기 위해 어떤 파일을 변경해야합니까?

커밋을 어셈블해야하고 가능하면 병합을 통해 어려워집니다. 따라서 나는 당신이 어디로 왔는지에 대한 추적을 잃어 버리는 것을 의미하더라도 밀어 넣기 전에 역사를 정리하는 것이 적절하다고 생각합니다.

답변