관리자 버전 관리 커밋 읽기

우리 관리자는 모든 프로젝트 에서 Git 커밋을 모니터링 하고 있습니다. 일반적으로 이것은 문제가되지 않으며, 버전 관리가 특히 이후의 감사 및 분석 (문제가 발생하는 경우)을 위해 진행중인 모든 작업에 대한 로그를 제공한다는 사실을 좋아합니다.

그러나 관리자는 "스타일 수정"을 읽는 커밋 또는 작업 관리 시스템에서 티켓 번호를 참조하지 않는 커밋 메시지를 볼 때 사람들이 무엇을하고 있는지 묻는 몇 가지 의견을 제시했습니다.

이것에 대한 사회적 또는 기술적 해결책이 있습니까?

추가 정보 :이 프로젝트는 유지 관리 프로젝트이므로 "A, B, C, D를 수행 한 다음 X를 구현해야합니다"작업이 많이 발생합니다.

추가 정보 : 관리자와 함께 플래그를 발생시킨 특정 커밋 메시지는 "X, Y 및 Z에 더 나은 방법을 포함했습니다"에 가깝습니다. 이는 단순한 문체 수정보다는 리팩토링 메시지에 더 가깝습니다.

version-control management

— 피터 모텐슨
소스

의 중복 가능성 커밋 메시지에 버그 / 문제입니다 참조 좋은 실례로 간주?

— gnat

나는 당신의 관리자에 동의합니다. 2 살짜리 커밋 로그를보고 어떤 것이 언제 바뀌 었는지 알아 내고 "스타일 수정"과 같은 커밋을 보는 것은 성가신 일입니다. 관리자가 리팩토링 태스크를 태스크 관리 시스템에 추가 할 수없는 경우 이는 완전히 다른 문제입니다.

— 로봇 고트

실제 리팩토링은 스타일 변경보다 캡처에 훨씬 중요합니다. 최소한 커밋 메시지는 리팩토링 대상을 말해야하지만 실제로는 리팩토링 대상을 알고 있었는지, QA가 더 신중하게 테스트해야 할지를 알고 있었으므로 추적하고 싶습니다.

— Gort the Robot

^^^ @StevenBurnap이 말한 것-이것은 매우 좋은 습관입니다. 어떤 종류의 스타일 개선 / 리팩토링에 대한 긴 설명과 이것이 바람직한 이유에 대한 커밋 메시지를 오염시키는 대신 티켓 ID를 참조하는 것이 가치가 있습니다. 그리고 추적 노력, 경영진 / QA 등과의 의사 소통 등이 있습니다. 그리고 버그 추적기가 VCS / 코드 검토 도구와 통합 될 때 얼마나 편리한 지 시작하지 마십시오

— gnat

상황에 따라 완전히 다릅니다. 관리자는 자신의 시간의 50 %를 리팩토링에 사용하는 팀 구성원이나 티켓 참조없이 단일 커밋에 반응하고 있습니까?

— winkbrace

답변:

이것에 대한 사회적 또는 기술적 해결책이 있습니까?

나는 생각하지만 이것은 문제 가되지 않습니다 .

당신의 매니저 는 당신이 무엇을하고 있는지 알아야합니다. 그들은 당신이 가치를 제공하지 않는 많은 일을하지 않거나 티켓이 아닌 일이 왜 우선 순위를 두 었는지 확인해야합니다. 이것에 해가 없습니다. 이상적인 세상에서는 관리자가 비즈니스에 대한 기대치를 설정하여 압력이나 중단없이 모든 작업을 수행 할 수 있기 때문에 이점이 있습니다.

관리자가 티켓 작업 만 수행해야한다고 생각하고 기술 정리 작업이 티켓이되는 것을 방해하는 경우에만 문제가됩니다. 정리할 기술 부채가 항상 있습니다. 명확하고 즉각적인 비즈니스 이점을 제공하지 않더라도 항상 조정해야 할 사항.

