코드에서 중요하지 않은 오타를 발견하면 (예 : print (error) 문에서 잘못된 아포스트로피) 해당 오류를 해결하기 위해 노력할 가치가 있습니까? 아니면 단순히 혼자 두어야합니까?

특히, 나는 중요하지 않은 오타를 해결하는 가치와 커밋 로그의 합산을 측정하는 것이 궁금합니다. 나는 그들을 해결하기 위해 기울고 있습니다. 내가 현혹되고 있습니까?

저의 개인적인 느낌은 품질을 향상시키는 것이 커밋 로그 항목을 조금만 추가해도 약간의 불편 함이 있다는 것입니다. 결국, 깨진 창 효과 를 고려할 때 작은 개선 사항이 많이 계산됩니다 .

TRIVIAL:태그 에 접두사 를 붙이거나 VCS가 지원하는 경우 사소한 것으로 표시 할 수 있습니다.

당신은 농민이 아니며 개별적으로 해결하는 것이 좋습니다. 변경 사항이 많을수록 더 좋습니다. 충돌하는 버그 수정이 500 개의 댓글 / 오타 변경 사항과 혼합되는 것을 원하지 않습니다.

일반적인 경우 : 예

그건 항상 가치는 유지 보수성 증가하는 소프트웨어의합니다.

그냥 가세요

릴리스를 출시하려는 경우 ...

... 그리고 팀장이 아닌 경우 그에게 확인하십시오 .

커밋 로그의 내용과 관련하여 ...

나는 고립 된 오타를 고치는 것에 관한 것이라면 최소한 "기능"관련 커밋과 구별되는 것을 작성해야한다는 것에 동의합니다.

일반적인 관행은 이슈 트래커에 끊임없이 변하지 않는 작업을 수행하여 영원한 변화와 끝없는 변화를 추적하는 것입니다. 예를 들어, 다음과 같은 작업을 수행하는 것은 드문 일이 아닙니다.

• 대규모 자동 무해한 정리 (공백 스윕)
• 문법과 오타 사냥 행위,
• 시스템 수정 빌드
• 기타...

사람들이 올바르게 문서화 된 티켓을 만드는 것에 대해 게으른 경우에 대한 것만으로도 타스크 ID로 사용되지 않도록주의하십시오. 특히 ID에 연결되지 않은 커밋을 거부하면 (이것은 좋지만 이와 같은 큰 작업은 게으른 개발자에게 더 매력적입니다).

오타는 커밋으로 추가해야합니다. 철자가 틀린 단어 나 문법 오류를 수정하면 코드의 가독성이 향상됩니다.

"고정 오타"또는 "file.c의 고정 오타"와 같은 커밋 메시지를 사용하면 이러한 커밋을 다른 주요 코드 커밋과 구별 할 수 있습니다.

예, 특히 프로젝트 초기에이를 수행해야합니다.

왜? 두 가지 점 :

1. 오타가 너무 늦을 때까지 오타가 "중요한"것인지 아닌지를 모를 것입니다. 모두가 큰 문제는 아니라고 생각하기 때문에 일부 수정 프로그램은 수정되지 않을 수 있습니다. 그 때까지

2. 수백 줄의 코드 / 함수 호출을 한 후 수정하는 것보다 오타를 조기에 고의적으로 수정하는 것이 훨씬 쉽습니다. 다시 말하지만 임시 해킹은 놀랍도록 빠르게 반영구적으로 반영 될 수 있습니다. 이것이 "CollapseAll"및 "ColapseAll"메소드가 모두있는 오브젝트를 처리해야하는 이유입니다.

최종 사용자가 볼 수있는 문법 오류의 경우 예, 사용자 또는 QA가 오류를보고하여보고 할 수 있으므로 추적해야 할 수 있으므로 커밋을 수행하는 것이 좋습니다. 이미 수정 된 경우 문제를 해결하는 데 시간이 더 걸릴 수 있습니다.

그래도 코드 주위의 주석에서 문법 오류 인 경우 실제 코드 변경의 일부가 아니며 코드 문서를 업데이트하는 경우가 아니라면 아무것도하지 않습니다.

커밋 로그를 정리하는 것이 걱정된다면 다른 일을하고있는 것입니다. :-) 빈번한 커밋은 좋은 것입니다! 나는 항상 오타 수정을 저지른다. 최대한 빨리 코드베이스에 참여하여 개발주기를 단축하십시오!

나는 찬성 투표합니다. 나는 사람들이 물건을 체크인하는 것을 싫어하는 회사에서 일했습니다. 거의 모든 것을 의미합니다. 코드 리뷰는 광범위했기 때문에 오타가 수정 된 변경 사항을 체크인하면 신음합니다. 코드의 상태를 상상할 수 있습니다. 실제로 코드는 끔찍하지는 않았지만 와인처럼 흐르기보다는 기적처럼 들렸습니다.

변경 관리 프로세스에서 허용합니까?

내 환경에서 내가 한 모든 커밋은 비즈니스 사용자 또는 필수 시스템 수준 변경에 의해 요청 된 변경 요청에 다시 연결되어야하며 해당 최종 사용자 테스트 프로세스가 완료됩니다. 설명하는 것과 같은 간단한 오타는 아마도 그 중 어느 것으로도 기록되지 않았을 것입니다 (아무도 모르게 4 년 넘게 존재했던 내 앱 중 하나에서 오타 및 문법 오류를 발견했습니다). 전화하기 자신을 설명하기가 매우 어려울 것입니다.

"실제"변경이 필요할 때 한동안 설명하고있는 것처럼 변경 사항을 저장하고 (실제로 메소드 이름의 철자가 틀렸고 방금 발견했습니다) 변경 사항을 저장합니다. "다양한 오타 수정"을 로그에 넣습니다.

DVCS를 사용하여 기록 편집

클린 커밋 히스토리에 대해 걱정이되면 기능 브랜치 에서 주요 작업을 수행하십시오 . 분산 VCS 로 작업하는 경우 커밋 히스토리를 메인 브랜치로 푸시하기 전에 커밋 히스토리를 쉽게 편집 할 수 있습니다. SVN을 사용하는 경우 Git을 사용해보십시오. Subversion과 양방향 으로 상호 작용할 수 있으며 실제로 Subversion을 커밋하기 전에 기록을 편집 할 수도 있습니다.

그렇지 않으면 상식을 유지하십시오

커밋 히스토리를 원하지 않거나 편집 할 수 없는 경우 자동 테스트 또는 컴파일에 영향을 미치지 않는 작은 오타에 대해 조기 또는 원자 적 커밋을 수행하는 기능적인 이유는 없습니다 . 이 경우 커밋 기록을 깨끗하게 유지하는 것이 실제로 원자 커밋을 수행하는 것보다 중요합니다. 하나 또는 두 개의 오타 수정과 "일반"수정을 혼합 해도 잠재적 인 검토 프로세스에는 영향을 미치지 않습니다. 그러나 더 큰 코딩 세션 후에 "정리"할 때 몇 가지 사소한 수정 사항을 하나의 커밋으로 그룹화 할 수 있습니다.

그 주 기능 버그 여전히 원자 커밋에 최대한 빨리 최선을 다하고되어야한다.

여기에 대한 답변의 일반적인 어조는 사소한 오타에도 "모든 것을 빨리 커밋"하는 전략을 제안하는 것 같습니다. 나는 의견에 동의하지 않고 토론을 환영합니다.