작동하지 않는 코드를 커밋해도 괜찮습니까?

작동하는 코드 만 커밋해야합니까?

이 커밋은 다음과 같이 저장소를 작동 상태로 둘 필요가 없습니다.

• ... 우리는 초기 설계 단계에 있으며 코드는 아직 안정적이지 않습니다.
• ... 당신은 프로젝트의 유일한 개발자입니다. 왜 작동하지 않는지 알고 있습니다. 또한 깨진 코드를 커밋하여 다른 사람의 작업을 중단하지 않습니다.
• ... 현재 코드가 작동하지 않습니다. 우리는 그것에 큰 변화를 만들 것입니다. 상황이 나빠질 경우 되돌릴 수 있도록 노력하겠습니다.

• ... 로컬 브랜치에 깨진 코드가 있으면 체인이 길고 아무런 문제가 없습니다. 즉

  1. 로컬 파일
  2. 준비 영역
  3. 지역 지점에서 커밋
  4. 원격 개인 기능 지점에서 커밋
  5. 원격 develop지점 과 병합
  6. 원격 master지점 과 병합
  7. 원격 release지점 과 병합

• 일찍 커밋하고 자주 커밋하십시오.

따라서 위의 질문에서 대부분의 답변은 컴파일 할 수없는 코드를 커밋하는 것이 로컬 및 기능 분기에서 문제가되지 않는다고 말합니다. 왜? 깨진 커밋의 가치는 무엇입니까?

추가됨 : 투표권이 높은 몇 가지 의견이 있습니다. 그러나 질문의 ​​기술적 측면에는 관심이 없습니다. 오히려 업계에서 수년간 일한 사람들이 가장 생산적인 습관을 습득하는 모범 사례를 배우고 싶습니다.

나는 엄청난 양의 훌륭한 답변에 놀랐습니다! 그들은 코드를 구성하기 위해 분기 를 사용하는 데 충분하지 않다는 결론을 이끌어냅니다 .

브랜치 철학 중 하나 ( 고급 SCM 브랜칭 전략의 브랜칭 전략 및 코드 라인 정책 개발 섹션 -또한 Perforce Best Practices ( pdf)이지만 다른 세부 사항도 참조)는 비 호환 정책을 브랜치하는 것입니다.

코드 라인 정책은 코드 라인에 대한 공정한 사용 및 허용 체크인을 지정하며 코드 라인 SCM의 필수 사용자 매뉴얼입니다. 예를 들어, 개발 코드 라인의 정책은 릴리스 용이 아니라고 명시해야합니다. 마찬가지로 릴리스 코드 라인의 정책은 승인 된 버그 수정으로 변경을 제한해야합니다. 이 정책은 또한 체크인되는 변경 사항, 필요한 검토, 필요한 테스트 및 체크인 후 코드 라인 안정성에 대한 기대치를 문서화하는 방법을 설명 할 수 있습니다. 정책은 문서화되고 시행 가능한 소프트웨어 개발 프로세스를위한 중요한 구성 요소이며 SCM 관점에서 정책이없는 코드 라인은 통제 할 수 없습니다.

(Perforce 모범 사례에서)

릴리스가 빌드되는 분기 '릴리스'(또는 '마스터')와 개발자가 작업 코드를 체크인하는 '트렁크'(또는 'dev')가 있다고 가정하십시오. 이들은 지점의 정책입니다. '작업 코드'를 주목하는 것은 'dev'브랜치 정책의 일부이므로 깨진 브랜치를 dev 브랜치에 커밋해서는 안됩니다. 종종 이러한 분기에 연결된 CI 서버와 같은 것들이 있으며 깨진 코드를 dev에 체크인하면 모든 분기를 망칠 수 있고 빌드가 깨질 수 있습니다.

그러나 작동하지 않는 부분 코드를 체크인하는 것이 적절한 경우가 있습니다. 이 경우 트렁크와 호환되지 않는 정책을 분기해야합니다. 이 새로운 브랜치에서 정책을 결정하고 ( '깨진 코드는 정상입니다') 코드를 커밋 할 수 있습니다.