— 텔라 스틴
소스

문체 픽스가 작업중인 티켓의 일부이고 관련되어있는 경우 더 나은 식별을 위해 작업했던 동일한 티켓 번호로 별도로 체크인하는 데 아무런 문제가 없습니다.

변경해야 할 사항을 발견하고 현재 진행중인 티켓과 관련이없는 경우 기술 부채 관련 티켓을 만들고 나중에 다시 해싱을 위해 백 로그에 넣는 것이 좋습니다.

계획하는 동안 기술 부채 관련 티켓을 통해이 방법으로 작업하려는 실제 유지 관리 티켓에 첨부하여 더 안정적으로 만들 수 있습니다.

이렇게하면 "어딘가에 있지 않은"수정 사항을 제거하고 작업중인 특정 문제 / 티켓 범주 아래에있는 모든 항목을 캡슐화 할 수 있습니다.

— 수의사
소스

알았지 만 사소한 수정이라면 완전히 바보입니다.

— Monica와의 가벼움 경주

기술 부채 99.99 %는 사소한 변화가 아닙니다. 그렇기 때문에 큰 컨텍스트 전환 인 다른 것으로 뛰어 드는 대신 티켓을 만드는 것이 좋습니다. 그것이 사소하고 작업중 인 것과 관련이없는 경우에도 별도의 주석으로 작업중 인 티켓 이름으로 체크인 할 수 있습니다. 또는 나중에 쉽게 식별 할 수 있도록 QFIX와 같은 표기법을 생각하는 것이 좋습니다. 따라서 조직이 없어도 사소한 사소한 변경 사항이 없습니다.

— AvetisG

관리자가 JIRA에서 새 티켓을보고 나서 질문을하면 어떻게 되나요? 그는 티켓이 미래의 스프린트에서 현재 티켓으로 옮겨 질 때에 의문을 제기하지 않지만 누군가가 기술 부채와 관련된 새로운 티켓을 만들 자마자 질문됩니다.

— Rudolf Olah

QFIX 표기법은 구현하기 전에 팀과 대화해야하는 것입니다. 그것은 의사 소통에 관한 것입니다. 당신은 단지 자신의 규칙을 작성하고 작성하지 않습니다. 먼저 팀으로 이야기 한 다음 동의하지 않으면 다른 해결책으로 이동하여 기본 티켓과 함께 체크인하여 별도의 의견으로 작업하십시오. 그러나 변경 사항이 사소한 경우에만 논리 변경 또는 큰 리팩토링이 포함되지 않은 경우에만 다시 한 번 유의하십시오. 무해하고 무해한 사소한 변화.

— AvetisG

@omouse 관리자가 소액 관리하고 있거나 기술 부채를 제대로 다루지 않았을 수도 있습니다. 그러나 관리자는 궁극적으로 프로젝트 전체에 대한 책임과 코드 자체에 대한 책임이 있으므로 진행중인 모든 작업과 이유를 어느 정도 인식해야합니다.

— 로봇 고트

이것은 나에게도 버그가있다.

가장 유용한 체크인에는 독특하고 변경된 내용뿐만 아니라 그 이유에 대한 설명이 포함되어 있습니다. 나는 때때로 단락 주석을 넣습니다.

개발이 시작되면 UI 요구 사항이 앞뒤로 튀어 오르는 상황에 처하게되어 코드를 본질적으로 바운스해야합니다 (예, 실제 세계는 때때로 짜증납니다). 이 경우 내 의견이 바운스 이유에 대해 명확하게 설명하고 코드가 그 위치에서 끝나는 이유를 더 중요하게 생각합니다. 그런 다음 고객과 이야기를 나눈 후 경영진이 돌아와서 그 이유를 알고 싶을 때 전체 경험을 기억하지 않고도 고객에게 보여줄 수 있습니다.

— Worrystone
소스