매일 코드를 커밋 / 체크하는 것이 좋은 습관입니까?

나는 Continuous Integration 에 대한 Martin Fowler의 메모를 읽었으며 필자는 "모든 사람이 매일 메인 라인에 커밋"해야한다고 언급했다.

작업중 인 섹션이 완료되지 않고 실제로 3 일마다 코드를 커밋하지 않는 한 코드를 커밋하는 것을 좋아하지 않습니다 : 하루는 작업을 조사 / 재생하고 예비 변경을 수행하고 하루는 변경을 완료하기 위해 하루를 변경합니다 시험을 작성하고 제출을 위해 정리 ^ 코드를 빨리 제출하는 것이 편하지 않습니다.

이제 저장소에서 변경 사항을 가져 와서 일반적으로 하루에 두 번 로컬로 통합하지만 더 작은 작업을 수행 할 수 없다면 자주 커밋하지 않습니다.

질문 : 매일 워크 플로우를 변경하여 수용 해야하는 좋은 습관을 실천하고 있습니까?

편집 : 나는 이것이 CVS 의미에서 "커밋"(일명 "푸시")을 의미한다고 분명히 말했을 것입니다. 왜냐하면 Fowler가 이것을 쓸 때 2006 년 Fowler가 의미했을 것입니다.

^ 순서는 더 임의적이며 작업에 달려 있습니다. 요점은 정확한 순서가 아니라 시간 범위와 활동을 설명하는 것이 었습니다.

이 규칙에 동의하지 않으며 Mason Wheeler의 말에 동의합니다 . 몇 가지 아이디어를 추가하고 싶습니다.

나는 커밋 할 의미있는 변화가있을 때마다 커밋하려고합니다. 몇 가지 작은 버그를 수정하면 하루에 여러 번, 나머지는 사용할 수없는 더 큰 소프트웨어를 작업하는 경우 일주일에 한 번이 될 수 있습니다 코드가 일관된 상태에 도달 할 때까지 의미있는 방식으로 코드를 작성합니다.

또한, 나는 해석 투입 으로 의미있는 개정 게시 코드베이스에 새로운 기능을 기여하고있다. 다른 개발자가 개정 내역을 볼 때 변경의 의미와 목적을 이해할 수 있도록 커밋하기 전에 코드를 정리해야한다고 생각합니다. 다른 개발자가 기록에서 볼 수있는 변경 사항이 적을수록 좋습니다. 개정 기록을 볼 때 의미있는 기능을 추가하는 증분을보고 싶습니다. 나는 각 개발자가 솔루션에 도달하기 전에 시도해보고 싶었던 작은 아이디어에 관심이 없습니다.

또한 SVN 서버 (또는 모든 버전 제어 시스템)를 코드의 현재 스냅 샷이 커밋 된 (컴파일 된 경우) 백업 기능으로 사용하는 것이 좋지 않다고 생각합니다 .USB 스틱을 사용할 수 있습니다 또는 컴퓨터가 고장날 때 코드가 손실되지 않도록 현재 코드를 미러링하는 외부 USB 드라이브 또는 네트워크 디스크. 개정 관리와 데이터 백업은 서로 다른 두 가지입니다. 개정판을 게시하는 것은 코드 의 스냅 샷 을 저장하는 것과 다릅니다 .

마지막으로, 나는 때때로 커밋하는 것이 문제가 아니라고 생각합니다 (즉, 코드의 현재 상태에 실제로 만족할 때만) 그리고 병합 충돌을 피하는 것은 종종 커밋에 대한 좋은 정당화가 아닙니다. 여러 사람이 같은 파일에서 동시에 작업 할 때 많은 병합 충돌이 발생하며 이는 나쁜 습관입니다 (예 : 이 기사 , 포인트 7 참조). 프로젝트를 명확한 인터페이스와 가능한 적은 종속성을 가진 모듈로 분할하고 개발자의 작업을 조정하여 작업 코드가 가능한 한 겹치도록하여 병합 충돌을 줄여야합니다.

그냥 내 2 센트.

편집하다

조기 커밋에 반대하는 또 다른 이유는 (매우) 버기 버전을 테스트 할 수 없기 때문입니다. 트렁크에서 커밋하고 테스트 팀이 매일 테스트하는 경우 몇 시간 동안 (또는 하루 동안) 테스트 가능한 버전이 없을 수 있습니다. 버그를 수정하지 않고 변경 사항을 되돌리려 고해도 다시 작성하는 데 몇 시간이 걸릴 수 있습니다. 예를 들어, 5 명의 테스터가 팀에서 일하는 동안 비 활동으로 인해 팀 시간의 5 x 2 = 10 시간을 낭비했습니다. 그것은 한 번 일어 났으므로 가능한 빨리 커밋 이름으로 조기 커밋을 피하려고 합니다 .

