푸시의 최종 커밋이 작동하는 한 중간 커밋을 중단 한 것이 괜찮습니까?

관련 : 모든 자식 커밋이 프로젝트를 작업 상태로 유지해야합니까?

로컬로 다음 커밋을 수행한다고 가정 해보십시오.

• 데이터베이스 스키마를 수정하여 애플리케이션을 중단하십시오.

• 데이터베이스 스키마와 다시 호환되도록 애플리케이션을 업데이트하십시오.

두 커밋을 푸시 master하는 한 작동 상태로 유지됩니다. 그러나 기록 버전이 손상되었습니다.

git rebase -i커밋을 함께 스쿼시하는 데 사용할 수 있다는 것을 알고 있습니다 . 그러나 결과 커밋은 크고 설명이 적습니다. 커밋 기록을 검색하여 변경 한 이유를 찾으려면 내가 한 일과 이유를 보여주는 원래 커밋을 찾으십시오.

내 질문은 :

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

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

의상의 브랜칭 전략에 크게 의존하지만, 개발 브랜치에서 커밋을 중단하면 일반적으로 많은 의미가 있다고 생각합니다. 소스 제어를 사용하는 데있어 가장 큰 "승리"는 작은 변경 사항을 롤백 할 수 있으며 때로는 계란을 뭉치면 계란을 부셔서 옴릿을 만들어야합니다.

마스터를 오염시키지 않고 개별 커밋을 유지하는 간단한 방법은 분기를 사용하는 것입니다. 마스터 브랜치의 이력을 오염시키지 않고 세밀한 이력을 가질 수 있도록 파괴 / 실험적 재료를 거기에 넣을 수 있습니다.

깨진 커밋은 "그냥 일어나"는 것이지 세상의 종말을 의미하지는 않습니다. 나는 머리 뒤로 약간의 잔소리가 들려서 원칙적으로 문제가있는 코드를 고의로 체크인 해서는 안되며 , 따라서 역사적 버전을 포함 해서는 안된다는 것을 말하지만 , 전쟁을 벌이는 것이 아닙니다.

Git의 칭찬 분기 모델은 팀이 gitflow 또는 단순화 된 버전을 채택하는 경우 특정 분기에서 깨진 커밋을 유지하는 것이 가능합니다 . "클린 마스터"정책이있는 모든 것. 이 경우, 최종 작동 버전을 병합 커밋으로 체크인 할 수 있습니다. 여기서 (파손 된) 히스토리 버전은 저장소에서 사용 가능하지만 기본 라인에서는 사용할 수 없습니다.

팀이 그러한 브랜칭 모델을 채택하지 않은 경우 전체 로트를 마스터하여 완료 할 수있는 핑계가 있습니다.

아냐, 괜찮아

당신이 git bisect(그리고 그 킬러 기능을 좋아하지 않는 사람)을 한 적이 있다면 , 모든 커밋이 빌드되는 역사의 가치를 알고 있습니다.

bisect빌드하지 않는 동안 많은 커밋 git bisect skip이있는 경우 마지막 좋은 커밋을 찾기가 어려운 많은 커밋이 있습니다.

기능 분기를 완료하고이를 마스터로 병합하는 경우, 히스토리가 명확하고 빌드되도록 병합하기 전에 분기를 정리하십시오.

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

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

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

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

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

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

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

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

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

짧은 답변 : 예

테스트 :

테스트 중심 개발은 실패한 테스트 (즉, 실패한 테스트)를 작성한다는 의미입니다.
그런 다음 테스트가 작동하도록 코드를 작성하십시오.

개발:

작게 커밋하고 자주 커밋하십시오.
각 커밋은 롤백 지점입니다. 잘못된 경로에 있다는 것을 알고 있으면 이전 지점으로 비교적 쉽게 롤백 할 수 있습니다. 커밋이 충분하면 정확한 지점으로 롤백 할 수 있습니다.

경고:

이것은 의미 하지 않습니다

1) 깨진 코드를 마스터에 확인하십시오.
2) 모든 사람들이 검토 할 수 있도록 모든 마이크로 커밋을 푸시해야합니다.

작업을 위해 가지를 사용하십시오. 검토 프로세스에 대한 마이크로 커밋을 잠재적으로 압축하여 적절한 주석이있는 논리적으로 구별되는 단위로 만듭니다. git을 사용한다면 원래 커밋 세트를 잃지 않을 것입니다. 마스터에 병합 될 검토 프로세스에 대해 더 논리적 인 새로운 커밋 세트를 만들 수 있습니다.

나는 커밋이 로컬이고 다른 사람들에게 밀리지 않는 한 괜찮을뿐만 아니라 실제로 작동하는 좋은 방법이라고 생각합니다. 깨진 코드를 다른 사람에게 푸시하지 마십시오.