외관상의 변경을해야합니까?

Question

종종 소스 제어에 커밋하고자하는 사소한 코딩 스타일 변경이 있지만 변경 로그는 코드 기능에 영향을 미치지 않는 변경 사항으로 가득 차 있습니다.

나는 같은 사소한 일을 해결해야 다음에 무엇을해야 :

올바른 들여 쓰기, 간격 및 라인 (C++에 포함, .NET에서 파이썬 수입)

• 제거 및 using이를 정렬 휴식

Answer 1

코드 파일을 변경하는 경우 이러한 변경 내용을 커밋하고 공유하고 싶지 않은 이유는 알 수 없습니다. 당신이하지 않으면 다른 사람이 그들을 고칠 것이고 당신과 충돌 할 위험을 감수해야합니다.

다른 사용자가 코드베이스에서 원하는 변경 사항이 아니라면, 아마도 당신이 시간을 쓰는 데 시간을 보내는 지 스스로에게 물어봐야 할 것입니다.

Answer 2

"사소한"것들이 수정 되었습니까? 그렇다면 커밋하십시오. 그렇지 않다면하지 마십시오.

정말, 당신과 당신 팀이 중요하다고 생각하는 것에 달려 있습니다.

Answer 3

다음 큰 변경 사항을 사이드 바로 사용하십시오. 적어도 그것이 내가하는 것입니다.

Answer 4

관련없는 수정과 함께 커밋하지 마십시오.

커밋 하겠지만 커밋 메시지에 미리 정의 된 키워드를 추가하십시오. 변경 로그를 생성 할 때이 키워드가있는 메시지는 무시 될 수 있습니다.

예를 들어 [cleanup]과 같은 접두사를 사용할 수 있습니다.

[cleanup] Removed some whitespace 
[cleanup] Changed format 
Fixed some major bug. 
[cleanup] Corrected indentation 

Answer 5

내가 유일한 개발자 인 프로젝트에서 나는 이러한 종류의 수정 사항을 다른 코드 변경과 함께 수행하는 경향이 있습니다.

우리 팀이있는 프로젝트에서 나는 이러한 변화를 스스로 시도하여 '실제 작업'을 모호하게하지 않는 경향이 있습니다.

들여 쓰기와 같은 사소한 일이라도 코드베이스에 '잘못된'모든 것을 고치는 것이 중요하다고 생각합니다.

Answer 6

변경 사항 목록을 건너 뛸 때 쉽게 무시할 수 있도록 커밋 주석이 적절하게 플래그가 지정된 상태로 커밋하십시오.

변경된 기능과 동일한 작업으로 커밋하지 마십시오. 그렇게하면 무언가를 망가 뜨리면 파기 된 것을 좁히는 것이 쉬워지고 필요한 경우 리팩터링 만 되돌리기가 쉽습니다.

Answer 7

자주 커밋하는 것이 좋습니다. 언제든지 상당한 변화가있을 것입니다. 그렇게 쉬운 방법입니다. 코드 조각을 분류하고 시작하여 나중에 코드를 작성하려고 시도하면 나중에 매우 중요한 것을 저지르는 것을 잊어 버리게됩니다.

간단히 말해서, 커밋을 자주하고 변경 내용을 문서화하십시오. 거대한 변경 사항이있을 경우 태그를 지정하십시오.

Answer 8

나는 이것이 당신의 작업 환경과 어떻게 다른 사람들이 같은 프로젝트에서 일하는가에 따라 다를 것이라고 생각합니다.

내 일반적인 제안은 같은 코드로 작업하는 사람들에게 그런 경우에 대한 지침을 제시하는 것입니다. 외관 변화로 인해 체크인에 신경 쓰지 않거나 복잡한 변경 로그를 다루는 것보다는 "불만족"으로 살기 쉽습니다.

모든 사람들에게 투명한 지침은 이러한 질문을 처리하고 장래의 혼란을 피하는 가장 좋은 방법입니다.