코드 라인을 분기해야하는지 여부를 결정하는 간단한 규칙이 하나 있습니다. 사용자가 다른 체크인 정책을 필요로하는 경우 분기되어야합니다. 예를 들어, 제품 릴리스 그룹에는 엄격한 테스트를 시행하는 체크인 정책이 필요할 수있는 반면, 개발 팀은 부분적으로 테스트 된 변경 사항을 자주 체크인 할 수있는 정책이 필요할 수 있습니다. 이 정책 차이는 코드 라인 브랜치를 요구합니다. 한 개발 그룹이 다른 개발 그룹을보고 싶지 않은 경우

(Perforce 모범 사례에서)

강력한 기업 마인드를 갖춘 중앙 서버 기반 SCM에서 발생한다는 사실을 인식하십시오. 핵심 아이디어는 여전히 좋습니다. 이것들은 종종 암시 적으로 생각됩니다-당신은 릴리스 브랜치에 테스트되지 않은 dev 코드를 체크인하지 않습니다. 그게 정책입니다.

따라서 브랜치는이 브랜치가 코드를 깨뜨려 커밋 할 수 있다고 말합니다.

Linus Torvalds가 제안한 철학 중 하나는 창의적인 프로그래밍이 일련의 실험과 같아야한다는 것입니다. 당신은 아이디어가 있고 그것을 따르십시오. 항상 효과가있는 것은 아니지만 최소한 시도해 보았습니다. 개발자가 창의적인 아이디어를 시도하도록 장려하고이를 수행하려면 실험을 수행하는 것이 저렴하고 복구가 저렴해야합니다. 이것은 git commit이 너무 저렴하고 빠르다는 진정한 힘입니다. 이 창의적인 패러다임을 열어 개발자가 그렇지 않은 것을 시도 할 수있게합니다. 이것은 자식의 해방입니다.

예, 릴리스 브랜치가 아닌 한 가능합니다.

개인 지점에서는 실험이 실패하면 모든 것이 사라지고 버릴 수 있습니다. 이것이 DVCS의 주요 이점 중 하나입니다. 자유

깨진 코드를 커밋하는 것의 가치 : 협업 및 실험

예, 괜찮습니다. 제가 많이하는 일입니다.

컴파일 할 수없는 코드를 커밋하는 요점은 (최소한 지점에서) 때로는 코드가 진행중인 작업이지만 지금까지 수행 한 작업은 다른 사람과 저장하거나 공유 할 가치가 있다는 것입니다

나의 연습은 :

• 테스트를 먼저 작성하십시오
• wip (진행중인 작업) 커밋이 양호
• 자주 (하루에 여러 번) 커밋 ( '작업'단계 저장)
• 모든 커밋 후에 푸시하십시오 (하드 드라이브가 충돌하거나 버스가 충돌하는 경우).
• 항상 가지에서 먼저 작동
• 가능하면 작업 코드에서 마스터로만 병합
• 마스터 병합 전에 wish를 스쿼시하기 위해 git의 대화식 리베이스

주요 문제 및 아마도 당신이 만지고있는 것은 기본적으로 작동하고 비즈니스에서 필요로하는 기능이 있고 (따라서 '마스터'에 있어야 함) 일부 테스트가 실패하는 경우입니다. 여기서 한 가지 옵션은 현재 진행중인 테스트를 보류하는 것입니다. 그러나 이것은 테스트가 절대로 고쳐지지 않을 수 있기 때문에 위험에 처해 있으며, 다른 영역에서는 단순히 테스트를 수정하지 않고 '보류'하는 패턴을 설정할 수 있습니다.

또 다른 옵션은 지점을 일시적으로 사용하고 배포하는 것입니다. 이는 특정 상황에서 도움이 될 수 있지만 일반적으로 권장되지 않으며 지속 가능하지 않습니다.

아마도 가장 좋은 방법은 기본적으로 소프트웨어 개발에보다 전문적인 접근 방식을 취하고 커밋 된 코드에 대한 실제 테스트를 요구하는 것입니다. 이것은 종종 많은 사람들이 상상하는 코딩이 아니라 소프트웨어 개발의 '열심 한'부분입니다. 더 나은 접근 방법은 애자일 개발 중에 더 나은 초기 추정, 자원 할당, 우선 순위 설정 등을 요구할 것입니다. 또한 충분한 시간과 충분한 훈련을 통해 문제가 발생할 때와 손질 세션 동안 문제를 해결할 수 있습니다.

