커밋 사이에 이미 너무 오래 기다렸을 때 어떻게해야합니까?

나는 장난 꾸러기 ... 너무 많은 "카우보이 코딩", 충분하지 않은 커밋. 자, 여기에 엄청난 커밋이 있습니다. 그렇습니다, 나는 모든 것을 커밋해야했지만 지금 너무 늦었습니다.

더 나은 게 뭐야?

1. 내가 바꾼 모든 것을 나열하는 매우 큰 커밋을 수행하십시오.
2. 파일에 여러 수정, 변경, 추가 메소드 이름 등이 있으므로 컴파일되지 않을 작은 커밋으로 나누십시오.
3. 적절한 커밋을 위해 파일을 부분적으로 되 돌린 다음 새로운 변경 사항을 다시 적용하십시오.

참고 : 현재로서는이 프로젝트를 수행하는 유일한 프로그래머입니다. 이 커밋 의견을 볼 유일한 사람은 적어도 우리가 더 많은 프로그래머를 고용 할 때까지는 나입니다.

그건 그렇고 : SVN과 Subclipse를 사용하고 있습니다. 이러한 변경을 수행하기 전에 새 분기를 만들었습니다.

추가 정보 : 처음 에이 상황에 어떻게 도달했는지와 관련하여 별도의 질문을 했습니다. 응용 프로그램의 접착제를 다시 작성하는 방법

답을 얻으려면 앞으로 이러한 커밋 결과를 어떻게 사용할지 스스로에게 물어봐야합니다. 가장 일반적인 이유는 다음과 같습니다.

• 어떤 릴리스의 버그가 도입되었는지 확인하십시오.
• 왜 특정 코드 줄이 있는지 확인하십시오.
• 다른 지점으로 합병
• 고객 또는 테스터가 해당 버전에서보고있는 문제를 해결하기 위해 이전 버전을 체크 아웃 할 수 있습니다.
• 릴리즈에서 특정 부품을 포함하거나 제외 할 수 있습니다.

첫 두 가지 이유는 변경된 코드의 각 줄에 동일하게 적용되는 체크인 메시지를 생성 할 수 있다고 가정하면 한 번의 큰 체크인으로도 제공 될 수 있습니다. 당신이 유일한 프로그래머라면, 작은 커밋은 병합을 더 쉽게 만들지 않을 것입니다. 제출되지 않은 변경 사항 중 일부만으로 릴리스 또는 테스트를 수행 할 계획이없는 경우 마지막 두 가지 이유는 적용되지 않습니다.

작은 커밋을 수행하는 다른 이유가 있지만 변경 중이고 그 시간이 지났기 때문입니다. 이러한 이유로 인해 실수 나 실험적인 변경 사항을 쉽게 철회 할 수있게되었고 무서운 합병없이 동료와보다 쉽게 ​​동기화 할 수 있습니다.

당신이 묘사 한 당신의 상황에 대한 나의 이해에서,이 시점에서 커밋을 나누는 데 아무런 이점이없는 것 같습니다.

난 당신이, 당신이 코드에서 검사를 피하려고 할 어떤 생각 을 알고 컴파일되지 않습니다.

세 번째 옵션이 실현 가능하다고 생각되면 커밋 시퀀스가 ​​컴파일 할 수없는 시스템을 만들지 않는 한 이것이 좋은 방법 일 수 있습니다. 그렇지 않으면 하나의 큰 커밋을 수행하십시오. 추악하지만 간단하고 빠르며 완료됩니다. 앞으로 더 자주 커밋하십시오 .

자주, 작고 의미있는 커밋을 만드는 가장 중요한 이유는 코드의 역사를 이해하는 데 도움이되기 때문입니다. 특히 이해하기 쉬운 diff를 생성하기 어려운 경우 코드가 어떻게 변경되었는지 이해하기가 매우 어렵습니다.

옵션 1 은 변경 한 이력을 난독 화하지만 그렇지 않으면 아무런 문제가 발생하지 않습니다.

옵션 2 는 옵션 1보다 약간 적은 변경 내역을 난독 처리하지만 커밋이 다른 것으로 가정하거나 결론을 내리면 다른 문제가 발생할 수 있습니다 (예 : 독립적으로 다른 브랜치로 병합 가능). 이것이 옵션 1보다 선호되는 강력한 실질적인 이유가 없다면, 이는 그보다 덜 이상적입니다.

