너무 많은 오버 헤드없이 코딩 진행을 의미있는 커밋으로 분할

수정 사항이나 기능을 작업 할 때 때때로 몇 초 만에 즉시 개선 될 수있는 다른 작은 문제가 우연히 발견됩니다. 내가 즉시 수행 한 다음 완성 된 기능 / 수정 사항을 커밋하면 커밋에 둘 이상이 포함됩니다. 예를 들어 "add feature X and code clean up"또는 "fix bug X and improved logging". 이것을 두 개의 커밋으로 나누는 것이 좋습니다. 동일한 파일에서 두 가지 변경 사항이 발생한 경우 단순히 하나의 파일을 추가하고 커밋하고 다른 파일을 추가 한 다음 다시 커밋 할 수 없습니다. 그래서 다음 세 가지 옵션이 있습니다.

1. 무언가를 작업하는 동안 의도적으로 관련이없는 것을 간과합니다.

2. 변경 사항이 두 개인 파일을 복사하고 되돌리고 한 변경 사항 포함, 커밋, 다른 변경 사항 포함, 다시 커밋하십시오.

3. 관련이없는 작은 것을 변경하지 말고 할 일 목록에 추가 한 후 나중에 수행하십시오.

다음과 같은 이유로 세 가지 옵션을 모두 좋아하지는 않습니다.

1. 작은 문제를 해결하지 않으면 코드 품질이 저하 될 수 있습니다. 노력없이 무언가를 개선 할 수있는 기회를 의식적으로 놓치면 기분이 나빠집니다.

2. 수동 작업이 증가하고 오류가 발생하기 쉽습니다.

3. 아주 작지 않은 할 일에는 괜찮지 만, 할 일 목록에 작은 항목을 추가하고 나중에 다시 방문하면 즉시 수정하는 것보다 훨씬 오래 걸립니다.

그러한 상황을 어떻게 처리합니까?

프로그래밍 할 때 매우 실용적이어야한다고 생각합니다. 완벽한 구성표, 워크 플로 또는 구현을 구성 할 수있는 경우에도 때로는 작업을 수행해야합니다. 내가하는 일은 다음과 같습니다.

git의 개별 덩어리와 라인을 가능한 한 관련되지 않은 변경 사항을 분리하기 위해 스테이지 / 커밋하는 기능을 사용하지만 때로는 분리가 제대로 수행되지 않으면 일시적인 문제가 발생할 수 있습니다. 변경 사항이 인접 해 있으므로 CI 파이프 라인의 모든 개별 변경 사항을 테스트하는 정책이없는 한 일반적으로 큰 문제는 아닙니다.

관련없는 변경이 너무 크면, 할 일 목록에 넣고 보통 내 생각에 신선하면서 바로 가져갑니다. 때로는 다시 돌아 오기까지 하루나 이틀이 걸릴 수 있습니다. 그것은 현재의 과제와 생각에 달려 있습니다. 때로는 좋은 해결책이 없다면 문제의 코드 옆에 TODO를 넣을 것입니다.

사물을 분리하는 것은 실용적이지 않으며 원래 작업과 함께 약간의 조정을 할 것입니다.

변경의 크기는 일반적으로 갈 경로를 선택할 때 결정적인 요소이지만 결국에는 냄새를 남기는 것보다 워크 플로 규칙을 무시하는 것이 좋습니다.

내 편집기에는 파일의 개별 부분을 매우 쉽게 스테이징 할 수 있는 플러그인 이 있습니다. 나는 다른 프로그래머 편집자가 비슷한 플러그인을 가지고 있다고 생각하지만 항상 수동으로 할 수는 있습니다 git add --patch | -p. 그런 다음 git stash 를 사용하여 다른 커밋을 격리하여 작은 커밋을 테스트합니다. 그런 다음 커밋 한 후 그냥 git stash pop중단하고 중단 한 부분을 계속합니다. 이것이 바로 그 기능을 위해 설계된 것입니다.

비결은 변화에 합당한 노력을 기울일 준비가되어 있지 않으면 변화를 일으키지 않는 것입니다.

내가하는 경향은 할 일 목록에 추가하는 것입니다 (때로는 코드에 주석을 추가하거나 때로는 버그 티켓에 대한 메모에 추가하고 때로는 수정 사항이 결국 병합 될 것이라는 것을 알고 별도의 지점에서 코드를 업데이트하는 경우도 있음). 사소한 품질 문제 롤업에 대한 버그 티켓이없는 경우이를 위해 특별히 하나를 제기하므로 나와 모든 사람이 지점이 병합 될 때 해당 코드 변경 이유가 무엇인지 알 수 있습니다. 나는 그것의 재미를 위해 결코 변경을하지 않으며, 모든 것이 추적 성을 얻으므로 코드가 변경 될 때 동료가 너무 놀라지 않을 것입니다.

간단히 말해서-코딩 할 때 간과하십시오. 기능을 추가하는 경우 아무리 작아도 2 개의 기능을 추가하려는 유혹을받지 마십시오. 누군가가 귀하의 지점을 되돌리기로 결정하면 (당신의 기능이 더 이상 필요하지 않기 때문에) 모든 미니 버그를 잃게됩니다. 마찬가지로 올바르게 작동하는 일부 중요한 코드에서 작은 '수정'을 만들고 싶지 않습니다.

내가 약간 사용하는 옵션은 TODO주석 을 추가 한 다음 git add --patch파일의 관련 부분을 선택 하여 자주 "부분"커밋을 많이 수행하는 것입니다 . 그런 다음 git rebase --interactive부분 커밋을 재정렬하고 최종 커밋하기 전에 부분 커밋을 다시 정렬하고 병합합니다.

이렇게하면 주 커밋을 깨끗하게 유지하면서 여전히 찾은 다른 문제를 해결할 수 있습니다.

git rebase로컬 커밋 만 다시 작성하기 때문에이 맥락에서 아무 문제가 없습니다 .

다른 옵션은 현재 변경 사항을 "git stash"하는 것입니다. 워크 플로우는 다음과 같습니다.

1. 기능 A 와 관련된 변경을 시작하십시오 .
2. 버그 B를 발견 하고 즉시 수정하기로 결정
3. 리포지토리의 명령 줄에서 수행하십시오 git stash (이후 코드는 Feature A 작업을 시작하기 전의 상태로 돌아갑니다 )
4. 이 시점에서 기능 A 에 대한 커밋되지 않은 변경 사항 은 "스 태쉬"에 저장됩니다.
5. 버그 B 를 수정 하고 리포지토리로 다시 커밋하는 데 필요한 코드 변경
6. 명령 행에서 git stash pop
7. 기능 A에 대한 커밋되지 않은 변경 사항 이 이제 숨겨져 버그 B에 대한 (이미 커밋 된) 수정 프로그램과 함께 진행중인 코드로 복원됩니다.

버그 수정과 관련된 변경 사항을 별도로 준비 (및 커밋)하십시오. Git Extensions에서 이것은 매우 쉽습니다. 커맨드 라인에서 나는 당신이해야한다고 생각합니다 git add -p.