'완료'의 의미에 초점을 맞추십시오. 이는 코드와 테스트가 작성되고 리팩토링되어 작동한다는 것을 의미합니다. "주로 완료, 테스트 작성 / 수정 / 리팩터링"과 같은 주석이 들리면 완료되지 않습니다. 기술적으로 완전하지 않은 상태에서 기능을 수행한다고 말하는 것은 주니어 프로그래머에게 가장 흔한 실수 중 하나입니다.

커밋 여부에 관계없이 커밋 값은 코드가 서버에 커밋된다는 것입니다. 전문적인 환경에서 해당 서버는 안전하고 중복되며 실행중인 백업입니다. 하루 종일 일하면 커밋은 로컬 컴퓨터에서 발생하는 모든 코드에서 코드를 유지하는 형태입니다. 하드 디스크가 죽습니다. 노트북을 분실하거나 도난당했습니다. 건물이 타 버린 경우에도 저장소 서버의 백업을 사용할 수 있습니다.

이런 식으로 생각하십시오. 개발자로서 가장 파괴적인 일 중 하나는 팀의 다른 개발자가 작업을 수행하지 못하게하는 것입니다.

작업 코드를 커밋한다는 철학은 리포지토리의 동일한 단일 트렁크에서 작업하는 개발 팀에서 비롯됩니다. 지금은 광기로 보일지 모르지만 10 년 전에는 이것이 정상적인 작업 방식이었습니다. 안정적인 릴리스를 만들려고 할 때 브랜치가 나타나지만 새로운 기능을 구현하기 위해 브랜치에서 작업하는 개발자의 생각은 거의 들리지 않았습니다.

환경이 커밋이 다른 개발자에게 즉시 영향을 미치지 않는 경우 자주 커밋하십시오. 코드의 보안을 강화하여 코드 실수를 쉽게 롤백 할 수 있으며 많은 소스 제어 시스템이 커밋 된 코드에 대한 코드 보호 기능을 제공합니다 (모두는 아니지만).

이제 다른 개발자와 공유 한 브랜치와의 병합이 작동하는지 확인하고이 레벨로 승격하는 모든 코드가 컴파일되고 모든 단위 테스트 및 기타 팀 기반 위생 검사를 통과하는지 확인하십시오. 술집에서 맥주를 ​​계속 사세요 ...

버전 관리를 사용하는 방법에 대해 독단적으로 시작하기 전에 버전 관리를 사용하는 이유 를 고려해야합니다.

버전 제어를 커밋하면 나중에 참조 할 수 있도록 코드 상태가 고정됩니다. 차이점을보고 패치를 작성하는 것은 스냅 샷간에 코드가 어떻게 변경되었는지를 보는 것입니다. 브랜치와 태그는 스냅 샷을 구성하는 방법 일뿐입니다. 다른 개발자와 코드를 공유하면 특정 스냅 샷을 볼 수 있습니다.

언제 커밋해야합니까? 합리적인 기회가있을 경우 나중에 코드 상태 (또는 변경 사항을 설명하는 커밋 메시지)를 살펴볼 것입니다.

Git은 스냅 샷을 구성하는 방법에 대해 많은 유연성을 제공합니다. 중앙 저장소가 없으므로 상태를 '기본'저장소로 푸시하지 않고도 다른 개발자와 코드를 공유 할 수 있습니다. 브랜치를 쉽게 생성, 병합 및 삭제하여 상태 세트의 세부 정보를 기본 코드 설명과 분리 할 수 ​​있습니다. 로컬로 커밋하여 현재 개발을 따르는 것을 취소 한 다음 다른 사람이 볼 수 있도록 모든 커밋을 단일 커밋으로 일괄 처리 할 수 ​​있습니다. 나중에 쉽게 찾을 수 있도록 특정 개정판에 태그를 지정할 수 있습니다.

키스 . 소규모 프로젝트의 개발 초기 단계에서 단일 개발자에게 가장 효과적인 것은 10 년 된 미션 크리티컬 시스템에서 작업하는 백 명의 개발자가있을 때해야하는 것과 완전히 다릅니다. 모든 소프트웨어 개발 프로세스에서 누군가 다른 사람이 요청했기 때문에 불필요한 아티팩트 를 작성하지 않아야 합니다.

빌드 / 릴리스 지점

깨진 코드를 의도적으로 빌드 브랜치에 커밋해서는 안됩니다. 지속적으로 통합되고 있거나 릴리스 또는 일일 빌드를 수행하는 모든 브랜치는 항상 릴리스 가능 상태 여야합니다.