옵션 3 이 가장 좋습니다. 다른 방법도 동일하지만 다른 곳에서 설명했듯이 "최고"의 시간이 필요하거나 다른 상당한 비용이 발생하는 경우 예상되는 이점과 비교하여 해당 비용을 측정해야합니다. 더 깨끗한 커밋 만들기.

제공 한 정보를 바탕으로 옵션 1을 선택했습니다. 변경 내용을 커밋하라는 알림을 설정해야합니까?

프로토 타이핑 및 재 작성

명심해야 할 또 다른 고려 사항은, 특히 유일한 프로그래머라는 메모에 비추어 볼 때 상대적으로 새로운 코드베이스로 작업하고 있다는 내 생각에 의문을 가질 때 변화를 저지르는 것과 관련하여 다른 습관을 개발하는 것이 좋을 것입니다 '새로운 코드를 프로토 타이핑하고 기존 코드를 유지하거나 확장하는 것입니다. 아마도 둘 사이에 굉장히 뚜렷한 구분은 없지만 여전히 유용한 구분이라고 생각합니다.

새 코드를 프로토 타이핑 할 때는 변경 사항을 거의 확실하게 브랜치에 저장하거나 별도의 프로젝트에 저장할 때마다 커밋하십시오. 또는 버전 관리 외부에서 모두 작동 할 수도 있습니다. 대신 고려중인 다양한 가설이나 설계의 실현 가능성에 대한 증거를 수집하는 데 집중할 수 있습니다. 필자는 종종 Visual Studio for C # 코드 대신 LINQPad와 같은 다른 도구를 사용하여 작은 프로토 타입을 작성합니다.

특정 가설이나 디자인의 유효성을 검증하면 기본 프로젝트, 이상적으로는 지사에서 다시 작성하고 변경의 본질에 대해 다른 사람 (미래를 포함하여)에 대한 이해를 도울 수있는 작고 의미있는 커밋을 만드십시오. 당신은 만들고 있습니다.

유일한 합법적 인 대답은 트렁크를 끊지 않는 것이지만 때로는 불가능한 경우도 있습니다. 예를 들어, 너무 많이 커밋하면 svn이 커밋을 중단 할 수 있습니다 (옵션 또는 기능 일 수도 있습니다). 이러한 특별한 경우에는 체크인 만하면됩니다. 당신은 단일 프로그래머이기 때문에 다른 사람을 방해하지 않을 것입니다.

따라서 옵션 1을 선택하겠습니다. 가능하지 않으면 옵션 2를 선택하십시오.

옵션 3에는 많은 노력이 필요하며 그만한 가치가 없습니다.

파일에 여러 수정, 변경, 추가 메소드 이름 등이 있으므로 컴파일되지 않을 작은 커밋으로 나누십시오.

비슷한 상황에서 자신을 발견했을 때 다음 기술을 사용했습니다.

1. 특정 기능과 관련된 코드 만 추가하십시오. git add --patch
2. 다른 모든 변경 사항을 보관하십시오. git stash save --keep-index
3. 테스트 실행 / 컴파일 시도
4. 모든 것이 괜찮다면 변경 사항을 커밋하십시오.

SVN에 익숙하지 않으므로 이것이 특정 상황에 적용 가능한지 모르겠지만 기본은 동일해야합니다. 작은 코드 부분을 분리하여 개별적으로 테스트하십시오.

방법 4 : 어쨌든 리포의 현재 상태를 임시 장소에 백업하고, 리포지를 원래 상태로 되돌리고, 모든 변경 사항을 목록으로 작성하고 (임시 백업을 볼 수 있음) 수동으로 다시 구현 (및 컴파일) 그리고 테스트!) 별도 커밋으로.

이미 코드를 작성 했으므로 임시 백업에서 복사하여 붙여 넣을 부분을 파악하는 것입니다.

모든 변경 사항을 깨끗하게 다시 구현하여 커밋이 자체 포함되고 작고 컴파일되도록 보장하면 임시 백업을 삭제할 수 있으며 모든 것이 커밋 시간 / 날짜를 제외하고 거의 동일합니다. 처음부터 제대로했다면

당신은 유일한 프로그래머입니다. 당신이 한 일의 중요한 부분을 자세히 설명하는 단일 체크인을 수행하십시오.

수행 한 작업의 "부분"을 롤백 할 가능성이 있습니까? 그렇지 않은 경우 옵션 1로 진행하십시오.

