체크인 코드에 충돌 마커를 남겨 두는 데 정당성이 있습니까?

충돌 마커를 고려하십시오. 즉 :

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

이 질문을 게시하도록 동기를 부여한 특별한 경우에, 책임이있는 팀 구성원은 방금 업스트림에서 지점으로 병합을 완료했으며, 어떤 경우에는 방금 이전에 대한 일종의 문서로 주석으로 남겨 두었습니다. 해결되었습니다. 그는 그것을 컴파일 된 상태로두고 테스트를 통과 했으므로 생각만큼 나쁘지 않습니다.

그러나 본능적으로, 나는 정말로 이것에 반대했다. 그러나 악마가 나 자신을 옹호하는 것은 그가 왜 그 일을했는지 ​​볼 수있다.

• 다른 팀 개발자에게 병합 결과로 변경된 사항을 강조하기 때문입니다.
• 특정 코드 조각에 대해 더 전문적인 사람들은 추측 할 필요가 없도록 주석으로 표시된 문제를 해결할 수 있기 때문입니다.
• 업스트림 병합은 올바른 고통이며 모든 것을 완벽하고 완벽하게 해결하는 시간을 정당화하기 어려울 수 있으므로 일부 반 완료 FIXME 통지가 필요하므로 원래 충돌을 주석으로 사용하여 문서화하지 마십시오.

내 이의 제기는 본능적이지만 합리적으로 정당화하거나 내 위치를보다 현명하게보고자합니다. 누군가 나에게 사람들이 다른 사람과 함께 나쁜 시간을 보냈거나 경험이 나쁜 이유 (또는 악마의 옹호자를 지원하고 지원 할 수있는 이유)를 보여 줄 수 있습니까?

내 자신의 즉각적인 관심사는 관련된 파일 중 하나를 편집하고 변경 사항을 가져 왔으며 실제 충돌이 있었지만 주석이 달린 파일을 가져 오는 경우 분명히 성가신 것입니다. 그런 다음 실제로 매우 지저분한 파일을 가지고 있었을 것입니다. 다행히도 그렇게되지 않았습니다.

이것은 분명히 잘못입니다. 변경 사항을 추적하는 것은 버전 제어 시스템의 작업이며, 병합 결과 변경된 내용을 표시하는 diff 도구의 작업입니다. 커밋 로그 및 코드에 주석이 있어야 변경 내용과 이유를 설명 할 수 있습니다. 그러나 IMHO, 충돌 마커를 주석으로 남겨 두는 것은 죽은 코드를 남기는 것과 같습니다.

일부 코드와 관련하여 비슷한 문제가 있었으며 (어쨌든 귀하의 경우와 비슷합니다) 실제로 어디서나 호출되지 않는 메소드로 이동했습니다. 사람들이 왜 이런 일을하는지 물었을 때 아직도 코드 블록이있을 때 조금 더 안전하다고 느꼈습니다. 가장 명백한 반론은 그것이 VCS 직업이며 그들의 것이 아니라는 것입니다. 그러나 또 다른 측면도 있습니다. 다른 사람이 배우거나 변경하는 동안 코드를 읽고있을 때는 아마도 그러한 주석에 의해 추적 될 것입니다. 그는 분명히 그것을 읽고 아마도 그것이 왜 여기 있고 현재의 직업과 어떤 상관 관계가 있는지 이해하기 위해 약간의 시간을 할애 할 것입니다. 충돌 마커는 이미 해결 된 충돌의 표시이므로 시간 낭비입니다.

주석은 과거에 있었던 코드, 과거에 코드에 발생한 이벤트, 또는 병렬 유니버스 (또 다른 분기)에 존재하는 코드가 아니라 존재하는 코드를 참조해야한다고 생각합니다. 과거. 팀원의 방식대로 마커를 남겨두면 적어도 세 가지 문제가 발생합니다.

1. 원래 코드는 아마도 blah blah null 으며 버그 보고서는 "Null을 사용할 수 없으며 이것이나 그 밖의 것을 사용하십시오"라고 말했습니다. 따라서 두 사람이 독립적으로 버그를 수정했으며 수정 사항이 병합되면 충돌이 발생했습니다. 이제 의견은 문제가 무엇인지, 수정 사항이 수정 된 것이 아니라 과거 어느 시점에서 두 가지 다른 수정 사항이 있음을 설명합니다. 그다지 도움이되지 않습니다. 같은 의견 //blah blah needs a non-null argument은 적어도 변경된 내용을 표시합니다 (그리고 그 정보는 버전 관리 시스템의 커밋 의견에서 더 쉽게 사용할 수 있습니다).
2. 병합 된 버전은 원래 줄 중 하나처럼 보이지 않을 수도 있습니다. 어쩌면 당신이 blah blah가 이것을 가지고 그것을 원한다면, 올바른 형태는blah blah (this,that) 또는 심지어 더 복잡한 것입니다. 이 경우 충돌 메시지를 주석으로 남겨두면 나중에 코드를 읽으려는 사람을 혼란스럽게 할 수 있습니다.
3. 대부분의 버전 관리 시스템은 프로젝트 히스토리에 대한 액세스를 제공합니다. 예를 들어, 이클립스 (svn으로) 파일을 마우스 오른쪽 버튼으로 클릭하고 "히스토리 표시 ..."라고 말한 다음 "현재와 비교 ..."라고 말하면 차이점을 강조하는 diff 창이 나타납니다. diff 하이라이트에 실제 차이점이 포함되어 있고 그 주위에 주석이 포함되어 있지 않은 경우 이해하기 쉬워집니다.

체크인 코드에서 충돌 마커가 얼마나 귀찮습니까?

너무 짜증나.