Subversion (우리가 직장에서 사용하는 것)은 커밋에 대한 의견을 요구하도록 구성 할 수 있지만 단순히 이것을 켜는 힘이 없습니다. 내가 알고 내 신속하게 커밋 뒤에 이유를 이해하는 것이 유용하기 때문에 내 커밋 주석 이유가있는 경우에만 메모리 조깅 등이다. 그러나 이것은 내가 항상 얻는 두 가지 반응에 맞서기에 충분하지 않은 것 같습니다.
- 시간이 너무 오래 걸리며 변경 사항을 리포지토리로 가져오고 싶습니다.
- diff를 보는 것만 큼 쉽습니다.
나는 심지어 단순히 JIRA 이슈 ID를 넣는 것의 가치와 그것이 이슈와 자동으로 어떻게 연결되는지를 보여 주지만 여전히 주사위와는 관련이 없습니다.
최악의 경우, 전화를 걸 수 있는 사람 은 같은 캠프에 있습니다. 귀찮게하고 싶지 않으며 diff를 보는 것이 좋습니다.
나는 그것이 옳은 일이라는 것을 알고 있지만 어떻게 그들이 빛을 보게 할 수 있습니까? 동료 개발자를 설득 할 수없는 경우에도 경영진이 비즈니스를 위해 옳은 일임을 설득 할 수 있습니까?
답변
“왜”에 중점을 둡니다. 그것의 모든 차이점을 잘보고 누군가가 코드 섹션의 논리 흐름이나 그와 비슷한 것을 바꾸는 것을 보았지만 왜 그것을 바 꾸었습니까? 이유는 일반적으로 관련 티켓 (JIRA)에 있습니다.
그들은 왜 “왜”가 중요한지 궁금해 할 수도 있지만, 2 년 동안 그 변경의 영향을 미치는 버그를 발견했을 때 그 버그가 발생한 이유를 아는 것이 새로운 버그를 수정하는 것뿐만 아니라 오래된 버그가 다시 발생하지 않습니다.
감사 이유도 있습니다. 바인딩 커밋 및 티켓 ID는 확인하기가 정말 쉽습니다. 버전 2를 푸시하고 있습니다. 이는 결함 23, 25, 26 및 27을 수정하지만 결함 24에 대한 커밋은 없으므로 여전히 미결합니다.
답변
그들이 합병을하고 지원을 처리하도록하십시오. 다시 말하지만, 당신은이 일을 할 수있는 위치에 있지 않지만, 이전 커밋에서 문제를 해결할 수있는 사람이 있다면 정중하게 울타리 위로 보내라고 말하십시오. 커밋 주석이 없기 때문에 내가 한 일을 말할 수 없습니다.이를 변경해야합니다.
분기 병합에도 사용됩니다. 그것이 당신에게 해당되는지 아닌지는 확실하지 않지만, 그것은 내가 의견을 유용하게 생각하는 한 영역입니다.
다시 한 번, 귀하의 보트가 아니라 소프트웨어 팀을 관리했을 때 그들이 좋은 커밋 의견을 주면 그들에게 주별 상태 보고서 대신 사용할 것이라고 말했습니다. 그 후 훌륭한 커밋을 얻었고 관리자로서 진행중인 일을 추적하는 것이 더 쉬웠습니다.
답변
코드에 줄 바꿈과 간격이 필요한 것과 같은 이유로 체크인 주석이 필요합니다. 더 쉽게 추적 할 수 있도록 읽고 이해하십시오.
때때로 당신은 비교를 비교할 필요가 있지만, 종종 그렇지 않습니다. 개발자가 필요로하는 모든 것을 2-3 문장으로 읽는 것만으로 비교할 수 없게하는 것은 총 시간 낭비입니다. 왜 개발자 시간의 가치가 보이지 않는지 궁금합니다.
답변
- 좋은 예를 설정하십시오. 자신의 커밋 메시지를 유용성의 빛나는 예로 만드십시오. 팀이 스토리 및 결함을 관리하는 데 사용하는 다른 시스템에 대한 참조를 포함하십시오. 변경 사항을 요약 한 간단한 설명과 변경 사항이 필요한 이유에 대한 적절한 설명을 제출하십시오.
- 적절한 커밋 메시지가 없으면 추가 작업이 발생할 때마다 제출자에게 질문을 던지십시오. 이것과 함께하십시오 (그러나 바보는 아닙니다).
- 역할을 과도하게 수행하지 않으면 커밋 메시지를 사용하여 매일 변경 로그를 보내는 스크립트를 작성하십시오. 이것은 유용한 메시지가 개정판을 탐색하는 것보다 이점이 있다는 주장에 신뢰성을 부여합니다. 또한 매일 매일 무슨 일이 일어나고 있는지 확인할 수 있으므로 관리가 도움이 될 수 있습니다.
- 동맹국을 확인하십시오. 바라건대 당신에 동의하는 다른 개인이 적어도 한 명 있기를 바랍니다 (아마도 동의하지 않음). 그 사람이나 그 사람들을 찾아서 당신이 혼자 서 있지 않도록 더 설득하십시오.
- 적절한 커밋 메시지가 시간을 절약 한 방법 (또는 불량한 메시지로 인해 시간이 많이 소요됨)을 언급 할 기회가 있으면이를 포착하십시오.
삐걱 거리는 바퀴가되는 것을 두려워하지 마십시오. 다른 사람들의 나쁜 습관과 싸우는 것은 종종 마멸의 전쟁입니다.
답변
이것은 내가 들었던 가장 기괴한 질문 중 하나입니다. 사람들이 무언가를 고치는 데 몇 시간 또는 며칠을 보내고 커밋 메시지를 입력하는 데 2 초가 더 걸리나요?! 근시안적인 사람들과 일하는 것에 대해 걱정할 것이라고 말해야합니다. 그들은 분명히 그들의 잠재력을 최대한 발휘하기 위해 도구를 사용하지 않습니다.
다음은 지난주에 관련된 코드 검토의 예입니다. Google의 버전 관리 소프트웨어는 병합에서 기록을 보존하지 않으므로 이전 변경 사항의 경우 정확한 지점을 찾아야합니다. 그렇지 않으면 커밋 메시지에 “지점 Y에서 병합 됨”과 같은 내용이 표시됩니다. 지점 Y는 “지점 Z에서 병합 됨”을 표시 할 수 있으며, 더 깊은 수준의 중첩은 실제로 실제 커밋 메시지를 갖습니다.
신입 사원은 역사를 정확하게 추적하는 방법을 몰랐습니다. 이는 본질적으로 diff와 함께 일하고 있음을 의미합니다. 그는 자신이 추적하고있는 버그와 관련된 코드를 주석 처리하는 것을 보았다. 코드의 주석을 해제하면 버그가 사라졌습니다. 그는 디버깅 중에 누군가가 코드를 주석 처리했다고 가정하고 실수로 체크인했습니다.
코드 검토 중에 우리 둘에게 옳지 않은 느낌이 들었습니다. 그래서 실제 커밋 메시지를 추적하고 1 년 전에 해당 코드를 제거해야 할 정당한 이유가 있음을 발견했습니다. 새 직원은 코드를 수정하여 이전 버그를 다시 소개하지 않고 새로 발견 된 버그를 수정했습니다.
철저한 단위 테스트와 같이 이러한 종류의 회귀를 피하는 더 좋은 방법이 있지만 단위 테스트에서 2 초의 커밋 메시지 “낭비”시간으로 귀찮게 할 수없는 사람들을 볼 수는 없습니다.
답변
여기에 정확히 같은 문제가 있었으므로 Subversion에 커밋 사전 후크를 추가하여 사용자 스토리 번호로 시작하지 않은 커밋을 수락하지 않습니다 (예상 형식에 대한 일부 기본 패턴 일치).
000-0000을 입력하는 것을 막을 수는 없지만, 한 번만 파괴적인 바보가 완벽하게 수용 가능한 숫자를 만들면 숫자를 구성합니다.
나는 일련의 사용자 이야기가 들어간 빌드를 찾으려고 며칠을 보낸 후에 이것을했습니다. 네, 그것은 어디 다른 프로세스 실패를 다루는했지만, 그것은 여전히 매우 추적 할 수있는 가치있는 정보를 제공합니다.
답변
좋은 커밋 의견은 좋은 문서, 느리고 기능이 부족한 두뇌를위한 캐시 또는 긴 디버깅 / 문제 분석 / 조사 결과의 캐시와 같습니다.
예를 들어 디버깅, 로그 분석 등 무엇이든 알아낼 때마다 결과와 결과는 소중합니다. 물론 대부분의 작업을 반복 할 수 있지만 시간이 걸릴 수 있습니다. 따라서 항상 결과를 문서화해야합니다.
여전히 문서화에는 시간이 걸리고 때로는 “이 작업을 한 번만 수행해야하므로 왜 적어 두어야합니까?”와 같이 필요하지 않은 것으로 느껴지기도합니다. 괜찮습니다. 결과를 처음으로 문서화하지 않았으므로 두 번째로 동일한 작업을 수행하자마자 결과를 문서화하는 것이 영리합니다.
따라서 동료가 커밋 의견을 추가하는 것이 너무 많은 일이라고 생각하는 경우, 예를 들어 적어도 Jira 사례 / 티켓을 통해 해결하고 있다고 지적하는 경우, 각각의 이유에 대한 질문에 지속적으로 응답해야한다는 압력에 동기를 부여 할 수 있습니다. 체인지 셋.
제 생각에는 문서는 요청되는 정보의 함수로 작성되어야합니다. 예를 들어, 메일 서신은 매우 훌륭한 문서 시스템입니다. 질문은 나중에 검색 할 수있는 답변을받습니다. 즉, 메일 링리스트와 포럼이 실제로 지식 기반으로 작동하는 방식입니다.
불행히도 내가 근무하는 곳에서는 3 개월 후에 메일이 자동으로 삭제되므로 실제로는 항상 작동하지는 않습니다.