소프트웨어 개발에서 일반적인 시나리오는 다른 사람의 코드를 검토하는 코드입니다. 이를위한 일반적인 도구는 풀 요청을 여는 것입니다.
내 질문은 리뷰에서 문제가 발견되면 변경해야한다는 것입니다.
- 별도로 커밋 (새 커밋)
- 또는 기존 커밋을 수정해야합니다 (공유 브랜치에서 기록을 다시 쓰는 것이 나쁜 소식이기 때문에 아무도 이전 커밋에서 분기되지 않는다고 가정).
첫 번째 시나리오에서는 커밋 히스토리에 약간의 노이즈가 추가되지만 증분 변경을 쉽게 추적 할 수 있습니다. 두 번째 옵션에는 반대 장단점이 있습니다.
14
당신은 커밋에 "노이즈"라고 말하지만, 나는 그것이 정확한 역사 라는 것을 읽었습니다 . 커밋 기록에서 실제로 일어난 일을 숨기려고하는 이유는 무엇입니까? 코드 검토는 코드 검토이므로 다른 것으로 칠할 필요가 없습니다. 나의 투표는이 경우의 리베이스가 아닌 별도의 커밋으로 진행될 것입니다.
—
Thomas Stringer
보통 나는 둘 다한다. 각 커밋을 개별적으로 게시 한 다음 검토가 완료되면 리베이스 및 병합합니다. GitHub는 커밋이 제거되거나 교체 된 후에도 풀 요청에 대해 계속 토론하므로 리베이스에서 기록이 크게 손실되지 않습니다. 두 세계의 장점을 모두 누리십시오.
—
Ajedi32
나는 나중에 어떻게 든 시스템 충돌을 결정한 것을 저지른 것에 대해 여러 가지 감정을 가지고 있습니다. 그 커밋은 곧 내 제작의 결함을 발견하면 역사에서 롤백하고 싶습니다. 그러나 그것들은 단지 조금이고 비용이 많이 들지 않으므로 아마도 가장 안전하고 비용 효율적이며 일관된 행동 (교리와 같이)은 항상 별도로 커밋하고 모든 사람이 도랑에 차 사고를 남겨 두는 것입니다 지금 그리고 영원히 참조하십시오. .... 그리고 결함이있는 각 분기에 확실한 메시지를 표시하여 빌드하지 않도록 할 수 있으므로 공유 분기가 없습니다.
—
robert bristow-johnson 2012
"저렴한"이란 무엇이며 언제 그것을 원할 수 있는지 설명 할 수 있습니까?
—
Kilian Foth