나는 Mercurial의 mantra 1에 항상 동의 했지만, 이제 Mercurial은 rebase 확장과 함께 제공되며 git에서 인기있는 관행이므로 실제로 “나쁜 습관”으로 간주 될 수 있는지 궁금합니다. 사용을 피하기에 충분히 나쁘다. 어쨌든, 나는 밀고 난 후에 rebasing이 위험하다는 것을 알고 있습니다.
OTOH, 5 개의 커밋을 하나의 패키지로 패키지화하여 (특히 생산 지점에서) 멋진 것으로 보이게하는 요점을 보았지만 개인적으로 일부 커밋을 볼 수있는 것이 더 좋을 것이라고 생각합니다 실험은 아무리 멋지지 않더라도 이루어 지지만 “X를하려고 노력했지만 결국 Y만큼 최적이 아니므로 Z를 기본으로 삼는 것”과 같은 것을 보는 것은 IMHO가 공부하는 사람들에게 좋은 가치를 줄 것입니다 코드베이스를 개발하고 개발자의 생각을 따르십시오.
내 의견은 (멍청한, 내장, 편견에서와 같이) 실수를 숨기려고 rebase와 같은 프로그래머는 …이 프로젝트에 전혀 좋지 않다고 생각합니다.
그래서 나의 질문은 : 당신이 실제로 그러한 “유기 커밋”(즉, 훼손되지 않은 이력)을 갖는 것이 가치가 있다는 것을 알게 되었습니까? 아니면 반대로, 당신은 멋진 커밋 된 커밋을 겪고 프로그래머의 실험 과정을 무시하고 싶습니까?; 어느 쪽을 선택하든 왜 효과가 있습니까? (다른 팀원들에게 역사를 유지하도록하거나 대안으로 근거를 바꾼다).
Mercurial “History is Sacred”에서 Google DVCS 분석 당 1 개
답변
역사는 1, 신성한 현재는 없습니다. DVCS “트리”를 두 부분으로 나눌 수 있습니다.
-
과거 당신이 코드의 현재 상태에 도달하는 방법에 대한 정확한보기를 포함 / 역사. 역사의이 부분은 시간이 지남에 따라 성장합니다
-
현재 현재 작업중인 부분은 당신에게 코드의 진화를 확인합니다. 역사의 대부분은이 팁의 크기가 항상 같습니다.
당신이 발표했거나 사용했던 모든 코드는 과거의 일부입니다 . 설정을 재현하거나 회귀를 도입 한 내용을 이해해야하므로 과거는 신성합니다. 당신은 결코 과거를 다시 쓰지 않을 것입니다 . git에서는 일반적으로 master에 있으면 아무것도 다시 쓰지 않습니다. master는 역사 의 과거 부분입니다. Mercurial에는 “트리” 의 과거 부분을 추적 하고 불변성을 강제하는 이 공개 단계 개념 이 있습니다.
코드 의 현재 부분은 현재 작업중인 변경 세트입니다. 사용 가능하고 버그가 없으며 리팩토링하려는 기능 분기입니다. 그것을 다시 쓰는 것은 완벽하게 좋습니다. 그것은 과거의 부분을 더 예쁘고 단순하며 사용 가능하게 만들기 때문에 좋은 생각 입니다. Mercurial은 초안 단계 에서이를 추적합니다 .
당신의 역사가 향상되면 다시 기지를 주시기 바랍니다. 머큐리얼은 당신이하지 말아야 할 물건을 리베이스하는 경우 발로 자신을 쏠 수 없습니다.
답변
예를 들어 모든 실수가 숨길 필요가있는 것은 아닙니다. 예를 들어 실수로 바이너리 파일을 내 저장소에 커밋했습니다. 히스토리를 무단 변경하는 것은 잘못해서는 안되는 커밋 된 파일과 같이 오류가 히스토리 자체에 독점적으로 있지 않은 경우에만 나빠집니다.
답변
많은 작은 의존적 변경과 대조적으로 하나의 큰 응집성 변경이있을 때 코드 검토가 훨씬 쉬워집니다.
새로운 기능을 개발할 때 지점에 많은 변경 사항을 적용하고 싶습니다. 패치를 제출할 준비가되면 작은 커밋을 해당 기능에 필요한 모든 새 코드를 나타내는 하나의 큰 커밋으로 축소합니다. 이것은 rebase가 유용한 곳입니다.
반면에 커밋이 서로 관련이 없으면 리베이스는 잘못 권고됩니다. 여러 기능 추가는 별도의 커밋이어야하며 (이상적으로는 별도의 브랜치에서 온) 것이 좋습니다.
답변
귀하의 질문은 역사를 일련의 코드 변경 세트로 설명하고 유기적 인 커밋이 미래 독자를 개발 프로세스에 몰아 넣는 지 여부를 묻습니다. 그러나 릴리스 / 통합 엔지니어 인 저는 종종 역사를 코드로 생각하지 않습니다. 나는 나의 역사가 말하는 이야기, 그것이 가지고있는 제도적 지식, 그리고 그것이 문제를 빠르게 디버깅 할 수 있는지의 여부에 더 몰두하고있다.
나는 유기적 인 워크 플로우가 내 자신조차도 이것을 잘한다고 생각하지 않습니다. 저렴한 브랜치, 빠른 커밋, 원격에 일찍 저장하는 등 코딩 할 때 DVCS에 대한 가치는 회사의 통합 관리자 로서 중요하지 않습니다 .
I 문제 git rebase, git merge, git diff, 그리고 git apply지금까지보다 더 자주 그 역할 git add이나 git commit. 같은 도구를 사용 rebase하면 기능이있는 코드에서 유지할 수있는 코드를 변환 할 수 있습니다.
비현실적이거나 모호한 커밋은 유용하지 않지만, 주요 관심사가 코드를 작동시키고 다른 사람에게 배포하지 않는 경우 유기적으로 작성하는 것은 죄악이 쉽습니다. 내가 작성하더라도 Case 15: Fixed a problem, 같은 커밋 또는 Refactored <cranky legacy feature>유지 관리 자체의 비난을합니다. 그러나 “증분”커밋과 같은 정전을 유발하지는 않습니다. 다른 날 개발자가 나에게이 주제 브랜치를 생각해 보자.
$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update
이것들은 악입니다. Faustus 박사를 위해 설계된 DVCS와 같습니다. 빠르고 쉬운 소스 컨트롤을 제공합니다. 당신은 나에게 당신의 코드 관리자의 영혼입니다. 모든 게으른 커밋은 이기적인 행동입니다. 우리 중 많은 사람들이 그것들을 작성하지만, 우리는 또한 미래에 논리적이고 복제 가능하며 디버깅 가능한 역사를 가지고 있습니다. 방법이 없으면 할 수 없습니다 rebase.
실패한 실험에 관해서는, 우리의 (새롭고 깨끗한) 커밋 메시지에 그것들을 묘사 해 보시겠습니까? 지금부터 1 년 후 반 완성 된 스 니펫이 필요하지 않습니다. 나는 중단 된 시도에 대한 기록을 원하고, 내가 다시 시도하기에 어리 석다고 생각되면 짧은 설명 일 것이다. 세계에는 많은 성공적인 워크 플로가 있지만, 프로덕션 코드베이스에 깨진 코드를 의도적으로 커밋하려는 이유를 생각하기 위해 고심하고 있습니다.
답변
성스러운 것은 없지만,하고있는 일에 대한 충분한 이유가 있는지 확인하십시오. Rebasing은 올바르게 사용하면 매우 강력하지만 다른 강력한 도구와 마찬가지로 부주의하게 사용하면 혼란스럽고 문제가 발생할 수 있습니다.
개인적으로 최종 테스트를 실행하고 기능을 기본 지점에 병합하기 전에 트렁크 (또는 주요 개발 지점)에 대해 로컬 기능 지점을 리베이스하는 것이 매우 유용하다는 것을 알았습니다. 그렇게하면 실제로 병합하기 전에 병합 충돌 등을 처리하게됩니다.
답변
IMHO, 실험은 일반적으로 기준선이 아닌 선반 또는 임시 지점에 속합니다. 이를 따르면 모든 커밋이 논리적으로 건전하고 가치를 더할 수 있으므로 문제가되지 않습니다.