나는 하루에 여러 번 코드를 커밋합니다 . 코드가 컴파일하기에 충분하고 다른 것을 깨뜨리지 않는 지점에 도달 할 때마다 코드가 들어갑니다.

하루에 몇 번 안전하게 체크인 할 수 있도록 작업을 해체해야합니다 .

이에 대한 근거는 두 가지입니다.

1. 체크인되지 않은 작업은 손실 될 수 있습니다. 컴퓨터에 치명적인 오류가있을 수 있습니다. 이 경우 기다릴수록 더 많은 작업을 잃게됩니다.
2. 체크인하지 않고 더 많은 작업을할수록, 최종적으로 베이킹을 결정할 때 다른 사람들이 더 많은 코드를 통합해야합니다. 이로 인해 충돌 및 병합 문제가 발생할 가능성이 높아집니다.

그 뒤에 이유를 이해하지 않고 방법론이나 연습을 노골적으로 준수하는 것은 좋은 생각이 아닙니다. 화물 컬트 프로그래밍이 시작되는 곳입니다.

따라서 "마틴 파울러가 그렇게 말했기 때문에 매일 커밋해야합니다"는 바보입니다. 때로는 비현실적이기도합니다. 복잡한 새 기능을 사용중인 경우 이미 며칠 동안 작업을 수행 할 때까지 체크인 할 가치가없는 시점에 도달하지 못할 수 있습니다.

그렇다고 체크인하기 전에 모든 것이 완벽해야한다는 의미는 아닙니다. 문제가 생길 경우 작업을 잃을 수있는 좋은 방법입니다. 올바른 행동은 문제에 대한 올바른 판단을 개발하고 사용하는 것입니다. 경험 법칙은 당신에게 많은 도움이 될 수 있습니다.

Oded는 가능한 한 자주 코드를 커밋해야하는 두 가지 중요한 이유를 제시했습니다. 몇 가지 더 추가하겠습니다 :

1. 코드에서 작업하는 동안 다른 코드에서 해당 기능이 필요할 수 있습니다. 그들은 그것을 얻기 위해 6 일을 기다려서는 안됩니다. 이 경우 내 동료는 일반적으로 코드에서 프로토 타입을 만들어 커밋하고 본문을 추가 한 후 다시 커밋합니다. 그리고 이것은 보통 몇 시간 안에 이루어집니다.

2. '공통'코드는 모든 사람이 가능한 한 빨리 모든 변경 사항을 볼 수 있도록합니다. 작업중 인 코드가 다른 사람의 작업과 완전히 분리되어 기다릴 필요가 없다면 작업 할 분기를 만든 다음 모든 것이 성공하면 병합하십시오. 메인 라인.

나는 가치가있는 모든 논리적 변화를 저지르는 것을 믿는 신자입니다. 자주 커밋하고 코드를 유지할 가치가 없으면 깨끗한 상태로 되돌립니다. 코드를 푸시 / 게시하기 위해 대기하는 시간이 길수록 구현하기가 더 어려워지고 더 많은 문제가 발생합니다. 또한 기여에 대한 피드백을 훨씬 빠르게 얻을 수 있습니다.

• 그들은 빌드를 깰까요?
• 다른 팀원의 노력을 복제하고 있습니까?
• 뭔가 잘못하고 있습니까?
• 아니면 사람들이 당신에게서 물건을 기다리고 있습니까?

작은 변경은 관리하기가 훨씬 쉽습니다.

또한 다른 버전 제어 시스템의 차이점을 주목할 가치가 있습니다. Git (분산)과 같은 일부는 전체 히스토리를 로컬로 커미트하고 제어 할 수 있으며 공개 할 준비가되었을 때만 푸시 할 수 있습니다. SVN (중앙 집중식)과 같은 다른 것들은 두 가지 단계를 결합하여 작은 커밋을 매우 비효율적으로 만듭니다.

커밋은 본질적으로 변경 문서임을 잊지 마십시오. 일이 잘못되면 충분하지 않은 것보다 더 많은 역사를 갖게되어 기쁠 것입니다. 일주일 동안 한 번의 커밋은 쓸모없는 것 같습니다. 방금 각 논리적 청크의 요약이 아니라 변경된 모든 단일 코드 줄을 읽었습니다.

나는 여기서 대부분의 답변이 Martin Fowlers 성명서의 주요 요점 중 하나를 놓친 것 같습니다. 이것은 지속적인 통합 과 관련이 있습니다. 메인 라인에 체크인 (푸시 / 게시 / 병합)되지 않은 코드는 테스트되지 않습니다.

이것은 사무실을 떠날 때마다 로컬 컴퓨터에있는 코드를 커밋하기위한 격려로 읽혀서는 안됩니다. 여기서 다른 사람들이 지적한 것처럼 나쁜 것은 빌드를 중단하고 메인 라인을 불안정하게 만듭니다.

