답변:
내가하는 습관에서 얻은 한 가지는 항상 체크인하기 전에 체크인하려는 모든 파일의 차이점을 보는 것입니다.
주석 처리 된 코드를 체크인해서는 안됩니다. 체크인 전에 주석 처리해야하는 코드가있는 경우 잘못된 코드입니다.
규칙에 관해서는 :
짓다
3.1 빌드 오류 수정
테스트 실행
4.1 고장난 테스트 수정
1로 가십시오 (얻을 새로운 것이 없을 때까지)
모든 단계가 완료된 경우에만 체크인하십시오.
다른 모범 사례 :
rebase -i로컬 히스토리를 정리하고 필요에 따라 커밋을 스쿼시 할 수 있으므로 메인 라인에 추악한 작업 진행 커밋이 없습니다.
내가 너무 여기에 pantsweasel의 되려고 노력하고 있지 않다,하지만이 질문에 가정 (모든하지만 대답 중 하나) 대부분 같은 TFS, SVN, 억지로, 등 중앙 집중식 VCS에 적용
페어 충분히, 그것은 무엇을의 OP가 사용 중입니다.
그러나 DVCS (예 : Mercurial 및 Git)를 사용하는 경우 일반적으로 체크인 대기하지 않아야하며, diff, 최신 정보, 병합 등과 같은 답변에 언급 된 대부분의 항목은 필요하지 않습니다. . 코드 검토 및 테스트와 같은 것조차 체크인 후 수행하는 것이 좋습니다 (아마도 푸시하기 전에 ...)
지금까지 본 예외는 작업 항목과 관련이 있습니다. 물론 체크인에 대한 의견도 좋습니다 ...
다른 답변에서 보지 못한 세 가지 :
새 파일 포함
변경되지 않은 파일 되돌리기
제출 한 커밋 확인
Git을 사용할 때 두 가지 :
원자 커밋 :
git add --patch필요한 경우 여러 부분으로 내 변화를 분할 할 수 있습니다.요약하는 동안 차이점보기
git commit --verbose커밋 메시지를 입력하는 동안 항상 변경 사항을 확인할 수 있도록 항상 체크인 합니다. (또는 패치 된 git-vim 을 사용하여 diff를 표시합니다.)팀 서버에 적용하는 '좋은 습관'몇 가지 항목은 매우 간단합니다. 먼저, 체크인하기 전에 항상 코드를 충돌시킬 수있는 다른 사람을 확인하지 않도록 항상 최신 상태를 유지하고 로컬 빌드를 실행해야합니다. 또한 서버가 아닌 로컬 컴퓨터의 코드 충돌을 처리하십시오. 최신 코드가 다운로드 된 코드가 빌드되고 제대로 작동하는 것으로 확인되면 다음 단계를 수행 할 수 있습니다. 자동화 된 테스트를 실행 한 다음 체크인을 시작하여 여전히 제대로 작동하는지 확인하십시오. 그런 다음 확실하게 최신 정보를 다시 받으십시오.
TFS 관리자는 모든 체크인에 대해 주석을 달 수 있습니다. 작업 여부에 관계없이 항상 귀하의 작업에 대한 체크인 의견을 작성하는 것이 좋습니다. 그렇게 할 수있는 옵션이 있다면 시행하십시오. 주석은 최소한 코드를 마지막으로 체크인 한 이후 변경 한 내용에 대한 일반적인 요약이어야합니다. 이렇게하면 문제가 발생하면 체크인을 살펴보고 대략적인 내용을 확인할 수 있습니다. 체크인시 변경되었습니다. 깨진 빌드를 훨씬 쉽게 디버깅 할 수 있습니다.
또한 TFS 관리자 권한이있는 경우 체크인시 롤링 빌드를 시행하고 (체크인이 문제를 겪는 경우 다른 사람이 즉시 알 수 있도록) 게이트 된 체크인을 수행하도록 서버를 설정할 수 있습니다 ( 체크인 된 코드가 빌드를 중단하면 서버가 거부합니다) 또는 단순히 버그를 생성하여 빌드를 위반 한 사람에게 할당하도록 할 수 있습니다.
모든 것을 제대로 유지하기 위해 켜거나 끌 수있는 몇 가지 다른 옵션이 있으며, TFS 관리자에게 설정하여 물건을 깨끗하고 깨끗하게 유지하도록 제안 할 수 있습니다.
Windows에서 체크인하는 경우 코드에 보이지 않는 ^ M 문자가 없는지 확인하십시오 .UNIX의 편집기는 종종 오류 / 경고를 유발합니다.
또한 탭을 시도하고 교체하십시오. 다른 사용자는 4 개의 공백이있는 탭 스탑을 다르게 보게 될 것이며 8은 코드 가독성에 좋지 않습니다.
최선의 방법 IMHO는 미리 정의 된 스크립트로 조직의 코딩 지침에 따라 코드를 확인하도록하는 것입니다. 많은 소스 제어 시스템에이 기능이 있습니다.
가능하면 체크인을 작업 항목과 연결하고 싶습니다. 이를 통해 변경된 내용뿐만 아니라 변경된 이유에 대한 컨텍스트 정보를 얻을 수 있습니다. TFS에는 상당히 괜찮은 작업 항목 추적 시스템이 있으므로 체크인시 수행하기가 쉽지 않습니다.
(이것은 내 변경 사항의 차이점을 검토하는 것 외에도)
여기에 모든 답변을 결합하고 완전한 체크리스트를 제공하려면
[체크인 / 체크 아웃] 다른 사람이 작업중인 스트림에 직접 체크인해서는 안됩니다. 스트림 전략이 있어야합니다. 예를 들어 개발자마다 다른 사람을 방해하지 않고 독립적으로 체크인 및 체크 아웃 할 수있는 스트림 : 작업은 안전하지만 자신의 개발 흐름에 따라 [자신의 개발 흐름에서만]. 체크인 할 때마다 변경 레코드와 변경 레코드를 연결하여 변경 세트라는 변경에 대해 변경 사항을 원자화합니다 (따라서 '모든 것'을 전달하지 않고도 개별 rfc / 버그 등을 배포 할 수 있습니다).
[그러면 팀 스트림으로 리베이스] 자신의 스트림에서 다른 사람들로부터 변경 사항을 얻음을 의미합니다. 이 작업을 수행하는 동안 병합 대화 상자에서 모든 "diffs"를 볼 수 있습니다. 또는 수천 개가 있거나 코드를 사용하지 않고 데이터 모델 / siebel 프로젝트 등을 사용하는 경우 ... 사소하지 않은 병합, 사소한 자동 및 사소한 수동 병합, 마지막 범주에는 어려운 항목이 포함됩니다. 여전히 자신의 스트림에서 작업하고 있음을 기억하십시오.
[완전히 리베이스] 모든 것이 정상이라면, 팀 스트림에서 방금 변경 한 모든 사항을 확인하십시오. 자신의 스트림이 최신입니다.
[배달]은 이제 팀 스트림으로 작업을 전달합니다. 모든 것을 제공하고 싶지 않다면 특정 버전의 파일 또는 해결 된 RFC / 결함 세트가 포함 된 1 개의 특정 RFC를 선택할 수도 있습니다.
[테스트 제공] 괜찮아 져야하지만 그 동안 누군가가 변경 사항을 전달했을 가능성이 있으므로 팀 스트림의 최신 변경 사항으로 작업이 작동하는지 테스트 할 수 있습니다. 차이점을 보여주는 동일한 병합 대화 상자가 있습니다.
[전달 완료] 전달 완료 및 작업이 이제 팀 스트림에 있습니다.
더 복잡하게 만들려면 : 여전히 제공 한 작업 = ok 일 가능성이 여전히 있지만 이미 다른 버전에서 작업하는 경우 제공 한 후에 항상 기준을 설정하고 다른 사용자가 재베이스를 선호하는 기준을 지정해야합니다. . 따라서 다른 개발자가 스트림의 최신 버전이 아닌 권장 버전을 얻을 수 있습니다 (해당 시나리오에서 작업중인 경우). 또한 팀 스트림의 최신 버전이 "나쁜"경우에도 다른 사용자가 기반을두고 있거나보고있는 버전이 아니며 구성 관리자가 이전 버전을 다음 버전으로 병합하여 실행 취소 할 수있는 트리플 확인도 수행합니다. 당신의 배달.
귀하의 예에서 코드 주석 처리를 잊어 버렸습니다. 실수가 발생합니다. 주변의 구성 관리 시스템이이를 관리해야합니다. 예를 들어 수천 개의 변경 사항이 발생하고 "빌드"및 "통합"이 시간에 따라 연결되고 처리 된 다른 서버의 스트림 계층 구조에서 발생하는 것일 수 있습니다. 따라서 5 개월이 지난 후에도 코드가 다른 코드 및 시스템과 통합되어야하므로 주석 처리 된 코드가 통합 서버에서 테스트 된 경우에도 변경 세트를 원자 적으로 제거하여 계속 수행 할 수 있습니다. 따라서 모범 사례는 다소 높은 수준입니다. 구성 관리 스트림의 전체 디자인이이를 관리해야합니다. 개별 개발자의 경우 모범 사례는 물론 검증 / 단위 테스트입니다. 그러나 큰 그림에서 "
다음 중 일부는 SCM에 따라 다른 것보다 더 많이 적용되거나 다른 형태로 적용되므로 여기에 해당됩니다.
참고 : 위의 항목 중 일부는 다소 분명해 보이지만 실제로 얼마나 많은 사람들이 실제로 주요 지점에서 작업하거나 생산을 변경 한 다음 수동으로 델타를 만들어 버전 제어를 직접 수행합니다. .. 및 레이블이 있습니다. 발효되지 않은 담즙처럼 달지 않은 겨드랑이 주스와 섞여서 ...
개인 점검 목록을 작성하십시오. 항목을 엉망으로 만들 때 비워 두십시오. 그것이 두 번째 성격이되면 목록에서 제거하십시오.
테스트를 실행하십시오. 그들이 통과하면 그것을 체크인하십시오. 당신이 엉망이고 어떤 것이 테스트를 통과하면 테스트를 작성하십시오.
우리는 다음을 수행합니다 ...
테스트-우리는 그것이 작동하는지 확인하고 싶습니다. 최소한 아무것도 깨지지 않는 것을 알고 싶습니다.
코드 검토 또는 최소한 친구 확인-지식이 널리 퍼지고 사람들이 최신 상태를 유지하도록하는 좋은 방법입니다. 또한 체크인하기 전에 버그를 잡는 데 도움이됩니다.
사전 통지 보내기-체크인 전에 사전 통지가 그룹으로 전송됩니다. 목적은 변경중인 파일 또는 영역을 다른 사람에게 알리는 것뿐만 아니라 변경 사항이 영향을 줄 것으로 예상되는 경우에 대비하여 미리 통지하도록해야합니다.
사전 통지를 보낸 후 몇 시간이 지나면 체크인이 수행되고 그룹에 이메일을 통해 알려줍니다. 그룹의 모든 사람은 버그 나 기능에 대한 특정 작업이 언제 완료되는지 알 수 있습니다.
체크인 통지의 사본은 버그 또는 기능과 연관된 수정 사항 레코드에 붙여 넣습니다. 레코드를 검색 할 때 수정 / 기능이 수반 된 내용을 이해하는 것이 매우 편리하다는 것을 알았습니다.
독립형 장치로 들어갈 수있는 변경 부분을 찾으십시오.
종종 코드를 수정하거나 개선 할 때까지 몇 가지 변경 사항이 있습니다. 그들 중 일부는 내가하려는 행동 변화에 따라 다릅니다. 다른 사람들은 내가 그 변화를 더 깨끗하게하기 위해 한 리팩토링입니다.
다음과 같이 자체 변경 설명을 사용하여 각 리팩토링을 개별적으로 확인하는 것이 좋습니다.
참고 : X의 이름을 Y로 바꿉니다.
X는 이전에 의미가 있었지만 이제는 Y 여야합니다. 이것은 문제 # 9의 작업과 관련이 있습니다.
그런 다음 각각의 좋은 리팩토링이 체크인되면 최종 동작 변경이 사소한 경우가 많습니다.
또한 일부 변경 사항은 많은 코드 줄에 영향을 주지만 그다지 흥미롭지는 않지만 다른 변경 사항은 현지화되었지만 중요한 영향을 미칩니다. 이러한 변경 사항을 함께 체크인하면 diff를 읽기가 어려울 수 있습니다. 그래서 나는 그것들을 따로 보관합니다.
나중에 누군가가 변화의 역사를 읽었을 때, 현재 상황에 어떻게 도달했는지, 왜 이런 방식인지는 분명합니다. 내 행동 변경 사항을 취소하는 것은 사소한 일입니다. 왜냐하면 수많은 다른 수정 사항과 얽매이지 않기 때문입니다.
빌린 물건을 다른 사람에게서 반환 할 때해야 할 일을하십시오. 깨끗하고 양호한 상태인지 확인하십시오. 엉망인 경우 코드를 소유자 (대부분의 경우 고용주)에게 반환하기 전에 청소해야합니다.