이전 커밋을 수정하는 경우 별도의 수정 커밋을 리베이스하거나 추가해야합니까?


11

소프트웨어 개발에서 일반적인 시나리오는 다른 사람의 코드를 검토하는 코드입니다. 이를위한 일반적인 도구는 풀 요청을 여는 것입니다.

내 질문은 리뷰에서 문제가 발견되면 변경해야한다는 것입니다.

  1. 별도로 커밋 (새 커밋)
  2. 또는 기존 커밋을 수정해야합니다 (공유 브랜치에서 기록을 다시 쓰는 것이 나쁜 소식이기 때문에 아무도 이전 커밋에서 분기되지 않는다고 가정).

첫 번째 시나리오에서는 커밋 히스토리에 약간의 노이즈가 추가되지만 증분 변경을 쉽게 추적 할 수 있습니다. 두 번째 옵션에는 반대 장단점이 있습니다.


14
당신은 커밋에 "노이즈"라고 말하지만, 나는 그것이 정확한 역사 라는 것을 읽었습니다 . 커밋 기록에서 실제로 일어난 일을 숨기려고하는 이유는 무엇입니까? 코드 검토는 코드 검토이므로 다른 것으로 칠할 필요가 없습니다. 나의 투표는이 경우의 리베이스가 아닌 별도의 커밋으로 진행될 것입니다.
Thomas Stringer

3
보통 나는 둘 다한다. 각 커밋을 개별적으로 게시 한 다음 검토가 완료되면 리베이스 및 병합합니다. GitHub는 커밋이 제거되거나 교체 된 후에도 풀 요청에 대해 계속 토론하므로 리베이스에서 기록이 크게 손실되지 않습니다. 두 세계의 장점을 모두 누리십시오.
Ajedi32

1
나는 나중에 어떻게 든 시스템 충돌을 결정한 것을 저지른 것에 대해 여러 가지 감정을 가지고 있습니다. 그 커밋은 곧 내 제작의 결함을 발견하면 역사에서 롤백하고 싶습니다. 그러나 그것들은 단지 조금이고 비용이 많이 들지 않으므로 아마도 가장 안전하고 비용 효율적이며 일관된 행동 (교리와 같이)은 항상 별도로 커밋하고 모든 사람이 도랑에 차 사고를 남겨 두는 것입니다 지금 그리고 영원히 참조하십시오. .... 그리고 결함이있는 각 분기에 확실한 메시지를 표시하여 빌드하지 않도록 할 수 있으므로 공유 분기가 없습니다.
robert bristow-johnson 2012

"저렴한"이란 무엇이며 언제 그것을 원할 수 있는지 설명 할 수 있습니까?
Kilian Foth

답변:


23

수정 사항에 새로운 문제점이없고 이전 문제점이 완료된 것으로 가정합니다. 그러나 많은 수정 사항은 자체적으로 검토 할 가치가 있으며 증분 변경을 개별적으로 검토 할 수있을 때 훨씬 쉬울 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.