코드를 버전 관리 시스템에 체크인해야하는 몇 가지 이유가 있습니다. 그리고 여러분 모두가 유일한 개발자 인 경우 안전을 중심으로 돌립니다. 즉, 나사를 조이거나 기계가 죽는 등의 경우 항상 마지막 체크 포인트로 돌아갈 수 있습니다.

나중에 프로젝트에 들어온 프로그래머는 컴파일되지 않은 버전으로 롤백하지 않을 것입니다. 따라서 IMHO의 옵션 2는 미치광이입니다.

옵션 3은 그런 시간 싱크처럼 들립니다. 내가 당신의 상사이고 당신이 이것을하는 데 시간을 낭비한다면, 나는 당신의 시간이 가치있는 것에 대해 약간 이야기 할 것입니다.

반복하려면 : 코드를 체크인하여 시스템 장애시 엉덩이를 덮거나 저장합니다. 한 사람 팀의 다른 모든 것들은 창 드레싱입니다.

내 규칙은 : 심각한 코드 검토 없이는 체크인하지 않습니다. 난 내 자신에있어 경우에, 나는 코드 나 자신을 검토해야 할 것이다, 그러나 그것은 것입니다 검토. 다른 사람이 검토 할 수없는 많은 양의 코드 변경이있는 것 같으므로 직접 검토 할 수 없습니다 (자신의 코드를 검토하는 것은 더 어렵고 더 많은 규율이 필요합니다. ).

완전히 깨지지 않는 규칙은 다음과 같습니다. 빌드조차하지 않는 코드를 체크인하지 말고 작동하지 않는 코드를 체크인하지 마십시오.

해결 방법 : 변경된 코드를 복사하고 원래 지점으로 돌아갑니다. 한 번에 하나의 변경 사항을 원래 코드로 병합하고, 검토하고, 테스트하고, 체크인하십시오. 설명한 프로그래밍 방법을 사용하면 심각한 버그를 발견 할 수 있습니다.

또한 좋은 프로그래밍 습관을 훈련시키는 좋은 방법이기도합니다.

당신이 너무 걱정하고 있다고 생각합니다. 당신이 유일한 프로그래머이고 작업 할 스펙 시트가 없다면 전적으로 당신이하는 일에 달려 있습니다. 큰 커밋을 한 사람을 아무도 처벌하지 않기 때문에 커밋 내에서 개별 파일 변경 사항을 롤백 할 수없는 것과 같은 기술적 문제 만 발생합니다. 이 시점에서 레포 만 제어 할 수 있기 때문에 큰 관심사는 아닙니다.

실용주의와 교의주의 사이에는 선이 그려져 있습니다. 당신이 한 일은 팀에서 좋은 생각이 아니며 앞으로 반복해서는 안되지만, 귀하의 상황에서 나는 큰 커밋을 제출할 것입니다.

문제는 커밋 사이의 지연이 오래 걸리지 않고 코드를 컴파일 할 수없는 상태로 너무 오랫동안 유지한다는 사실입니다. 먼저 'long'에 대한 정의는 무엇입니까? 어떤 사람들에게는 과도기 상태에 대한 5 분이 너무 많지만 컴파일러를 실행하지 않고도 며칠 동안 코드를 연마 할 수 있습니다.

실제로 중요하지 않습니다. 중요한 것은 코드를 제어 할 수 없게되어 코드를 관리 할 수 ​​없게 된 것입니다. 이것은 정상입니다. 기술 부채가 있고 리팩토링에 대해 생각할 때입니다. 당신은 좌절합니까? 코드가 컴파일되지 않고 단위 테스트가 없습니까? 이 경우 리팩토링에 대해 어떻게 생각할 수 있습니까? 걱정 마. "카우보이 코딩"을 마치고 청소를 시작하십시오. 이상적으로 몇 가지 테스트를 작성하십시오. 그럴 시간 없어요? 좋아, 작은 개선부터 시작하십시오.

일부 변경에는 테스트가 필요하지 않습니다. 변수 이름을 더 적합하게 변경하고 반복 코드를 별도의 함수로 이동하는 등 ... 코드에 대해 더 잘 이해할 수 있습니다. 그 후에는 더 큰 변경을 수행 할 수 있습니다. 다시 가능하면 테스트를 작성하십시오. 코드를 관리하기 쉽게 만드십시오.

그 후 다음 변경으로 "너무 오래"걸리지 않는다는 것을 알 수 있습니다 (무엇이든).