좋은 / 더 나은 소스 코드 제어 방법을 시행하는 방법?

나는 내가 틀린 문제에 집중하고 있다고 생각하므로 내가 생각할 수없는 최적의 해결책을 제시하기 전에 먼저 문제가 무엇이라고 생각하는지 설명 할 것입니다.

현재 상황 :
현재 내 동료들은 프로젝트 전체에 변경 사항이 퍼져있는 엄청난 양의 덩어리에서 코드 변경을 커밋합니다. 얼마 전까지 만 .zip 아카이브를 일부 네트워크 공유에 배치했기 때문에 진행 상황입니다. 여전히 합병은 악몽입니다. ​​솔직히 말해서 충분했습니다. 그리고 나는 또한 이야기하고 설명하고 구걸하는 것에 지쳤습니다. 나는 끊임없이 "나쁜 사람"이되지 않고 멈추어야한다.

내 솔루션 :
문제에 대한 인식이 없거나 관심이없는 것 같고 며칠 이상 지속될 수있는 노력을 기대할 수 없기 때문에 ... 시간, 파업 서버가 잔소리.

내 질문 :
나는 여기에서 떨어져 있습니까? 아니면 잘못된 문제를보고 있습니까? 뭔가 빠진 것 같습니다. 문제를 해결하기위한 도구를 살펴보면서 잘못된 것을 묻는 것 같습니다.

이 문제를 해결하기위한 도구를 찾아야합니까? 아니면이 문제를 해결하려면 어떻게해야합니까?

인간의 문제에 대한 기술적 해결책을 찾고 있습니다. 거의 작동하지 않습니다.

그 이유는 팀원들이 규칙을 따르지 않고 무언가를 받아들이지 않거나 (의미를 이해하지도 않는 경우) 규칙을 우회하려고하기 때문입니다. 예를 들어, 개발자가 단순히 체커의 요구를 따르지 않고 스타일 규칙을 받아들이고 이해해야하는 이유가 바로 여기에 있습니다.

과거에 실제로 사용했거나 실제로 기회를 얻지 않고 염두에 두었던 몇 가지 방법이 있습니다. 팀 내 직위에 따라 일부 사례에 적용되지 않을 수도 있습니다 (평판이 뛰어난 팀 리더 인 경우 학부생 인 경우보다 더 나은 시야를 확보 할 수있는 기회가 있습니다) 인턴쉽 기간 동안 팀에 합류했습니다).

1. 동료와 문제를 논의하고 커밋의 결과를 설명하십시오. 복잡한 병합이 드문 커밋 의 직접적인 결과 라는 것을 이해하지 못할 수도 있습니다.

   나는 단지 병합이 항상 복잡 하다는 것을 확신 한 많은 프로그래머들을 알고 있었다 . 그들은 하루에 최대 한 번 커밋을 수행하고 Visual Studio의 diff 및 자동 병합과 같은 강력한 도구를 사용하지 않았으며 수동 병합 연습이 열악했습니다. 그들에게이과는 아무 상관이 없었다 그들에게 , 그리고 병합의 고유 한 특성이었다.

2. 다른 회사 (특히 동료가 깊이 존중하는 회사)에서 일어나고있는 일에 대한 구체적인 예를 제공 하십시오. 그들은 단순히 그것이 문제라는 것을 알지 못하고 하루에 최대 한 번의 커밋이 모든 팀이하는 일이라고 확신 할 수 있습니다.

   어떤 사람들은 5-10 명의 팀이 생산에 최대 50 번의 푸시를하는 팀이 있다는 것을 알지 못합니다. 이는 하루에 평균 5-10 번의 커밋을 의미합니다. 그들은 그것이 어떻게 가능한지, 왜 그렇게하는지 이해하지 못할 수도 있습니다.

3. 예를 들면. 충분히 작은 커밋을하십시오. 가능하면 일주일에 걸쳐 자신과 병합을 나란히 보여주는 간단한 프레젠테이션을 수행하십시오 (버전 제어에서 이러한 종류의 정보를 추출하는 것이 쉬운 지 확실하지 않습니다). 병합 중에 발생한 실수를 강조하고 실수 (0에 가까워 야 함) 수와 비교합니다.

4. 적절한 경우 “내가 말한”기술을 사용하십시오 . 동료가 고통스러운 병합으로 고통받는 것을 볼 때 작고 빈번한 커밋이 병합을 (상대적으로) 고통없이 만들 수 있다고 큰 소리로 말합니다.

5. 커밋을 수행 할 수있는 최소 기간이 없다고 설명합니다. 커밋은 심지어 몇 초만에 이루어진 사소한 변경에 해당 할 수도 있습니다. 파일 이름 바꾸기, 쓸모없는 주석 제거, 오타 수정은 즉시 커밋 할 수있는 모든 작업입니다.

   프로그래머는 작은 커밋을 두려워하지 말고 많은 변경 사항을 하나의 큰 커밋으로 모으십시오.