그러나 문제를 일으키지 않고 메인 라인에 체크인 할 수있는 작은 단계로 변경을 시도하는 것이 좋습니다. 이를 통해 코드를 분리하여 다시 작성하는 대신 코드의 진화를 권장합니다.

자, 이런 방식으로 좋은 점은 무엇입니까?

1. 큰 코드 덩어리 또는 혁신적인 변경 사항을 커밋하지 않으면 빌드가 중단 될 가능성이 줄어 듭니다.
2. 커밋이 빌드를 중단하면 문제가 무엇인지 식별하고 되 돌린 다음 고정 버전을 빠르게 커밋하는 것이 매우 간단합니다.
3. 코드의 작은 변화마다 모든 테스트가 실행되도록함으로써 지속적인 통합 체계 외부에서 코드가 커지면서 발생할 수있는 미묘한 버그 나 회귀가 발생하지 않도록합니다.

물론 모든 변경이이 접근법에 적합하지는 않습니다. 다른 사람들이 지적했듯이 절대적인 규칙은 없습니다. 그러나 오랫동안 메인 라인에서 벗어날 것으로 예상되는 변경의 경우 자체의 지속적인 통합 체계를 사용하여 대체 메인 라인을 설정하고 동일한 방식으로 변경하십시오. 오늘날의 분산 VCS를 사용하면 매우 쉽습니다.

매일 체크인 인수 :

• 하드 드라이브 오류에 대비하여 코드가 저장되고 백업됩니다
• 커밋 노트에 활동을 기록 할 수 있습니다 ( 목요일에 내가 한 일은 ...? )
• 기존 코드베이스와의 통합은 초기 및 더 작은 청크에서 발생하므로 충돌을 조기에 식별하거나 문제를 빨리 병합 할 수 있습니다
• 팀은 작업 한 내용을 파악할 수 있습니다
• 동료는 인터페이스에 대해 더 빨리 작업 할 수 있으므로 '복잡한 코드 비트'와 통합 할 시간이 더 많아집니다.
• 코드는 실제 테스트보다 더 빨리 테스트되거나 최소한 더 많은 사용량에 노출되어 버그 나 누락을 조기에 식별 할 수 있습니다.

매일 체크인에 대한 논쟁 :

• 필요하지 않거나 원하지 않는다
• 아직 내 코드를 '정리'하지 않았지만 엉망입니다.
• 시간이 없어

게으름이나 무질서와는 별도로 매일 체크인해야 할 이유가 없다고 생각합니다. 누군가가 아직 완료하지 않아서 체크인하지 않았기 때문에 개발 환경에서 실행되는 코드가 개발 브랜치의 코드와 일치하지 않는 것을 보는 것보다 더 나쁜 것은 없습니다.

이 문제에 대해 잘못 알고 싶습니다. 매일 체크인에 대한 합법적 인 주장을 알려주십시오.

"커밋"을 "메인 라인으로 병합"으로 의미하는 경우 고객에게 공개되는 소프트웨어 프로젝트에서 매일 그렇게하지 않아야합니다. 메인 라인이 항상 작동하고 해제 가능하며 절반이 완성 된 기능으로 일부 중단 된 상태가 아닌 변경 사항을 병합하고 수행해야합니다.

그러나 오늘날의 분산 버전 제어 기능을 사용하면 사선을 안정적 git/hg/whatever commit으로 유지하면서 동시에 상태를 유지하려는 느낌이들 때마다 작업을 수행 할 수 있습니다 . 나는 몇 시간마다 한 번씩 그리고 확실히 매일 끝납니다.

DVCS를 사용하면 작업을 게시하고 팀의 다른 사람들과 공동 작업하고 기본 지점의 변경 내용을 최신 상태로 유지할 수 있습니다. 고객 및 / 또는 다른 팀이 의존하는 코드의 안정성을 오염시키지 않고이 모든 작업을 수행 할 수 있습니다.

Subversion이 최신 기술이었으며 극도의 고통없이 기능 분기를 분기 및 병합 할 수 없었던시기에 여러 가지 기능이 동시에 구축 된 메인 라인을 사용하는 것이 가장 좋은 방법이었습니다. 그러나이 우월성은 2010 년을 넘어 확장되지 않습니다.

Team Foundation Server에서는 체크인과 동일하지 않은 'Shelve'를 수행 할 수 있지만 컴퓨터가 죽더라도 변경 사항을 잃지 않도록 코드를 백업합니다.

또한 '개발자 라인'과 '메인 라인'이있는 소프트웨어 하우스도 보았습니다. 개발자는 적합하다고 생각 될 때마다 개발자 라인에 자유롭게 체크인 할 수 있으며 팀 리더 만 메인 라인에 액세스 할 수 있으므로 프로덕션 준비가 완료되면 개발자에서 메인으로 코드를 복사 할 책임이 있습니다.