다른 지점 : 저장 상태

개인 또는 기능 지점의 경우 목표가 종종 다릅니다. 코드의 빈번한 체크인 (작동 여부에 관계없이)이 바람직 할 수 있습니다. 일반적으로 현재 상태로 되감기해야 할 때마다 커밋하려고합니다.

저장된 상태가 상당한 이점을 제공하는 다음 예를 고려하십시오.

• 전역 검색 및 바꾸기를 실행하기 직전에 커밋을 수행하여 문제가 발생할 경우 단일 작업으로 트리를 되돌릴 수 있습니다.
• 복잡한 코드 조각을 리팩터링하는 동안 일련의 임시 커밋을 수행하여 프로세스에서 무언가가 깨지는 경우 이등분하거나 되 감을 수 있습니다.
• 커밋을 수행하거나 새 브랜치를 시작하거나 언제든지 현재 작업 트리의 상태로 돌아 가면서 실험적인 것을 시도하고 싶을 때 태그를 만들 수 있습니다.

로컬에있는 한 깨진 코드베이스를 커밋해도됩니다.

왜?

• 커밋을 개발의 저장 점으로 사용하는 것이 중요합니다.
• 제품을 개발하는 동안 사용 된 사고 패턴을 보여줍니다.
• 그것은 협력을 중단하지 않습니다 .

그러나 프로그래머 팀이 있으면 프로그래밍 하우스 의 철학 이 가장 중요하며 개별 커밋 동작을 대체합니다. 일부 프로그래밍 하우스는 모든 진행 상황을 기록하기로 결정하고 다른 프로그래밍 하우스 는 기능을 해결하는 코드 만 커밋하기로 결정합니다. 이 경우, 커밋 된 커밋 의 값 ( 소프트웨어 관리 관점에서 볼 때 비용 )은 엄중합니다 :

1. 추가 기능에 사용되는 시간이 이제 오류 수정에 소비됩니다 ...
2. 개발 감축이 충족되지 않습니다 ...
3. 제품이 정시에 배송되지 않음

다른 세 가지 점이이 세 가지 요인에 영향을 미쳐 회사 붕괴에 기하 급수적으로 영향을 줄 수 있습니다.

깨진 코드를 커밋해도 괜찮다고 생각하지 않습니다.

만약에

• 긴급한 수정이 필요합니다. 코드베이스가 고장난 상태입니다. 롤백, 수정 및 배포해야합니다.

• 누군가가 깨진 코드를 커밋했는지 알지 못하는 동일한 지점에서 작업하기 시작합니다. 그들은 그들의 변화가 무언가를 깨뜨렸다 고 생각하는 '붉은 청어'를 쫓고있을 수도 있습니다.

• 회사를 떠나거나 휴가를 가거나 어떤 이유로 든 출근 할 수 없습니다. 동료들은 부서진 부분과 부서진 상태에서 커밋 된 이유를 찾기 위해 깊이 파고들 것입니다.

• 누군가 '깨진 코드'를 배포합니까? 개인 데이터 또는 지불 제공 업체와 협력하는 경우 '게임 오버'가 될 수 있습니다.

트윗 담아 가기

모든 사람들이 기능 브랜치에서 작업하는 이상적인 세상에서는 작동하지 않는 코드를 커밋하는 것이 효과적이라는 점에 동의합니다. 대규모 프로젝트를 수행 한 후에도 단일 기능 지점에서 여러 사람이 작업해야하는 경우가있었습니다. 또한 릴리스가 몇 주 떨어져서 다음 날에 수정하려고 계획했기 때문에 사람들이 메인 분기에 '작동하지 않는'코드를 커밋하는 것을 보았습니다. 이 모든 것들은 재난의 후보이며, 나는 모든 비용을 피해야한다고 믿습니다.

작동하지 않는 코드를 커밋해도 괜찮은지 확인하는 데 도움이되는 몇 가지 질문 :

1. 과로하고 있습니까?
2. 팀원이 지속적으로 빌드를 중단합니까?
3. 코드베이스가 혼란스럽고 더 나빠질 수 있습니까?

위의 내용 중 하나라도 예라고 대답하면 작동하지 않는 코드를 커밋해도됩니다.

가능한 빨리 수정하고 적용 가능한 단위 테스트로 덮고 빌드를 중단 한 것에 대해 사과하십시오.