6. 적절한 경우 팀 대신 개인과 협력하십시오. 특히 빈번하고 작은 커밋을 거부하는 사람이있는 경우,이 사람과 개별적으로 대화하여 왜 거부하는지 확인하십시오.

   그들은 팀에 무슨 일이 일어나고 있는지에 대한 힌트를 줄 수있는 완벽하게 유효한 이유를 줄 수 있습니다. 내가 들었던 몇 가지 이유 :

   • “교사 / 멘토는 하루에 한 번의 커밋을하는 것이 최선의 관행이라고 말했습니다.” 대학 교사들로부터 들어야 할 것을 감안할 때 놀랍지 않습니다 .

   • “나의 동료들은 저의 커밋을 줄여야한다고 말했습니다.”나는 일부 팀에서도 그 사실을 알고 있으며, 그들의 요점을 이해합니다. 우리는 실제로 내 커밋으로 채워진 로그를 가지고 있었으며 (4 명의 팀원이 하루에 한 번 커밋을 수행하지 않아도하기가 어렵지 않음) 동료들을 실망 시켰습니다.

   • "작은 커밋으로 인해 개정판을 찾기가 어렵다고 생각했습니다."팀이 설명적인 로그 메시지를 작성하려고 할 때에도 타당한 점이 있습니다.

   • "버전 관리 서버에서 너무 많은 공간을 낭비하고 싶지 않습니다."그 사람은 커밋이 어떻게 저장되는지 (저장 공간이 얼마나 저렴한 지) 이해하지 못합니다.

   • “커밋은 특정 작업에 해당해야한다고 생각합니다.”종종 작업은 시각 관리의 작업 보드에서와 같이 하루에 수행해야하는 작업에 해당합니다. 이는 우연의 일치가 아닙니다. 그런 다음 백 로그 작업 (2 ~ 8 시간 작업)과 논리적으로 격리 된 변경 사항 (몇 초에서 몇 시간) 사이에 차이를 만드는 방법을 배워야합니다. 이것은 포인트 5 와도 관련이 있습니다.

7. 팀이 커밋을 더 자주하지 않는 이유를 검색하십시오. 결과에 놀라실 수 있습니다.

   최근에 나는 커밋 속도가 중요하다는 다른 대답 을 언급 했으며 심지어 수백 밀리 초조차도 개발자가 덜 자주 커밋 할 수 있습니다.

   다른 이유는 다음과 같습니다.

   • 커밋 메시지를 작성하는 지나치게 복잡한 규칙.

   • 개발자가 커밋을 버그 추적 시스템의 작업에 연결하도록하는 규칙입니다.

   • 빌드를 깨뜨리는 것에 대한 두려움.

   • 지금 당장 빌드를 무너 뜨릴 위험을 감수하려는 의지 : 금요일 저녁에 떠나기 직전에 커밋을하면 월요일까지 깨진 빌드를 처리 할 수 ​​있습니다.

   • 합병에 대한 두려움.

8. 개발자 가 자주 저지르면 다른 이점 이 있다는 것을 이해하는지 판단하십시오 . 예를 들어, Continuous Integration 플랫폼은 회귀가 도입 된 위치 를 정확하게 찾아 낼 수 있기 때문에 커밋을 자주하는 데 큰 도움이됩니다 .

   CI 플랫폼을 선호합니다. 수십 개의 파일에 걸쳐있는 변경으로 구성된 개정판 5023이 아니라 15 분 전에 한 파일에서 두 가지 방법으로 변경 한 것으로 구성된 개정판 5023에서 빌드를 중단했다고 말합니다. 13 시간의 노동.

내가 과거에 계약 한 조직은이 같은 문제를 해결하고 싶었고 상당히 훌륭한 소셜 솔루션을 개발했습니다. 개발자는 자신의 컴퓨터를 가지고 있지 않습니다. 개발 TEAM에는 컴퓨터가 있지만 모든 개인에게 특정 날짜에 모든 개발 컴퓨터에서 작업하도록 요청할 수 있습니다. 따라서 체크인은 어제 수행 한 작업을 계속 수행 할 수있는 유일한 방법입니다!

그런 다음 경영진은 몇 시간 후에 컴퓨터의 변경 사항을 되돌려 되돌려 서 체크인하지 않은 항목을 잃어 버렸습니다. 이러한 "시뮬레이션 된 컴퓨터 오류"는 개발자가 탑승하기 전에 몇 번만 발생해야했습니다.

물론 규칙의 "이유"와 "무엇"을 설명하는 것이 중요합니다. "이유"가 명확하지 않으면 소스를 USB 드라이브 나 다른 곳에 저장할 수 있습니다.