필자는 개인적으로 코드 정리가 마음에 들고 순전히 외관상의 변화로 인해 체크인에 신경 쓰지 않을 것입니다. 그러나 간격과 줄 바꿈이 조금이라도 있다면, 어쨌든 동일한 코드 파일에서 작업하는 경우에만 변경하고 변경하면됩니다. 나는 종종 사용법을 제거하고 정렬합니다. 왜냐하면 이해가 안되는 사용법이 많이 있지만 혼란 스러울 때가 있습니다.

Answer 9

확실히 커밋하십시오. 실제 코드 변경 사항과 함께 커밋하고 이러한 변경 사항을 롤백해야한다면 미용 수정 사항을 잃을 수 있습니다.

이상적으로 커밋은 데이터베이스 트랜잭션과 같아야합니다. 시스템의 나머지 부분에 영향을주지 않고 롤백 할 수있는 관련 작업 코드입니다.

Answer 10

몇 가지 문제가 있습니다.

처음에는 지루하고 실제 작업이 충분하지 않기 때문에 코드를 변경하지 마십시오. 이 경우 프로젝트 관리자와상의하여 실제 업무가 가치가있는 것으로 할당됩니다.

즉, 변경을 위해 코드를 변경하지 마십시오. 항상 프로세스의 코드에 값을 추가하십시오.

이제 이러한 변경이 코드를 사용자 및 다른 사람이 처리하기 쉽게 만드는 데 도움이된다면 그렇게하십시오. 네이밍 표준을 지키는 것과 같은 일들, 리팩터링 코드, 등등. 그러나 프로젝트 관리자가 "네, 괜찮습니다. 이것으로 2 시간을 보내고 저에게 다시 돌아 오십시오."라고 말할 수 있도록 작업을하십시오.

변경을 완료하면 변경 사항을 적용하십시오. 직전에 완료 한 실제 작업이나 그 다음 작업을 함께하지 마십시오. 분기 간, 코드 검토 및 일반적인 코드 찾아보기 사이에서 병합 버그 픽스가 발생합니다.

"그래, 버그 7711을 수정하고 약 100 개의 다른 파일을 변경 했으니 까. 근데 사실 여기에 버그 수정이 있니?"

Answer 11

동일한 코드에서 작업하는 개발자 팀이있을 때 가장 중요한 것은 코드의 코스 스타일에 동의하는 것입니다. 따라서 첫 번째 작업은 팀 전체가 코딩 스타일에 동의하도록하는 것입니다.

행운을 빈다.

일단 작업을 완료하면 사람들이 스타일을 고수 할 것을 상기시키기 위해 원하는만큼 꾸미기 변경 사항을 적용하십시오.

다른 코딩 스타일의 장점에 대해 코드 완성에 훌륭한 섹션이 있습니다. 팀이 코딩 스타일 회의 전에 섹션을 읽도록 할 수 있다면 회의에 모든 도움을 줄 수 있습니다. 토론에 초점을 맞 춥니 다.

Answer 12

어떤 방식 으로든 논란이 될만한 사항 (예 : 대괄호의 위치)을 변경 한 경우 나머지 팀과 코드 스타일을 동의했는지 확인하십시오. 자신의 선호하는 스타일로 변경 한 다음 체크인하십시오. 그렇지 않으면 다른 사람이 다시 변경하여 변경 사항을 확인한 다음 다시 변경하십시오.

Answer 13

그냥 커밋하지 마십시오. 커밋을 위해서. 나는 보통 내가 작업중인 코드를 추가한다. 예를 들어 메소드 A에서 버그를 수정하는 경우 모든 수정 작업도 수행해야합니다.

IMO 여러분이 코딩 할 때이 문제를 처리하는 PMD, JIndent 등과 같은 코딩 도구가 없습니다. Netebeans과 같은 일부 IDE는이 "문제점"을 경고로 표시합니다. 따라서 무작위적인/개인적인 변화는 표준을 따르는 것이 아닙니다.